Impact of Expected Change on the Length of Sprint
Because changes are not allowed during a Sprint, the impact and frequency of expected changes may have an impact on the decision related to the length of the Sprint when it is determined. If project requirements are generally stable and major changes are not expected in the near future, the Length of a Sprint may be set to be longer, 4 to 6 weeks. This provides stability to the Scrum Team members to work on the Prioritized Product Backlog requirements for lengthy periods of time without having to go through the related processes that are conducted for every Sprint.
However, if project requirements are not very well defined or if significant changes are expected in the immediate future, the Length of Sprint may be relatively shorter, 1 to 3 weeks. This provides stability to the Scrum Team members to work on shorter Sprints and deliver results, which can be evaluated by the Product Owner and stakeholders at the end of the Sprint. This also provides enough flexibility for them to clarify requirements and make changes to the Prioritized Product Backlog at the end of each Sprint.
To get maximum benefits from a Scrum project, it is always recommended to keep the Sprint Time-boxed to 4 weeks or less, unless there are projects with very stable requirements, where Sprints can extend up to 6 weeks.
The following figure depicts the impact of expected change on the Length of Sprint.
However, it is important to note that expected change is not the only factor used to determine the Length of Sprint. Other factors that also need to be considered include:
- Actual time to get work done (if the project or corporate environment needs a specific time to get tasks done, that could determine the Length of Sprint)
- Planned date for a release (the Length of Sprint should take into consideration the release dates for the overall product or service)
- Any other factor as determined by the Product Owner or Scrum Master, that need to be considered while determining the Length of Sprint
It is important to note that changing the Length of Sprint should not be decided lightly or periodically (e.g. it is not advisable to have the sprint length as 3 weeks this sprint, 2 weeks the next, 4 weeks for the third sprint etc.) Length of Sprint should preferably be consistent. One of the greatest impacts of changing the Length of Sprint is that it causes a reset on all tracking at the project level. Previous velocities may become useless for forecasting and planning of future Sprints. Without an accurate velocity (which is a primary metric in any scrum project), the Scrum Team cannot be measured for effectiveness or adequately choose the number of User Stories to take on when planning for the next sprint. So, once the Length of Sprint is decided, it should preferably be kept constant over the duration of the project or through multiple Sprint cycles.
Agile Enterprise Transformation Coach
4 年Stretching a sprint or iteration duration from two weeks to longer necessitates a careful look at a number of often overlooked factors; the volatility of the product backlog is merely one. Other potentially more impactful factors include: the stability of the composition of the Scrum Development team, reported defects with recent releases, the ability of the team to mitigate risks and to avoid their escalation into issues, consistent value delivery as reflected by predictable velocity, the maturity of the Scrum Development team (Tuckman model as an indicator), and the potential impact on other teams in a scaled environment. I refer to this set of considerations as the "sum of the risk" much like any other risk probability and impact assessment. I would equate my "sum of the risk" to your "Expected Change" label on your "Y" axis. Lengthening sprint duration itself puts the team and the product at greater risk by extending retrospective feedback loops used for improvement which in turn, hinders empirical process control and adaption, the very heart of agility. When it comes to lengthening sprint duration I like to suggest that organizations "proceed with an abundance of caution." While they can always change the duration, disrupting cadence isn't usually a productivity enhancer.