Any discussion about Sprint Zero’s purpose in software development will likely be littered with questions.
Should it be called a sprint at all? Is it even necessary?
All understandable inquiries. But if you’ve come seeking answers to all of them, this isn’t the article for you. This is not a treatise on the validity of Sprint Zero as an Agile and Scrum technique.
This is an overview of how your friends at DePalma Studios use Sprint Zero to more accurately plan and estimate development work for our clients.
My goal is to provide a practical look at how Sprint Zero can be used to mitigate many of the common risks and save resources in software development projects.
If that sounds valuable, then you’ve come to the right place.
In a moment, I’ll show you the step-by-step process we use to do our story mapping, outline our technical approach, and create our estimation and release plan for new projects.
But first, a brief definition.
Sprint Zero is an Agile project management technique teams use to do the work required to prepare for the first release.
This often includes discovery and planning tasks, like agreeing on a shared definition of success for the project with clients, creating an initial backlog of user stories, and estimating the time and effort needed to complete each story.
In Scrum, sprints are often labeled numerically, so Sprint Zero precedes Sprint One, which is when the first code will be delivered.
As the graph above illustrates, each sprint is part of a larger software release, and each release is part of a larger project (like a redesign or new application launch).
In a broad sense, Agile simplifies complex work by breaking it down into more easily managed segments.
That’s why the first part of our process is Story Mapping, during which we divide the work required to build the client’s application into smaller and smaller work segments. Ultimately, this level of detail allows us to scope the project more accurately.
Here’s how it works:
To begin with, many of our clients will only have the general purpose of the application defined i.e., “a call center management application.”
Next, we clarify the high-level ideas or areas the client requires for the application. We call these definitions themes, and they serve as categories to group features.
After the themes have been organized and agreed upon, we work with the client to prioritize which areas we should build first.
Then, we unpack the high-level functionality related to each theme.
We refer to these functions as epics, and they link the broad ideas of what the application will do with the more concrete tasks of what needs to be built.
Finally, the epics are broken down into user stories, which are specific pieces of functionality that need to be built to create a full-fledged feature.
User stories from this initial phase of Sprint Zero become the backlog for Sprint One and the first release.
I really appreciate that the entire process has recurring literary undertones, but beyond using cool signifiers for units of work, Story Mapping during Sprint Zero yields some very real benefits.
This is beneficial for several reasons:
1: The project scope will be more precise, which helps us deliver a more accurate estimate to the client.
Every client we work with wants to know with a reasonable degree of certainty how long it will take for us to build an application, and how much it will cost.
Most firms in our industry will just shoot from the hip to get the project, then ask for budget extensions later in the development process, because their estimations were half complete.
Although it may make getting a “yes” from a new client easier, we view this approach as unethical.
2: We can articulate exactly what we’ll be working on, which makes everyone feel more comfortable. Collectively, the team is also better coordinated, which reduces wasted time.
3: We can draw a clear line between each User Story and the overarching goals of the application.
4:The project can be properly managed. By defining what’s possible and the order in which the work will be accomplished, our team can be held accountable to a project plan.
To maintain balance in The Force and give the design a few weeks of lead time over development, we schedule our UX design process as part of our Sprint Zero.
In case you’re new to the site or the blog, our team always follows a human-centered design process because it draws on user feedback to inform the direction of the design. The end result is a design that speaks directly to the audience who will be using it.
Here’s a look at some (though not all) of the steps we follow:
During this phase of Sprint Zero, we’re also defining our technical approach to building the client’s application. This generally includes six tasks:
1: Choosing the technology stack that our developers will use on the project. This varies based on the specifications of the project.
2: Setting up the architecture for the development environment.
3: Assembling the team and ironing out who will be responsible for each part of the development process.
4: Planning the integration of the application with the client’s existing systems. This helps uncover any interoperability requirements or obstacles in tandem with UX design.
5: Rolling out a testing strategy for Q&A.
6: Assigning points to the user stories that were defined during the Story Mapping process, and using those points to plan the next release.
Story points indicate the amount of time needed to complete a given story, and they allow managers to measure velocity over time.
At the beginning of longer projects, we always set a goal to increase the number of story points consumed on a weekly basis as the project moves forward. Increasing the number of story points becomes a KPI throughout the project.
Positioning UX design as a part of Sprint Zero ensures a shared understanding between designers and developers. As designers create the user flows and visual design of the application, they can check with the dev team to confirm that their work is technically feasible.
This prevents costly repair work later in the project.
Getting to know your users before anyone starts writing code also gives us the opportunity to uncover new user stories (and therefore priorities) that stakeholders might not be aware of.
In terms of our technical approach, this work simply needs to be done. Whether you call it Sprint Zero or not, these pieces need to be in place for development teams to adequately do their jobs.
Now that the discovery work has been done, it’s possible to deliver an accurate estimation to the client. We accomplish this by allocating points to each user story based on the length of time each one will take to complete.
Here’s a visualization of how it looks:
We typically manage user stories in a project management tool like JIRA that has the native functionality to support we need to distribute points.
Using the points assigned to each story, we’ll organize stories into sprints with release dates. Each sprint will have a point total that communicates how many hours we’re estimating for that sprint.
By correlating the epics and stories we identified in the first part of our Sprint Zero process, we’re able to deliver an estimate for the first iterations based on quantitative data, rather than assumptions.
***
As I mentioned earlier, the semantics regarding Sprint Zero are controversial.
Given the blowback against the Waterfall approach to project management, there’s a degree of hostility toward planning -- not to mention a dogmatic adherence to Agile scripture.
We agree there’s certainly a point where planning becomes gratuitous. Like many other things in life, it’s about achieving proper balance. We’ve used Sprint Zero at DePalma to successfully manage complex development projects for enterprises and startups alike.
In our experience, it has only led to more accurate budgets and timelines, increased accountability, and reduced waste.
I think we’ll stick with it.