In this series, we're looking into the fundamentals of the Scrum framework. By understanding why each role, artifact, event, and rule exists, we can be wise in convincing others to follow Scrum and explain the possible consequences of violating the framework.
In this article, we’ll focus on fixed-length Sprints.
As always, we’ll use the Scrum Guide to identify the fundamentals (the latest Scrum Guide can be downloaded here).
All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.
[Scrum Guide, July 2013, page 7 (English version), emphasis added]
Put another way, most Scrum events (Daily Scrum, Sprint Planning, Sprint Review and Sprint Retrospective) are time-boxed to avoid too much overhead; when you’ve accomplished the objective of these events, they’re over. The Sprint, however, is always fixed length; if the team finished all they planned to do in the Sprint, it’s not over—they add more work!
Why? Why not let Sprint lengths vary and complete the Sprint when the work is done?
Oh, and can’t we let Sprint lengths vary from Sprint to Sprint? No. Again from the Scrum Guide:
Sprints best have consistent durations throughout a development effort.
I have had several clients tell me, “It’s too hard to plan just the right amount of work. We always planned too much (or too little). So we just let the Sprint end whenever the work is done.” My response? “Then you’re not doing Scrum!”
You may or may not care if you’re “doing Scrum” but the fixed-length Sprint has several specific purposes in the Scrum framework:
- Cadence. Establishing fixed-length Sprints gives everyone—the Development Team, the Product Owner, and the stakeholders—an expectation of how frequently they will get working software and when they will get a chance to inspect and adapt the Product Backlog.
- Meaningful velocity. If the Sprint length varies from Sprint to Sprint, then the amount of work accomplished in each Sprint tells you next to nothing about what to expect in future Sprints. Velocity is a crude tool for forecasting future work, no doubt, yet it’s the primary metric by which the Product Owner can establish expectations with stakeholders.
- Dynamic tension for continuous improvement. Perhaps most importantly, fixed-length Sprints will help drive discussions around opportunities for improving the process. More about this later.
By keeping Sprints the same length every time, the Development Team will begin to get used to the rhythm of the Sprint. By establishing a rhythm, the Team will learn how much work they can do in one iteration. That same rhythm also gives the Product Owner, management, customers, users, and other stakeholders an expectation for when they will get a chance to change direction as needed to meet then-current business needs. From a Lean practices perspective, fixed-length Sprints help drive variability out of the process leading to higher quality and greater predictability.
Although velocity may be the most misused metric in Scrum, it is also extremely useful in forecasting when capabilities will be available in the marketplace. That forecast must be updated after every Sprint based on the most recent learnings about how much work the Development Team can accomplish. Without fixed-length Sprints, any measure of “work accomplished” is useless in forecasting when new product or system ideas will begin to generate cash. Time-to-cash is an important indicator of just how agile any business really is.
Finally, fixed-length Sprints force the Scrum Team to talk about how to improve the process. You may be familiar with the “Devil’s rectangle” depicted below showing the four key variables for managing any project: Cost, Time, Scope, and Quality. (This extends the “Iron Triangle” to include quality.) Only 3 of the 4 variables can be “fixed” for a successful project.
In Scrum, Quality is fixed through the Definition of Done and only reviewing and releasing “done” software. Cost (driven primarily by labor for software) is fixed by using a stable, self-directing team. And time is fixed by using fixed-length Sprints. Only Scope is allowed to vary from Sprint to Sprint. This pressure to forecast the Scope of the Sprint while constraining the other variables will highlight opportunities for improving the practices used by the Scrum Team.
So what happens if we let Time be a variable in addition to Scope? Then the pressure is off—“it takes what it takes” is the refrain. And so is the pressure to improve the process.
I had a client recently that was using 3-week Sprints. They were able to maintain their largely manual testing processes and do pretty well at completing the work planned for the Sprint. However, the Product Owner was unhappy with waiting three weeks to inspect their progress given the volatility of their requirements and they decided to try 2-week Sprints. In their first 2-week Sprint, they realized their manual testing methods would not allow them to complete much work in a Sprint. This realization drove them to invest in and adopt automated testing practices. Today, all their testing is 100% automated. The fixed-length Sprint drove them to improve their process. If they had allowed Sprint lengths to vary, the pressure to automate testing would not have occurred.
Why fixed-length Sprints?
- To establish a rhythm for all concerned.
- To better enable forecasting when capabilities will be available in the marketplace.
- And perhaps most importantly, to drive continuous improvement in the development of software for the organization.