Sprint Zero is becoming a very popular practice in the organizations where Agile and Scrum are used. Sprint Zero is not a part of the official Scrum framework, where it is mandatory to have a working and usable increment of the software at the end of the regular Sprint. Therefore there is no official definition for Sprint Zero even considering there are plenty of articles on the topic. Because Scrum was inherited fr om an Empirical Research method we can surely say that Sprint in Scrum is like a controllable and time-boxed experiment to validate the hypothesis of the Sprint Goal with measurable outcomes at the end of experiment. This makes the process of development highly transparent in the dark cloud of uncertainties. Given the various ideas circulating about Sprint, it is important to clarify that Sprint Zero is not a Scrum sprint at all, this is rather a time-boxed pre-scrum planning workshop. Further in the article we will investigate the value and the power of Sprint Zero.

One of the best formats for Sprint Zero was suggested by Jeff Patton [1]. It was designed for collaborative product discovery to plan Agile projects. Whenever Sprint Zero is mentioned you can refer to the Collaborative Product Discovery workshop. Collaborative product discovery is especially valuable for organizations where business and development teams are sitting in different locations and regular business trips to off-shore locations is expensive for the budget. In such dispersed organizations the planning mostly is done by phone calls between people who are barely involved in actual development. This causes many misunderstandings, misinterpretations, miscommunication and other kinds of "mis’s." Such circumstances usually lead clients to plan off-shore business trips aimed to fix annoying "mis" perceptions and in many cases supplemented by a chaotic agenda.

Sprint Zero Workshop


The Collaborative Product Discovery Workshop or Sprint Zero has a clear agenda. It requires people fr om the business and development team to be in the same room for at least for a one week. They are:

  1. Doing collaborative product discovery for the next 6-9 months
  2. Discovering just enough technical complexity to achieve 6-9 months of business goals
  3. Discovering the process, practices and elaborating working agreements
The goal for the workshop is to create a truly shared version of product backlog, release roadmap, assumptions and working agreements. This will create so important momentum for the development team and will further serve to avoid any kinds of "mis’understandings" between developers, managers and business management. Investment in such business trips provide a sense of satisfaction and great value.

At Luxoft, I think we've got great experience in the facilitation of such workshops. Our first attempt was with Hotwire teams in 2012 wh ere we learned how powerful and valuable it is when developers and business people discover together what to do, why they do it, and how to develop valuable software for end users. The most recent example of the live Sprint Zero Workshop we conducted with one of the scrum teams of a major investment bank. Via this example I will try to explain step-by-step approach to Sprint Zero.


The story begins with when a business requested to develop a new application. They handed over development to the Luxoft Scrum Teams and reasonably requested estimates and a project roadmap as the scope was pretty fixed. After several weeks of investigations developers still were not comfortable to provide any estimates because of large amount of uncertainties and open ended questions. In this situation we suggested to management to try a Sprint Zero Workshop as an experiment. The goal was to get initial estimates and release a roadmap for the next 6 months of development. Because Sprint Zero is a discovery workshop it did not require any specific preparations except the training I conducted for developers in order for them to understand the nature of relative estimates and essentials of Agile planning. The only condition was to get a person who knows the business well and will enact as a Product Owner for the Scrum Team. We prepared a one week agenda for a Sprint Zero Workshop that consisted of 16 steps.


Step 1. Vision, Users.

We started the Sprint Zero Workshop with a brief presentation to the application domain wh ere the Product Owner explained some theory and basics of the business domain. After that we created a shared vision statement for the product for the next 6 months [2]. Then we continued to discuss our potential users, their current needs and pain, as well as their objectives and habits. This process helped us to discover potential functionality for our users. This exercise is very important as a very first step. If you do not have an understanding of the purpose and success criteria for the new application the workshop cannot be effective.

Step 2. Initiate Story Map


On the second day, the team with the product owner was discovered and explored product capabilities and functionality using a Story Mapping technique. It was a great moment to identify what is missing in the big picture, what is relevant or irrelevant for the 6-month vision.


The first row of the story map (which is enclosed in blue rectangle) describes the main application capabilities. Capabilities are ordered on the map from the end-user perspective which helps to discover user actions in the right order. Capabilities are labeled (pink, blue) with types of work which is required to deliver them (Java, Oracle , OBI).

Below capabilities, we discovered what kinds of tasks the end user is going to perform within given capabilities. We call this functionality. The first level of tasks (red rectangle) is describes the most common workflow. The other levels (below red rectangle) describe alternative workflows. All workflows are sorted vertically by their necessity.

Step 3. Finalize Story Map.


After filling the Story Map with capabilities and functionality that is known we started to do the following:

  1. Identify potential or missed capabilities and functionality (blue rec.)2. Put architectural and technical assumption on orange stickies (orange rec.)3. Telling and debriefing the whole picture4. Some functionalities were grouped into potential User Stories (red rec.)
  2. Put architectural and technical assumption on orange stickies (orange rec.)
  3. Telling and debriefing the whole picture
  4. Some functionalities were grouped into potential User Stories (red rec.)
Step 4. Create a User Story board


The “Idea” of a Story Map is to facilitate effective discovery of the needed functionality from the end user’s perspective. But it is not a goal in itself. AStory Map is used to collaboratively create a first set of User Stories relevant from business and development perspective, grouped by capabilities, which in turn appeared in JIRA as Epics. Some additional Epics were identified and added to JIRA.

Step 5. Validate technical and Architectural Assumptions

On the video conference call with the Architect team we validated technical and architectural assumptions. It was strongly recommended to have an Architect physically present during the Sprint Zero, but unfortunately at the last moment due to a valid reason he was unable to be present. Nevertheless, he was able to participate via distance conferencing. He reviewed the validity of all technical assumptions which in turn impacted estimates.

Step 6. Elaborate Acceptance Criteria


The Team together with the PO elaborated the high-level acceptance criteria for each User Story just enough to provide high-level estimates. On the picture you can see how PM, of our customer, documented acceptance criteria in JIRA.

Step 7. User Story Sizing


Having User Stories with validated technical assumptions and validated acceptance criteria should be enough for the User Story sizing. You can see that the team started to layout User Stories in a sequence ordered by relative size. The smallest user stories appeared on the left side of the queue whenever the largest was on the right. This is a highly collaborative exercise. Only the development team is allowed to participate in this step, the PO may observe and should be available to answer or clarify acceptance criteria. Sizing ensures that developers actually investigate the acceptance criteria.

Step 8. User Story Estimation


Having an orderly queue of user stories by its relative size simplifies the process of relative estimation in story points. On the picture you may see that for relative estimation we used a Fibonacci sequence. The Team is comparing and specifying sizes using story points. Also during this exercise the team identified Spike User Stories (light blue stickies).

Step 9. Release Roadmap Drafting


Having all user stories estimated in relative story points should be enough to figure out first draft of the release roadmap. In this case you may find 6 monthly releases (blue stickies on the first row) packed with User Stories so that each release is evenly loaded.

Step 10. Release Roadmap Learning


I think this is the most interesting step because:

  • Team started to learn what are: Balanced Potential Releases, User Story Priorities and Delivery Risks• This is the point when the team is forecasting its own velocity and releases should be balanced according to the expected velocity• User Stories which were sized as “13” and “20” are the first candidates to investigate and split into smaller User Stories• Need to find a way to deliver large User Stories in multiple releases
  • This is the point when the team is forecasting its own velocity and releases should be balanced according to the expected velocity
  • This is the point when the team is forecasting its own velocity and releases should be balanced according to the expected velocity
  • Need to find a way to deliver large User Stories in multiple releases
Step 11. Working Agreements and DoD


This was the last step but still is very important because the team has to discover the process which would fit the best for them to deliver valuable software. Business people should understand that the obtained roadmap release is not a plan to which the team can commit. After this the first real Scrum Sprint Team will learn what is their actual velocity and this may lead to revisiting the release roadmap. This needs to be very clear both for development and business sides.


The Sprint Zero Workshop is not a silver bullet. It does not guarantee estimation accuracy and plan precision but it does give great momentum for developers and business. It will provide transparency from the very beginning enabling all participants and key people to be on the same page and thus reducing the number of potential miscommunications, misunderstandings, mis-, mis-, and mis’s .....