Cet article est également disponible en français

Used to two-weeks sprints, like many, I recently could see the impact of a one-week sprint can have on the product and on the team. Do you think you should give it a try too?

Sprint definition

Here is the official definition of a “Sprint”, as it is presented in the Scum Guide:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product Increment is created.

As I already explained in my article Scrum : The perfect day to start a sprint, the Scrum Guide let us free to do sprints from one-minute time to four weeks time. We could even do sprints of 3, 13 or 20 days –but I don’t recommend (see the article).

What’s the status?

Vincent Barrier, CEO of Kagilum, editor of IceScrum (which I recommend to give a try), kindly gave me the repartition of sprint duration amongs IceScrum’s users (as of March 2018) :

15% -> 1 week
80% -> 2 weeks
4% -> 3 weeks
1% -> other

We can see the overwhelming majority of the 2-week sprint.

Project management software, like Jira or IceScrum, have a default value of two weeks when you create a sprint in it. Could this influence teams to not even think about it and choose the default value? Possible.

A priori on one-week sprint

When I suggest to a new team to develop the product in one-week sprints, I raised some concerns.

  • We won’t have enough time to get a working product every iteration
  • We’ll spend to much time in ceremonies and preparations
  • We won’t be able to work on big features within one sprint

What I replied to:

  • Embedded features will be fewer and smaller
  • Ceremonies can —and should— be adapted. There are many, but they last less
  • The interest is precisely to get better at splitting big features

The result

As Rob Galanakis wrote, if my team works in one-week sprints , it’s to get very fast feedback. If your team works in three-weeks sprints while mine works in one-week sprints, we have three times the feedback and have three times the opportunities to learn and improve.

Instead of discussing whether we should try something, we test it immediately, empirically. This allows the culture of failure and greatly reduces its impacts. We eliminate the tunnel effect because we agree to consider the elements of the product backlog (before their arrival in a sprint, therefore), as options that can be questioned.

Items backlog are just possible options, as long as they are not embarked in a sprint

For the product owner, it’s almost impossible to add unready backlog items in the sprint. With a one-month sprint, you can be tempted to add a feature for which UI should be available “in a few days”. On one week, the risk is to big and it’s easier to wait for the next sprint (in a few days only).

For a team which is not at ease with Scrum yet, it’s also a better way to learn. Shorter iterations help the team to learn faster.

If Agile is all about feedback, then halving your sprint length gives you double the feedback and chances to improve. You can try something out for a week, find it doesn’t work, and move on without putting a release at risk. A sprint twice as long carries twice the risk.

The impact is not the same for everyone

For the Scrum Master, the cost of, per example, the retrospective is at least the same. The event itself takes less time, but the preparation needs to be more precise to make as many amelioration out, in less time.

The product owner must be particularly attentive to developers’ needs. They won’t have the luxury to say “we’ll see that tomorrow”. “Tomorrow”, it’s 20% of the sprint.

Finally, maybe it’s the development team which is less negatively impacted. We don’t ask them to work faster, on contrary, they have more freedom.

Conclusion

Sprints duration is not to be chosen because of the hype, or because you’re used to it.

For each new project, you should ask the question of the duration to yourself and to the team.

  • Can we get users’ feedback every week?
  • Is the definition of done allowing us to deliver every week?

Indeed, the first interest of short cycle is to have users’ feedback. If this is not possible for you to have some regularly, you should think twice before moving to a one-week sprint.

Some do it already without daring to admit it

A lot of teams which are doing two-weeks sprints or more organize “middle-sprint meeting”, or a “weekly meeting”. Why? To coordinate and to question itself. It’s a good alternative to shorter sprint, but one should ask oneself why not to formalize it as one-week sprints.

Shorter than one week

Why not going further to one-day sprint? A multitude of sprints, with regular stops  (every week per example), in order to inspect and improve, as we would do a “product retrospective” every 6 sprints or so.

What about you?

As we have just seen, although it is more intense for the Scrum Master, one-week sprint has many virtues:

  • Quick feedback
  • Allows for culture of failure and limit its impact
  • Harder to negotiate unready items into the sprint
  • The shorter the iteration is, the faster the team learns

Did you try one-week sprint? one-day sprint? Do you use it already? With which results?

Discover more:

The agile principle that gave birth to the most profitable toy franchise in history