The stages of the Sprint Zero

Nowadays everything related to a project tends to be product-oriented, and all surrounding the product management cycle is linked to agile processes. Today, we are talking about a small piece of this broad framework called agile in terms of how to design a user-centred product.

If we compare to other agile techniques like Scrum or just product design, we can easily realize the difference in search trends. If we just make a loop in sprint zero, it's distributed over time, which can result from a lack of knowledge in the market.

The objective of this post is to centralize the information about sprint zero and share the approach we follow at Wealize to help other sprints zero champions.

What's Sprint Zero?

The Sprint Zero is an extended work process used in digital product studios that consists of applying an iterative process of discovery, definition, and design to a new business or existing product. For the matter of this article, we are considering only new business in the following lines.

Sprint zero is the working method to reduce uncertainty in the product design and development processes that invokes complex processes or technology.

The main objective is to asset a product backlog detailed at the user story level that is aligned with the business objective and covers all the functionalities defined for the product. This results in another key asset to understand better the product: an interactive prototype.

Why Sprint Zero?

Everyone who has spent years working in professional services knows about the difficulty of establishing an accurate scope when we are planning projects. This can get complex when we work with businesses in the ideation phase and require complex user flows or the use of technology.

The Sprint Zero is a dynamic alternative to statics RFPs or traditional product/services sheet, that pretends the reduction of the uncertainty cone in software development projects, by taking the proper time to analyze the business, define the user's interactions, design prototype and decode the pieces of the product into user stories conforming a detailed product backlog.

Imagine what? After having this time to work as a team and with stakeholders or owners, we have a prototype that's aligned with the business objective, a user-centered prototype that stakeholders can test, and a detailed scope of the product development phases within a product backlog organized in a roadmap or releases so we can start working with both squads at a high grade of confidence.

At Wealize, we've tested and validated that customers that onboard on this working process felt after it to have a better understanding of their business, the value of having an interactive prototype to share and that those factors help in the early stages of a business fundraising.

Framework

The main objective is to asset a product backlog detailed at the user story level that is aligned with the business objective and covers all the functionalities defined for the product. This results in another key asset to understand better the product: an interactive prototype.

Thus, we work in different stages during the period of 4-6 weeks to understand the business value, translate it into product requirements, and design a solution we can test.

The approach for a good sprint zero execution is based on the decision-making framework promoted by HCD and relates to every week or stage of the cycle.

For this matter, we identify 3 key elements to succeed in a progressive execution of the sprint zero which reflects on the following weekly working sessions to use as a reference:

• Customer working session for discovery.
• Team working session for loop.
• Customer working session for validation.
  

Stages of the sprint zero

The purpose of defining certain stages during sprint zero is to be able to create a relation about every phase, in terms of time and delivery. Thus, each stage is related to one week of work with the variable mentioned above taking (1-2 weeks) place during stages 2 and 4.

1. Inception

The main objective of the first week of sprint zero is to ensure teams and stakeholders are on the same page regarding the business goal.

The deliverable can be a written business landscape based on the most relevant areas of a new business: background, business objective, problem, solution, customer persona, competitors advantage, and technology.

To gather this information from the customer, we can perform a business interview based on the business model canvas' relevant streams or asking the 5Ws of the business.

2. Definition

The main objective of the second stage of sprint zero is to translate the business requirements into functional needs from a user-centered point of view.

For this need, we are focusing the working sessions on two main works: user flows and user story map. The USM is a great technique we use transversally when we work with products, but I'll talk about this in future posts.

The deliverables of this phase are both a users flow and user story map board validated with the stakeholders. We like to use Miro so we can keep it alive with customers' feedback and comments.

3. Design

The key result at this stage is to build an interactive prototype and define a solution architecture to base the application.

After validating the product backbone with the customers, we feel confident enough to build an interactive prototype coming with iterations low/mid-fidelity and ideally ending with a high fidelity prototype.

On the technology side, now that we understand both the business and the product, we can draw a solution architecture drawing the IT infrastructure with the requirements registered from the customer and our advice - you might have your favorite cloud service provider.

4. Refine

The key outcome of sprint zero comes here when we loop into the functionalities and user’s tasks to write the user stories to facilitate the development flow.

The deliverable is a product backlog detailed at the user story level, ideally with the suggested implementation and acceptance criteria, organized by product releases or feature roadmap.

Now both the squad and the stakeholders can have a more accurate scope of the product development phases that unlocks time and money questions that arise during the first steps of a new business.

Conclusions

Some customers may have a clear vision and definition of the business to work throughout a traditional process of requirements gathering and request for proposal. But those, innovative ideas, that are looking to become a reality, and have an impact on thousands of business users need a curate phase due to understanding the right problem we are solving for them.

Founders or decision-makers that have been through sprint zero or related methodology, confess to feeling more prepared to start a new business or initiative in their companies, even if the development phase is delayed.

For teams, developers and designers feel more confident and motivated with the product development phases, not only by having a detailed registration of tasks but having been working in their specialty and plugin those skills into the sprint zero execution and delivery.