8 ingredients to prepare your Design Sprint for the Marathon
You’ve probably sprinted before. You wanted to catch the train, find shelter when the rain started or challenge one of your friends. While some people are faster than others, everybody can run a short distance as fast as they can.
A marathon is a different story. Opposed to running as fast as you can over a short distance, you need to manage your energy. This requires strategy and preparation. Long-distance trainings, special diets and breathing exercises can help build your stamina. Deciding whether you will slow down, accelerate or keep the same pace during the race has to be part of your strategy.
You might see where I’m going. Design sprints are a truly great mechanism to ideate, find focus and validate in different stages of your software development project. Agile sprints are a great way to work through your product backlog, iterate upon results and have effective meetings.
For a product that needs more development and will be part of a bigger picture, you need some extra ingredients. You need to get ready for a marathon full of design, development and delivery.
The following (non-exhaustive) list consists of ingredients that I have included before, during or quickly after a design sprint. They help me get beyond a validated prototype. They prepare me for an effective software delivery marathon.
1. Understand the V in MVP
Eric Ries’ The Lean Startup defines a Minimum Viable Product as ‘that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort’. This definition is helpful for delivering and validating results quickly, but deciding on the borders of viable is pretty subjective. If you’d ask a product owner, some products are only viable when they perform well during heavy usage, other products are viable when they support a complete process, including its exceptions.
In these cases, you need to not only look at viability, but also at how first value can be delivered. What is the first feature that will make people use our solution? In addition, you need to build trust with your stakeholders that the product will actually become fully viable, even though you plan to release and validate before that moment.
2. Define a roadmap
A roadmap is a great way to move towards a viable product and position topics that you ‘park’ along the way. During a design sprint, participants like the idea of the sprint’s target, but often want to add more things to the sprint’s scope.
An engaging way to connect your design sprint to a roadmap is user story mapping. With this technique, you map user stories (or epics) on the user journey you’ve developed before. Differentiating between different sprints or releases will directly visualize which part of the journey will be supported in which product version.
3. Understand the business objects
This is one I haven’t always agreed with, but was useful in many projects. Most processes are more complicated than, let’s say, online shopping. To fully understand these processes, it’s important to understand the elements and the connections between those elements. A basic entity-relationship diagram, supported by a glossary of definitions can already help with this.
4. Fit your solution into the IT landscape
Maybe you’re building the one application to rule them all. Probably not. Your application will be one of multiple touch points in the user journey and will interact directly or indirectly with other applications in the IT landscape.
In order to prevent duplicate work, accurately estimate effort for building integrations and become friends with an organization’s architects, you’d better look at positioning your solution. Understand why the other applications exist, where the gaps are and how to maintain data integrity within the bigger landscape.
But don’t forget, also take this chance to improve the user experience across touch points! Maybe with a little less interface?
5. Set up a product backlog
So your design sprint has ended. You’ve got your prototype, you’ve got the users’ feedback. Now what? Put it on a product backlog!
Only if a single developer is implementing the exact scope of the prototype, it might be possible to just get going. In any other case, you should create an overview of what you want include in the first versions of your product and have a way to collaboratively build it.
Translating the outcome of a design sprint to user stories is instrumental to connecting the dots and finding the gaps in your current view on the solution.
6. Discuss the roll-out strategy
The success of a software product is usually not in the quality of its code. It’s in the fit with the user’s need and the effectiveness of the product’s roll-out.
Some roll-outs are easy, especially when an application will be used by a small and centralized group of users that have no alternative solutions. When people need to be convinced to use your application or users are spread geographically or functionally, it becomes more complicated. This situation requires a thorough understanding of the stakeholders of your project.
Identifying and appointing (local) ambassadors can help a lot in letting your product land. These people, that represent different groups of users, are ideally already involved during the design sprint. During the product roll-out, the ambassadors can help training users, collect early feedback and promote your application.
7. Track project status
In college, the agile methodology was presented like a holy grail. It decreases development costs, increases user adoption and makes software delivery more successful in general. While all these benefits are legitimate, I’ve experienced that a bit of old school project management does help delivering applications.
As mentioned before, organization usually have a finite budget for developing a product and will thus approach it as a one or more projects. You want to define on a high level what the result of a project (product delivery phase) should be and respond to risks and scope changes that impact the feasibility of that result.
8. Celebrate success
Last but not least, a proper celebration is well-deserved after a pilot, go-live or even design sprint. Keeping silent and just carrying on will cause a loss of enthusiasm, even with your ambassadors.
Go out and celebrate. Thank your early users, your design sprint participants and yourself! That’s the nice thing about marathons, they will earn you a medal.
