The intent behind "Sprint Zero"
Mike Bowler
Helping organizations improve how they deliver value for over 25 years. Using a mix of agile technical practices (XP), workflow design, and applied psychology/neuroscience.
Several of the agile methods develop software in time boxed periods called sprints or iterations.
I’ve run into a number of cases recently where the term “sprint zero” was being used in unexpected ways. For example, I had one person tell me recently that in sprint 19, they were still doing “sprint zero activities”.
So let me clarify what exactly I mean when I say sprint zero (or iteration zero). In every sprint, we are expected to deliver business value. This is a key piece of working in an agile fashion - we are always delivering things that are valuable to the business. Some sprints we deliver more value and in some we deliver less but we are always delivering something of value to the business.
When a team first kicks off, there are often a large number of setup and configuration type things that need to be done before we’re able to deliver something useful. We need to get development environments configured. We need to set up some servers. We need to get permissions for various environments. There are often so many of these things that it’s hard to deliver something valuable to the business at the same time.
So we’ll often give one free sprint in which the team is not required to deliver any business value at all. One sprint in which they can focus purely on technical setup and configuration. This is “sprint zero”. Once it’s over, every single sprint after that is expected to deliver something of value to their business.
How long is sprint zero? It’s the same length as all the other sprints. If you’re normally doing a two week sprint then you can have one two week sprint to get stuff up and running before turning your focus to delivering value.
Is technical setup expected to be perfect at the end of sprint zero? No, you had a head start on technical considerations and now you build out the rest at the same time that you’re delivering value.
That’s all sprint zero is. It’s a head start on some of the technical pieces. Now let’s get back to being focused on what our customers need.
Lean/Agile Process and Architecture Coach
9yI don't care how you number them as long as 1. Sprints don't change length, and 2. Every Sprint creates a potentially shippable increment that elicits feedback from the end of the value stream. Too often Sprint 0 is an excuse to violate one of these, or both. There are Scrum activities other than Sprints. POs might work 1 - 6 months — or as long as six years, as Jeff Sutherland found with one of his teams — before you run the first Sprint. POs don't run in Sprints. I think there is a set of people who don't understand this and that's one of the sources of confusion about Sprint 0.
Retired and still not completely adjusted to it
9ySprint Zero? What do you call the business approval / funding process for getting the thing started in the first place? Sprint -1?
Program Director, Agile Coach Camp Support Initiative at Agile Alliance
9yMy preference is to make this a part of Release Planning, which I scope-box, rather than time box. I also stress to teams that while it is scope boxed, part of the Release planning is a defined start date to which they commit to meeting. Then they aren't overly 'rushed' and thus have time to get it done, yet still have some pressure not to take too long. Just my $2 (inflation you know...)
I'm complicated: business leader, technology practitioner and people-inspirer - I fix productivity/efficiency problems in your organization. I do speaking, training, consulting and coaching on Agility, Innovation and AI.
9yI did a video on this recently: https://www.youtube.com/watch?v=fBIztji0AOc - I really don't like calling it a "Sprint" because the definition of the word, when used with Scrum includes the idea of delivering business value. I like the concept of a very very very VERY short time-boxed period of preparation between projects or releases, but I would prefer that people call it something else. To Dick Carlson: far too many projects fail because of TOO much project preparation, IMO. Where are the numbers? The Standish Group Chaos Report numbers show that Agile processes used to run IT projects results in a success rate 2.5x that of traditional methods. Some of the best case studies of Scrum are when it is used to break the traditional project preparation work: look for stories about the Federal Reserve Bank, Charles Schwab (2002-3), Capital One (2005), Siemens Trango (2006), etc. etc. I'm surprised at your comments considering the "Lean" part of your organization name. Project preparation work is almost exclusively NVA work and should be minimized as much as possible.