Sprint Zero & Why you should NOT refer to it
What is a Sprint
As described in the Scrum Guide, Sprints are the heartbeat of Scrum, where ideas are turned into value.
They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
As a best practice, Sprint should include:
- Sprint Planning – To determine and agree on the sprint scope
- Daily Scrums – For team collaboration
- Sprint Review – To facilitate early feedback and adapt to changing requirements
- Sprint Retrospective – To encourage environment improvements
During the Sprint
- Sprint Goal is the focus with no changes that could endanger the Sprint Goal;
- Quality remains constant;
- The Product Backlog refinement is done as needed; and,
- Scope may be clarified and renegotiated with the Product Owner as more is learned.
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project.
Sprints help the team follow the agile principle of “Delivering working software frequently,”. It also helps the team to live the agile value of “responding to change over following a plan.” The scrum values of transparency, inspection, and adaptation are complementary to agile and central to the concept of sprints.
Sprint 0
In Scrum, each sprint is required to deliver a potentially shippable product increment.
Though Scrum does not limit use of any processes, techniques or tools, it is important to understand what exactly is Sprint 0 and what is achieved out of it. And most importantly, why are teams referring to this period of grouping a certain non-development activity as Sprint 0.
Teams often create it to better prepare themselves for the development and delivery. From the discussions on various forums, teams are creating Sprint 0 to create a vision, discover requirements, create rough product backlog, analysis of requirements, product road map, defining architecture, tech stack, applicable tools, UAT plan, etc.. For a moment, forget about Scrum and take the sprints out of the picture. Irrespective of the project types, wouldn’t you still be doing all these? If yes, when would you ideally do it; during the Planning phase or create a dedicated timeframe for it?
In a project following Scrum as the development framework, these activities are still applicable in respective phases to create the roadmap and determine the scope of initial 1-3 sprints and build on that understanding during sprint planning and continuous refinement. There are teams that even create Sprint 0 in the JIRA board and list these activities for tracking. Worse, they assign estimates to them. It is okay and necessary to do all these activities but without referring to them as Sprint 0 and making it part of your scrum board.
Projects following Scrum, often term this phase as Sprint 0 simply because of the buzz word and for the fact that the fixed length events in Scrum are referred to as Sprint. You can even find teams creating hardening and closing sprints.
Though Sprint 0 solves the preparatory goal, it defies the purpose and value of sprints that is delivering a potentially shippable product increment. Remember that requirement analysis and planning are part of the sprint and are required to lock the sprint scope but you cannot start from scratch and pick raw requirements on the first day of the sprint. If you are doing so, you are compromising the development time. Limiting Sprint Planning to the early hours of the very first sprint day helps you to strengthen the scope understanding, size and estimate the sprint scope. Continuous backlog refinement helps you to prepare for the upcoming sprints. Try to limit the Sprints for delivering value to the customers.
What should a Project actually do instead of referring to Sprint 0?
More emphasis on project planning is required. Project plan should consider these critical to delivery activities during the Project Planning phase. Deliverables from the discovery phase should at least include the architecture, delivery milestones, product definition and high level product backlog for at least 2-3 sprints. These are critical to start the next project phase. This approach is also important to clear any key assumptions and determine dependencies that might jeopardize the development at an early stage.
For some reasons, if you miss to scope these in the Planning phase, it is still fine to undertake them in a planned time frame but without tagging them as Sprint 0.
