Scrum organizes the added value in iterations, known as Sprints. Sprints in Scrum are initially nothing more than time boxes, i.e. just one-time units. Nothing more, but also nothing less.
Thus – and this is the interesting aspect of Scrum – Scrum introduces a different paradigm of time management.
Waterfall also has certain phases like specification phase, implementation phase, test phase, documentation phase, acceptance phase, etc.
Here, however, the time periods are bound to specific content, and the content ultimately determines the length of the time period. The phase is completed when the objectives of this phase have been achieved, or at least when satisfactory results have been achieved.
Scrum turns the relationship between timebox and content upside down. The timebox, i.e. the length of the Sprint, is clearly defined and should change as rarely as possible. We’ll get to that in a moment.
The content, or more precisely the scope, that is to be delivered in this timebox is variable.
At first glance, this paradigm shift seems to be necessary because of the vertical (end-2-end) and feature-oriented development that Scrum introduces. But the decoupling of timebox and scope gives Scrum teams even more opportunities.
The decoupling of the timebox and scope offers much greater flexibility. When choosing the length of a Sprint, other things can suddenly be taken into account than just the scope.
The Sprint length thus becomes more of a strategic tool to better support the flow of value. The following example illustrates this:
Apart from bugs, constant scope changes in the middle of a Sprint are not only a nuisance for Scrum teams, but they are also very expensive and a real velocity killer.
Cross-functional teams have made a lot of effort to perfectly balance a Scrum Sprint during the planning, which takes several days of effort (not time) over all team members, taken together with all activities.
A scope change immediately destroys this balance; a replanning is necessary, which costs money.
Teams that are constantly faced with scope changes could reduce the length of the Sprints to one week, for example, or even just for one phase.
In the meantime, the Scrum Master can work with stakeholders to address the causes of permanent scope change, whatever they may be.
The Sprint construct is used here as a strategic instrument and is not only the carrier of the scope.
If you ask me, the optimal length of a Sprint is not two weeks, but only one week.
This is not only because the risk of expensive scope changes is at its lowest here, but also for a number of other reasons:
Try scagile now and see what your Sprint Backlog could look like.
The preference for longer, at least two-week Sprints is usually based on the erroneous assumption that less time will be lost in longer Sprints for meetings (Planning, Review, Retrospective) and more net value-added time remains.
My experience tells me the opposite.
Planning long Sprints takes longer and is much more tiring.
Scrum.org says planning a four-week Sprint can take up to 8 hours. Seriously, who wants to sit in an eight-hour technical workshop? And who expects something meaningful to come out of it?
In short Sprints, meetings are more frequent but much shorter.
For example, a Retrospective can still be held every two weeks. There isn’t that much to improve every week anyway and to improve significant things you often need more time.
The mission is to tickle 4.5 days of net development time out of a 5-day Sprint. And that is possible.
As a matter of fact, shorter Sprints create even more transparency and demand even more discipline. Otherwise, you won’t get 4.5 days of net value-added time.
But that’s exactly what teams often don’t like that much. Often, Dev Teams and POs like to stay at a distance and don’t have the best of relationships. During short Sprints, they have to communicate more often and more directly with each other.
The Scrum Master also has to work more intensively with the team to keep the pace up.