Scrum : Effective Sprint Zero

Geert Bossuyt

What is it about waterfall we want to avoid ?   It's mostly the transition moments !   A lot of information is simply lost when you transfer it from one person to another.  Another thing we want to avoid is to create a strict order in things because this leads to limiting flexibility.  Still, Sprint Zero, is a commonly used practice, and it implies to happen before anything else right ?

So how to do a Sprint 0 in a smart way ?  Use these principles :

  • A length of more than 1 week for Sprint Zero is way too long
  • Spending half of Sprint Zero on training and teambuilding is only nearly enough
  • To do more than strictly needed to start the first sprint is too much
  • The outcome of Sprint Zero is a jump start for Sprint One.

Yes !  Heartbeat is important !  But Sprint Zero is the exception.  The shorter the better.  Starting Sprint Zero on wednesday and start Sprint 1 on next monday would be completely acceptable.

Yes ! Shippable code is the outcome of every Sprint !   But Sprint Zero is the exception.  Use Sprint Zero to get to know each other.   Build a Team, before building Software.    Admitted, you can't build a team in 5 days, but you can make a start.     This start can make the difference between becoming a Team and stay a bunch op people.

Yest !  Keep the end in mind !  But don't postpone starting until you understand the end.   Inspect & Adapt.  Whatever you do, the end will change because of the things you learn along the way.

To have an effective Sprint Zero can be very important.   Most people involved will have read something about Scrum and what they remember is that Scrum is Agile and that the Team is self-organizing in combination with a strong focus on delivering software.     To have a Sprint Zero of 3 weeks then would kill any enthusiasm and faith in whatever principle of Scrum or Agile.

Agile states that individuals and interaction are valued over processes and tools.   It's true !    You can invent any kind of process with any number of tools, without the right people interacting, the process will never work and the tools will not be of great use.   Even so, a set of individuals is not winning the game, to make a Team out of a number of champions is what really makes the difference.   Make time for this in Sprint Zero, because later on, you risk not to have any time for this.

Architecture and tooling are important assets to a successful software delivery team.  Building software and learning from that, however, is more important.   Keep in mind that if you can't imagine the architecture in 2 days, it won't be much better after 2 weeks.   While developing and exploring the stories, the best possible architecture will emerge.

How does an ideal Sprint Zero looks like ?

In the Ideal Sprint Zero the entire Team sits together for 3 consecutive days.

  • The first day to have a day of training about Agile and Scrum.   It's important that this training is followed by the entire Team and that the trainer has some attention for the team-building side of this training day.  Team Rulezzz and Definition of Done should be part of the Training day.
  • The second day to examine the backlog.   My assumption is that the ProductOwner has already prepared the backlog and that the Team only needs to validate the quality of the backlog.  However, even if this is not the case, the Team and the ProductOwner should be able to create enough backlog for the first Sprint.   The ProductOwner has the vision / ideas, the Team feels the need to make things specific and therefor asks the right questions.    Spending more than one day on the creation of the product backlog would be a waste of time for the Team.   This is the job of the ProductOwner and should not be of any concern to the Team.   Since we're talking about the ideal Sprint Zero, the quality of the backlog that high, that half a day will be enough to determine that the user stories are good enough to poker and commit upon.   This way,  the second half of this day can be used to poker the highest prioritized changes.
  • The third day is needed to end Sprint Zero.   In other words,   this third day should make sure Sprint 1 can be started the next day.    If Team Rulezzz or Definition of Done is not addressed in the Training, it should be addressed now.   If planning for Sprint 1 has not yet been done, it should be done now.   Make sure there is time left to build the Team.   Get to know each other.    There are some nice exercises to trigger some interesting discussions and still focus on the Agility of the Team.  ( Upcoming blog ).

The world, off course, is not ideal.   Still, the principles are to be kept in mind.   And with these principles in mind, you'll find out that the world is more ideal than you thought. 🙂

Comments (6)

  1. Scrum : Effective Sprint Zero - Reply

    February 1, 2011 at 4:12 am

    [...] to another. Another thing we want to avoid is to create a strict order in things because this... [full post] Geert Bossuyt Xebia Blog 0 0 0 0 0 [31 Jan 2011 [...]

  2. Tarun Sapra - Reply

    February 1, 2011 at 6:35 am

    A nice introduction to importance and effectiveness of Sprint zero, the emphasis on team building during Sprint0 is very relevant as software development is a team effort. Also I would like to add, that activities related to setting up software infrastructure for the project i.e. Softwares like JIRA, Hudson, Bamboo Confluence etc should also be inculcated in the Sprint Zero.

  3. [...] This post was mentioned on Twitter by Arnon Rotem-Gal-Oz, Guillaume BRETON. Guillaume BRETON said: At least somebody has some advise about sprint 0 : Effective Sprint Zero [...]

  4. Geert Bossuyt - Reply

    February 2, 2011 at 6:13 pm


    Agreed. And my advice remains to keep Sprint Zero to 1 week. Even when setting up the right tooling is costing you more, then please start and add the right tools along the way.

  5. Obaid Malik - Reply

    February 6, 2012 at 11:10 am

    Nice post.
    It's also come under discussion that the convention of naming it as "Sprint Zero" gives the feeling that somehow it's not really part of the sprints, and further exaggerates the misconception that an initial analysis is "Waterfall-ish", and somehow SCRUM is trying to adjust it into it's sprints while pretending not to be doing so, while SCRUM never states that there should be NO ANALYSIS upfront, just that it's "silent" on it (and understandably because every project and team is different) and leaves it up to us to decide. Is there anything wrong in just calling it as SPRINT ONE, like any other sprints?

  6. Danny - Reply

    June 19, 2014 at 2:39 am

    If some one wants expert view regarding blogging afterward i advise him/her to pay a visit this website, Keep up the pleasant job.

Add a Comment