4 Prerequisites for Reducing Sprint Duration
Agile manifesto has explicit stated preference for shorted sprints. Shorter sprints can ensure that:
- “Parkinson’s Law” does not set in, that is work does not expand to fill the available time
- “Understanding gap” between users and developers gets ironed out quickly
- “Quick response to change” becomes possible
However, there are other factors which may make too short a sprint cycle counter productive.
Factors influencing sprint duration
There is a certain amount of overhead associated with each sprint. Every sprint requires some initial planning time plus validation, regression testing and integration time and effort at the end. This overhead is proportional to the total size of the software and the level of automation in place and does not depend on the number of stories delivered during the sprint. In short…
Do not attempt short sprint cycle without a mature engineering practice.
Otherwise, it would lead the team to burn midnight oil and lead to frustration.
If the product owner is always available for the team…
If all the stories are clearly spelled out…
If there is no confusion or disagreement on how the user stories are to be implemented…
…then short sprints are fine. Otherwise, stories cannot be delivered in a short sprint.
Do not attempt short sprint cycle without clear user stories.
But longer sprint may not be a solution because it will only introduce slack and waiting time. So, better idea would be to create a buffer of clearly defined user stories. Applying Kanban principles may help.
Third key point in deciding the sprint duration is the amount of time and effort required to implement a story. Several factors may influence that:
- Architectural complexity
- Existing technical debt
- Skill level of the team
Do not attempt short sprint cycle if, for whatever reason, the team cannot implement stories fast enough.
If you need to have short sprint cycles, do the following:
- Improve your engineering practice to bring down the sprint overhead
- Ensure availability of clearly defined user stories
- Simplify your architecture and reduce technical debt
- Improve the skill level of the team