Sprints in Scrum

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 unit. 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 a 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.

Why is Sprint length so important?

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 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:

What role do Scope Changes play in a Scrum Sprint?

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.

The best length of a Sprint

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:

Scrum is a difficult matter, no question. So we should use all the help we can get to make things easier, not harder. It’ s easier for us to keep track of a week, and we can plan better because we have been socialized this way since childhood. We know the weekly rhythm almost from birth and therefore it is relatively easy for us to plan the period of one week accurately.

Stories have to fit into one Sprint. The shorter the Sprint, the shorter the Stories need to be. Personally, I’ve seen many teams that are really annoyed by Product Owners who love writing mammoth Stories. I’ve seen extreme cases of two Stories for a three-week Sprint with a team of seven. Short Sprints force the PO’s to write short Stories.

I also know teams that have been doing a pretty relaxed job in the first week of the two-week Sprint, according to the motto “we don’t have to deliver until next week”. In fact, the Sprint length even influences the velocity of teams.

Shorter Sprints, shorter meetings, more value-added time

Shorter Sprints, shorter meetings, more value-added time

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 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 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.

After all, this is exactly what we want in Scrum.