Scrum : Effective Sprint Zero
Join the DZone community and get the full member experience.Join For Free
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 leeds 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 then 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 then strictly needed to start the first sprint is too much
- the outcome of sprint zero is a jump start for sprint one.
yes ! harbeat 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 accepted.
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 frist 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 thins specific and therefor asks the right questions. spending more then 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 then you thought.
Opinions expressed by DZone contributors are their own.