Designing systems that work.
Contact us to get started today.
Sprint 0 + Why?
Pam (one of our Scrum Masters) and I were having a chat about this over lunch yesterday… apparently the sprint 0 concept has been bandied around the Agile community so the concept itself, even the terminology, is not foreign… When I was thinking about sprint 0 there were several motivations.
- Architecture in Scrum is almost non-existent. This is a HUGE omission. Some sort of foundation needs to be laid down in order for the team to not spin wheels later. What are major architectural concerns? Be explicit. What kind of automated testing framework are we going to use? Why? On and on… This is not to say that things are fixed in stone after sprint 0, on the contrary. However, we have done the hard thinking so that if we need to adjust, we have a solid basis to do so. That reduces spinning of wheels.
- We are a services company not a product company and this is very significant. We are often engaged by customers who are not familiar with Agile and Scrum. In order to not spin wheels, we need to ramp them up through training. We need to set a baseline of understanding so that communication is fluid in the later sprints. If there is misunderstanding or disagreements, we can then go back to the baseline and guide the team back on track so they can focus.
- Often there isn’t sufficient planning done prior to sprint planning. People just jump in and quickly start to spin wheels. They do not get into the right mind-set of having an intense, time-boxed session to drive clarity. As a result, the planning session is not fruitful, which results in quickly diverging away from the Scrum methodology. The sprint 1 planning session is essential as it sets the tone early! A part of sprint 0 is to ensure that the product backlog has been priortized properly and the product owner and the team gets into the right mind-set prior to the important sprint 1 planning.
- Sprint 0 has clear deliverables. These deliverables are of value. They may not be in terms of executable/testable software but they are of value.
- Sprint 0 should also be time-boxed. Time-boxing promotes focus and Scrum if anything is a methodology to synchronize and focus the team towards a clear goal in the most efficient way possible.
- Calling it “sprint 0″ also is significant. We are executing on deliverables. It is time-boxed. We need to be focused. Naming it something else takes away from that urgency and focus.
Should you have a sprint 0 all the time? It depends… However, for all but the simplest projects I would recommend thinking about sprint 0 explicitly and determine if it is of value.