Sprint 0

[erik_scheid]

What's a Sprint 0?

A Sprint 0 is an iterative approach in which we work together with customers to discover, describe, and validate the requirements for a solution. Sprint 0 is based on Design Thinking, UX design, and agile Requirements Engineering. When you finish a Sprint 0, you should have a Vision & Scope document and an initial backlog.

In a Sprint 0 and in the subsequent development project, we have to focus on the following:
* Viability: There are business reasons for doing the project. Some business value is to be produced and achieved. This targeted business value is always in focus and should be validated in a Sprint 0.
* Desirability: Human factors also play a role here. Humans will be using the software and humans will decide whether we receive the contract for the project. So, Sprint 0 is also a pre-sales activity. Desirability helps to sell.
* Feasibility: But what if you're targeting a great business value with a great UX experience, and there's either no technical way to achieve it or the costs are too high? This is why we need to keep the technical feasibility in mind as the third aspect.

It's not easy to achieve these three goals - viability, desirability and feasibility - at the same time. We'll explain how the iterative approach used in a Sprint 0 can help you get there, and we'll give you some tools and techniques to use on the way.



A Sprint 0 offers a number of positive aspects, both from the customer's perspective and from our perspective as a software vendor.

Validated Learning
* Sprint 0 entails a lot of Value Engineering. For our customers, Sprint 0 allows them to define the business value to be created and give feedback, for example, about prototypes or mock-ups of the planned solution. Customers can validate the solution early on and actively optimize the business outcome.
* For us, a Sprint 0 helps validate our understanding of the customer's requirements and our proposed solutions.

Decreased Entry Barrier
* For our customers, a Sprint 0 requires a much lower investment than what's required for a big project. They can validate the future solution without a large initial investment.
* For us, Sprint 0 is a foot in the door to get the follow-on project.

Tangible Results
* For our customers, a Sprint 0 produces tangible results in a lean and agile manner. Customers can give feedback early. They can also use these tangible results to sell the project internally to the relevant stakeholders.
* For us, we get early feedback. We can also check the technical feasibility with prototypes. We can wow the customer by delivering results faster and perhaps even above their expectations.

Mitigated Risk
* For our customers, the iterative approach of a Sprint 0 lets them give feedback early on and mitigate risk. Prototypes or mock-ups that are good enough for a round of feedback can be developed quickly and easily. This is much faster and cheaper than developing production-ready software and gathering feedback during the acceptance test at the end of a cost-intensive development phase.
* For us, a Sprint 0 provides a much better understanding of the requirements than the usual evaluation process. Closer collaboration with the customer gives us much more feedback early on.

Trust and Established Working Model
* For our customers, a Sprint 0 lets them gain trust in how we work and in us as a team. It also establishes a working model between the customer and the project team.
* For us, a Sprint 0 allows us to show our customers how we work and prove that we understand their needs.

Sprint 0: One Approach, Many Flavors

Each Sprint 0 can differ greatly due to a range of factors. Depending on the complexity and number of roles involved, you might need more or less time. The architectural complexity and the technical feasibility can also vary greatly. UX might be the main focus or might not be involved at all. Many other aspects can differ in each Sprint 0. But one aspect is always the same: the iterative approach in which we work together with customers to discover, describe, and validate the requirements for a solution. When we do Value Engineering together with customers, the situation determines how we do it and the tools we use. At the end of the Sprint 0, we want to know that the requirements are good enough for us to make a binding offer. We want to validate the proposed solution before the follow-on contract is signed.



Another aspect of diversity comes from Design Thinking. A diverse team is one of the three pillars of Design Thinking. A diverse team is also crucial for Sprint 0. In particular, this means including end-users in addition to the Sprint 0 team. Involving people with different backgrounds and skills in the iterative process is key for the success of a Sprint 0.

Tools and Methods

Value Engineering in Sprint 0

Several rounds of build, measure, learn are conducted here. In the beginning of Sprint 0, you get an initial understanding of the personas, storyboards, and value proposition. This makes it possible to plan the contextual interviews with the different user groups. Then you can refine personas, storyboards, and value proposition in the synthesis and iteration workshops. In these workshops, you also start the user story map and architecture vision. Based on the contextual interviews for selected processes, you can also create UI wireframes (or even visual and interaction design) and validate them with end-users. All these paper artefacts are refined based on the feedback received. The results are validated again and finalized in a second round of iteration workshops.

UX Tools and Methods

Sprint 0 is the starting point for a user-centric design. The interactive nature of the Sprint 0 allows you to identify the different personas (user groups) involved in the business processes. You can observe them in their context and visualize and plan the future processes. End-user research provides the basis for defining user stories and the UI design.

Customer Journey Map and Storyboards

Interaction with the end-users is also the basis for designing the future processes. The goal of a customer journey map (CJM) and storyboards is to understand together with customers the “journey” of end-users in the future solution.

Here's an example of how you can create a storyboard using Scenes.

User Story Mapping (USM)

User stories are the preferred way to describe the backlog in Sprint 0. You can use User Story Mapping (USM) as a team internally to map your backlog and gain an overview of the scope. In addition to the mapping, you can use USM to prioritize user stories. You'll prioritize for each column in the map. You can then rank the backlog items and start to plan your releases by drawing lines in the USM.

Evolving Architecture

The feasibility aspects that we mentioned in the beginning have not been covered so far here with the tools and methods. Feasibility starts with looking for and planning the architecture of the software system that realizes the solution planned in Sprint 0. In this early phase of the project, when you've just started to discover and describe requirements and you're still looking for solutions, the architecture will certainly not be finalized. Still, you should start planning the architecture in the same iterative way in which you're progressing in Sprint 0. This will result in a planned and validated architecture - the intentional architecture. This will be validated by the development team, based on the known requirements and evolved during the project's lifetime.

Software Prototypes

Prototypes can also help you check feasibility. The purpose may be to check technical feasibility or performance aspects. You can also use prototypes to check whether an algorithm proposed for a computation in a data science scenario yields the expected results.

In Sprint 0, you can use software prototypes to do the following:
* Better understand requirements
* Make requirements tangible
* Eliminate risks

Structure of a Sprint 0

Because each Sprint 0 can be so different, there's no fixed structure. One basic principle is to work in iterations in a Sprint 0. Build - measure - learn. The recommendation is to iterate at least twice in the sprint.

Try to understand the business requirements, the personas involved, learn about the requirements by interviewing end-users, build a customer journey map of the future process, get feedback from discussing the CJM with the customers. Then use this to start creating wireframes. Go back to the end-users with the wireframes. That's one way to structure your Sprint 0. Depending on the parameters for your Sprint 0 (number of roles, level of complexity, time to deliver, and so on), you'll have to plan which tools you want to use and the sequence of activities in the sprint.

Example structure:



Here, you can see that many of the iterations happen in parallel. For example, value proposition, storyboards, and even personas are iterated in parallel at the beginning. Based on the results of the first iteration, you can start and validate visual designs.

From Sprint 0 to a Binding Offer

You have two main deliverables after a Sprint 0: the Vision & Scope document and the initial backlog. They are required as the basis for a binding offer. But how are they related to Sprint 0?

Let's start with the backlog. A backlog contains the work to be done in a software project. If you've used User Story Mapping, you can take the user stories from the lower part of the map. But remember: "User stories are a promise for a conversation." You'll have to increase their level of detail to make the estimation. In the terms of Requirements Engineering, the user stories are the user requirements. You have to add acceptance criteria to the user stories and - if needed - add further functional requirements. As the non-functional requirements drive the architecture and thus the effort, you should also add them before estimating the related effort.

The Vision & Scope document contains the other things that you need for a development project. These things won't result in work packages, as the work to be done is already in the backlog. The Vision & Scope document includes information about the business requirements and architecture.

You're collecting the business requirements in Sprint 0 and the Vision & Scope document is the place to store them:
* Business value: the vision statement, business value on company level, business value on user level, time-to-value aspects
* Personas
* Structural information on the backlog, i.e. the usage steps
Most of this information is collected in the upper part of the USM. You can add other information, for example, on stakeholders and background information about the project scope.

The second part of the Vision & Scope document consists of the intentional architecture, including the information architecture created in Sprint 0. The architecture is essential for the estimation. Efforts for the realization of the same requirement will differ greatly depending on the architecture.



 

 

References:

- Design Thinking, Hasso-Plattner-Institut; https://hpi.de/en/school-of-design-thinking/design-thinking.html
- User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton and Peter Economy

 

See also: Handling Chaos and Complexity When Building and Running Enterprise Software Systems

 

created by:
 | Editing: Ella Wittmann | Content: Erik Scheid