I have never been a big fan of the concept of Sprint Zero.  Recently, I heard a story from a colleague that got me thinking about Sprint Zero and I wanted to share her story with you.  She told me on the first day of working with a new client she was invited to attend their Sprint Review.  Excited by this opportunity, she sat down in the conference room (only a little bothered when the lights were dimmed) and the first slide announced the results of Sprint 0.21 – they had completed 21 Sprints without producing a single line of code!

This is the first time I have heard of something like that and I bet there are other tales of woe waiting to be told.  I share this story to warn you of the peril Sprint Zero since it is so easy to fall back into old habits when starting with Scrum.  Here are my main reasons why I avoid Sprint Zero.

1. The amount of time dedicated to a Sprint Zero is usually not sufficient to complete the activities necessary to kick-off a project with a reasonable amount of complexity.  Unless the project is trivial and involves only a single team, two weeks is not enough time to go from nothing to prioritized Product Backlog.
2. Sprint Zero is a trap based on the old mentality that if we just sit down for long enough, we can figure out the perfect plan for the software.  There are no perfect plans for software and to persist in this myth, in my opinion, is irresponsible.
3. There is no software delivered at the end of Sprint Zero.  If you are not producing potentially shippable software at the end of each Sprint, you are not doing Scrum – period.  EVERY Sprint must produce software.

While I don’t like the concept Sprint Zero, for some larger projects I recognize that we still need to complete some of the activities people normally do in something like a Sprint Zero.  First, I call this process Lift-Off, Initiation or Elaboration.  This is the process where you create and prioritize the initial Product Backlog, select the Team, identity any infrastructure you may need to support your product (or the Team) and create a product roadmap.  Second, during this process of Elaboration you do not need to use Scrum.  You could use Scrum or you could run this like any other project in your organization with a project manager and everything.  I hope you would use Scrum principles like short timeboxes, dedicated cross-functional Teams and iterations, but that is up to you.  Third, this process is short – from one to six weeks – with a preference for the shorter timeframes rather than longer timeframes.  If you feel a desire to spend more time in Lift-Off, I encourage you to give up that old mentality that we can build the perfect plan, requirements document and\or design.  They do not exist.

These are my steps for initiating a single team.

1. Select the Product Owner: this is the most important role in Scrum.  Without a Product Owner, Scrum does not work.  If the Product Owner is not empowered to make choices on behalf of the Stakeholders, then the Team will stall.  It is important to choose wisely in this step since the Product Owner will set the tone for the entire project.  Pick someone who is passionate about building products, likes to work with technical people and is available.  In addition, you need to choose someone with business maturity, is respected and trusted by management and the Stakeholders and can make decisions with incomplete information.
2. Create the Vision with the key Stakeholders: the next step to Lift-Off is for the Product Owner to sit down with the key Stakeholders and draw out their Vision for the product.  What do they hope to achieve with the product?  How will the product make an impact for them?  How will the product make this lives better?  Articulating the Vision is crucial since it serves as basis for all project metrics – are we going to deliver the Vision or not?
3. Select the ScrumMaster & key Team members: now that we have a Vision, we are ready to think about who will be the key contributors to the project – tech leads, testing leads, architects, business analysts, graphic designers, etc – and the ScrumMaster.  In selecting the key Team members, we want people who are experienced in the product domain and have many years building software.  As for the ScrumMaster, the skills I am looking for at this point are someone who is organized, focused and can facilitate large groups of people.  If you want, you can also make the choice of ScrumMaster and Team members in Step #1, but you cannot advance from this step until you have a list of  names for the ScrumMaster and the key technical contributors.
4. Write the Product Backlog & Identify Infrastructure Needs: this next step is where the bulk of the work happens.  This is where the Product Backlog comes to life as the Team, Product Owner and ScrumMaster write the Product Backlog in a series of workshops.  This step is a period of lightweight analysis, design and experimentation.  In these conversations, the Team should consider design alternatives, technical risks and any hardware, tools and infrastructure they might to build and support the product.  At this point, you may even choose to bring in subject matter experts for the Stakeholder community in order to validate the requirements and scope of the product.  In addition, the Product Owner along with managers should think about project metrics, communication and any organizational infrastructure needed to support the Team (desks, computers, workspace, etc).  This process is complete once the Product Owner and the Team have identified between 60 to 100 items in the Product Backlog.
5. Finish Selecting the Team Members: once we have an idea about what is in the Product Backlog, we can now have realistic conversations about exactly how many developers, testers, business analysts, etc  are needed to deliver on the product scope.  We might find out that we need more than one Team.  This is also the time to discuss the percentage allocations of specialized roles like DBA, architects and others.  These discussions are mostly held between the Product Owner, technical management and other managers who normally participate in these conversations
6. Create the Roadmap: at last we come to the final step of Lift-Off – time to create a roadmap.  The ScrumMaster and the Product Owner bring together the Team and the Stakeholders to discuss their plan to deliver a product that will meet the Vision defined in Step #2.  During this meeting the Product Owner will explain the Sprint Goal for each Sprint and Team members will identify any concerns, risk or issues they would like the Stakeholders to resolve before blast off.  This meeting should be a dynamic, interactive session with the full participation of the Stakeholder.  We need their input to validate the Sprint Goals, key Product Backlog items and the order in which they are delivered.

If the Stakeholders approve the roadmap, we have launch.  There are a couple of options to launch at this meeting.  One, the Stakeholders could see the roadmap and decide not to invest the money in the product.  OK – better to be canceled now than after you have spent 10 months of money.  Two, the Stakeholders ask the Team to rework the Roadmap or reduce scope.  If the adjustments can be done in the meeting, we will make the changes.  If not, then the Team will ask for some more time (no more than a couple of days) and come back with a new roadmap.