Author: Ram Srinivasan
When organizations are adopting Scrum, they are always confronted with how long their Sprints should be. Scrum merely provides guidelines that Sprints can be anywhere from 1 week to 4
weeks long. The Sprint is a feedback loop, providing an opportunity for the stakeholders and the Scrum Team to Inspect and Adapt (the product, and the way they work together, respectively). The Sprint ends with a Sprint Review, an opportunity for the stakeholders to see what the Development Teams have built during the Sprint (i.e. the Product Increment, built as per the “Definition of Done” is made “transparent”), and discuss what might be built in the subsequent Sprint (“Inspect the artifact i.e. Product Increment, and Adapt the Product Backlog).
There are various factors which determine how long the Sprint should be. Shorter sprints have a higher transaction cost associated with them (e.g. – if the team has one week sprints, they may have four planning, review and retrospective meetings in four weeks, but if they have a four week sprint, they may only have one planning, review and retrospective meeting). Longer Sprints have a higher holding cost, and possibly also increase the risk by decreasing the frequency of feedback the team could get from its stakeholders. Also, longer Sprints will be associated with knowledge decay, if all “how to build the increment” is done during Sprint planning, not to mention that a team doing that will fail to capitalize on the knowledge that they have gained during the sprint. It is hard to quantify “knowledge decay” and “knowledge gained” so for the sake of simplicity, let us just consider the transaction cost and holding cost alone in determining the duration of the Sprint.
This is a “U-Curve” optimization problem and for most teams a two week cycle optimizes the transaction cost and the holding cost associated with Sprints. However a two-week cycle may not work well for everyone. These are some of the factors that you may have to consider before deciding on the duration of your Sprint
- Stakeholder’s Risk Tolerance: How long can the stakeholders wait before getting anxious to see the working Product Increment? Lesser the risk tolerance, shorter the sprints.
- Market competition and market demands: Are you in an industry where your competitor is releasing a new version of their product every week, or may be multiple times a week? Not only should you have a robust “Definition of Done”, but you should also consider a shorter time frame for your Sprints. If you are in an industry where you have specific launch windows (e.g. educational industry, where the launch window is typically the Summer and Winter breaks), may be you can afford longer Sprints
- Complexity of your product: Scrum tries to mitigate risk by making the Product Increment transparent at the end of the Sprint. It might be tempting to think that more complex the product is, the longer the Sprint should be. More complex the product, greater the risk, and contrary to the popular belief, shorter Sprints provide better risk management opportunities. It may sound like it would be challenging for the team to build a meaningful Product Increment with a short sprint, but with a good Product Owner, big features can be sliced to multiple “micro-functionalities” and with that, the teams should be able to build a meaningful Product Increment.
- Size of the team/number of teams working on the product: Scrum does scale to multiple teams, and it is definitely possible to have multiple teams working on the same Product (Backlog) to create one Product Increment at the end of the Sprint. More teams working on the same product need a tighter feedback loop and again, contrary to the common belief, a shorter Sprint would give them a tighter feedback loop and would help them build the right product. Beyond shorter sprints, good technical practices (like Test Driven Development, Continuous Integration, etc) should also be followed to make sure that the product being built is a high quality product.