What is Sprint Zero & Why It Matters In Digital Product Development

Let’s start with an analogy.

If you engaged a builder to build your dream house, you would not assume that the very first interaction with them would be them arriving Monday morning and pouring your concrete slab.

One would assume that you would need a plan; a plan that was consultative, and discussed via multiple on-site meetings, discussions, engagements to clearly define what your dream house entails.

You would expect the site to be surveyed. You’d want engineers determining that the ground was suitable and there were no unexpected water features to cause trouble down the line.

What about that complicated roof that your architect designed? Again, you would expect the builder and architect to converse and have a plan in place to execute to the highest quality. Those two non-native trees where your carport will go? Permission from council will be needed. Conversely, initial materials would need to be delivered on-site.

It is called ‘pre-build’ planning.

The benefits of pre-build planning, other than the obvious practical and functional outcomes, are considerable:

• You’ve established expectations and seen how your builder operates; giving you the chance to discuss up-front what it is you desire and why.
• You have an aligned vision between you, your builder, and your architect. It’s cheaper to sketch ideas on paper than to move a bathroom that already has plumbing installed.
• You’ve likely identified and potentially mitigated risks and issues that would have otherwise expensively halted the build down the track. You found the underground water source that is de-stabilising your foundation, before the slab is poured.
• You have the materials and trades people ready to go in sequential and logical order. There was sufficient runway to find suppliers that had what you needed and trades that could commit to your start date.

You’ve set yourself up for the best possible start to build. You have confidence that day one is aligned to a master plan and your vision will be executed to your desires.

So why don’t we start digital projects like this?

There are a few main reasons; it all comes down to your approach, or the approach of your digital product development agency.

The first approach; “waterfall and fixed cost”.

Put simply, this approach is a nightmare. It sets terrible expectations, starting with misalignment on approach, resulting in significant delays, variances and potentially an aborted build. This approach is the standard method a digital agency often uses; it lacks pre-build thinking and focuses on the human desire to know exactly what the cost will be.

However, you enter this approach thinking that build will run smoothly on day one. When your digital agency finds an unexpected issue (ala that underground water source) – you start hearing about additional costs and delays. Both parties become aggravated, as you believe that your “builder” or in this case, digital agency, should have known better.

The second approach; “agile, time and materials”

Agile, time and materials – is certainly the superior approach and really the only approach you should accept for engaging with a digital product development agency.

However, many teams and their digital agencies prefer to jump straight into the deep end. The argument is that the pre-build, warmup, learnings, and alignment can be undertaken as part of the project itself. The equivalent of guessing how much water your foundational cement base needs as you’re pouring the slab.

Whilst this might be true and a reasonable argument to make for when a digital business makes a digital product for itself, it is not advisable when you’re building a digital product for someone else, as unforeseen issues cost time and money, and it’s you (the client) that needs to absorb this.

This is where the concept of Sprint Zero becomes paramount.

As a digital product development agency, we have inherent processes in place that we follow to mitigate the shortfalls of common approaches to digital product development.

In agile digital product development, we work in two-week sprints of work. It all starts with Sprint Zero.

We plan what we want to get through and leave no stone unturned in the pre-build phase. At the conclusion of each two-week sprint, we take stakeholders (clients, business advisors, internal product teams) through the progress and how we can further better the next sprint.

Sprint Zero is all about de-risking on a multitude of levels.  

This leads us into Sprint One; a sprint that has the foundations understood, expectations aligned and a plan in place to mitigate as many unforeseen issues as possible.

Examples of Sprint Zero deliverables

Each client, project and digital product is different. Some clients have performed research, have clear branding guidelines, while others do not.

If the digital product is complex or intended to scale, solution architecture needs to be thought through and documented. Some clients have this, and again, many do not.

Initial analysis prior to Sprint Zero should allow for a reasonably accurate assessment of what should be in or out of your Sprint Zero. Which of course, is not to say things won’t change and more or less work will be required.

That is the iterative nature of agile. You found underground water. You now want a bathroom in the garage. That subway tile you wanted is no longer manufactured.

You pivot and adjust and that’s great.

To illustrate these concepts, here is a sprint plan we developed with a client recently. It showcases the upfront thinking and agile approach to delivering against an aligned vision.

Universal activities in digital product builds

In our experience, there are however a few universal activities you can almost always assume need to occur. These can include:

1. Project setup: setup the development environment, tools, and infrastructure.
2. Team setup: build the team, define roles and responsibilities, and ensure you have all the skills and knowledge needed.
3. Requirement gathering: working with stakeholders, exactly what are the initial requirements of this build (remembering that future requirements are gathered later on as you discover exactly the digital product you need). This results in what are known as ‘user stories’.
4. High-level planning: preliminary estimation and then prioritisation of work; defining the ‘product backlog’ and an initial release plan.
5. Architecture and design: the solution architecture I referred to above where you’re undertaking software design and technical implementation planning.
6. Prototyping or proof of concept (both): wireframes, small prototypes and potential a visual concept to validate feasibility and demonstrate and align on the visual vision of the digital product.
7. Training and knowledge transfer: any additional, “oh, one last thing you should know”, conversations to make sure we all know the ground water has been mitigated, though keep an eye out.

In summary, Spring Zero is a sensible and structured approach to ensuring your project starts on day one with the best chance of success. It’s an approach so often overlooked, given the inherent investment in the old ‘waterfall and fixed costs’ model. Don’t skip Sprint Zero; you’ll thank us later.

‍

‍