Small Batches
In order to understand the why behind sprints, you have to first understand why we use the concept of sprints at all. There are a couple reasons. Reason 1 is because we want to have small batch sizes. Since Scrum is an empirical process, the notion of small batch sizes (short sprints) is based on the Theory of Constraints, which says that a system is limited in achieving more of its goals by a small number of constraints. In software, some of these constraints are backlog items (inventory), throughput (velocity), and ROI (customer value). When the batch size is small, you can get faster feedback and dynamically manage your risk.
Fast Feedback
In scrum, there is always a trade off between the speed of the feedback and the size of the sprint. Every sprint has an administrative cost (in pure Scrum) with the sprint planning, backlog selection, task breakdown, and daily Scrums. For many teams, the balance for this overhead vs working time is in having a 2 week sprint. Longer than that and you are increasing your feedback cycle time. Shorter than that and there may not be enough time for the team to really get started.
Dynamic Risk Management
Another advantage of shorter sprints is that it gives you the opportunity to dynamically manage your risks. If the customer changes their requirements, the short cycles give you the opportunity to re calibrate every 2 weeks. If a competitor comes out with a product that changes your product’s value proposition, you get the opportunity to change direction every 2 weeks. This is very different than traditional project management whereby there may be a risk mitigation plan, but no real way to change the direction of the project in mid flight.
