Scrum Sprint: Why 1 Week is More Effective

Why a one week sprint is much more effective and increases the team velocity enormously!

Scrum Sprint: Why 1 Week is more effective | scagile blog

Contents of this article

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

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

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.

Prioritizing with the WSJF Method [+ Excel Template].

With the WSJF Method, PI Plannings become a breeze and more effective than ever before. Click here for the free step-by-step guide and WSJF Excel template.

The most optimal Sprint lenght

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: 

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.

Scrum is a difficult matter, no question. So we should use all the help we can get to make things easier, not harder. 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.

The Sprint length even influences the velocity of teams.

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

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

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

The app for scaled agile teams is here!

Click here, to show articles with the same tags:

Klaus Riedel

As an agile coach, Klaus Riedel, together with his team, supports the digital transformation and the introduction of Scrum and SAFe in large organizations such as Deutsche Bank, Conrad Electronics, Volkswagen, PWC and others.

All his gained practical experiences in more than 15 years of agile transformation have been incorporated into the articles of his blog.

In Scagile Academy he trains young Agile Experts and since 2016 he teaches agile project management at the German Faculty of TU Sofia.

More interesting articles for you: