Scrum Does Not Have a “Sprint Zero”
Sprint Zero: Sprint Zero is the time used to plan and set-up the foundation needed before a team can execute their first successful iteration. Sprint Zero deliverables may include: identify stakeholders, build the team, training, create high-level architecture diagrams, and set-up environments.
It’s become quite common for Scrum teams to begin by planning Sprint Zero. I’m not sure if you’re aware, but Sprint Zero is a bit of a debate topic at times. I’m often asked what my stance is when it comes to Sprint Zero, and I struggle a bit since the real answer is this: it depends.
I know it seems like answering with “it depends” is totally punting and not helpful. However, up-front pre-implementation activities vary greatly depending on what is being built.
1) Large Mission Critical Enterprise Applications
Assuming this is creating something that didn’t exist before, or re-building something that is legacy, I would start with a small core group of “key” people. An enterprise architect, a business leader (Product Owner, perhaps) – the person who owns the vision of “why” we are doing this, possibly some key stakeholders, etc. Ideally no more than 5 people. In this case, this small core group would determine the answers to the questions you ask and then figure out the best way to execute.
Activities would include: determine how to and then get started on setting up environments, technology, CI strategy, training, change management, etc. This small team would also come up with a strategy on how to assemble Agile teams.
I would not call this a sprint zero. As has been said before, it’s not a sprint as defined by Scrum, so let’s not pretend it is.
2) Small – Medium Projects Using Existing Technology
As you all know, these come and go. This is the steady stream of new feature requests that come from the business. It may take just a couple sprints to deliver, or it may take 10 sprints. The number of sprints is irrelevant in this case. There is still no need for a sprint zero. Just spend some time creating the product backlog and start. Business as usual.
3) New Product or Start-up
I have been involved in quite a few start-up ventures as a Scrum Master or as a developer. We start small with a vision (that’s typically been baking for some time) and a quick technology conversation, then we start executing. We have passionate people who all are trying to achieve the same goal. Yes there’s “up front” stuff, but it’s super quick…as in hours. In no way would I consider it a sprint zero.
Ultimately, I would love to eliminate the term “sprint zero” from our nomenclature. Upfront activities (other than release planning) should only be reserved for contexts where complexity, breadth of impact to the enterprise, and cost are all high.
For agile training check out our list of courseware, we would enjoy helping you on your agile journey.