Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days
“Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days”: Not a revolutionary book but well summarized and provided with anecdotes on why and how Riskiest Assumption Tests (RATs) as part of Design Sprints should preceed Development Sprints to:
“Fail faster, succeed sooner”.
The book focuses on the five days of a design sprint, with an emphasis on:
1. Day: Understand the users’ needs and problems.
2. Day: Sketch multiple solutions from the user’s perspective.
3. Day: Decide on the most promosing (desired, feasible, viable) solution.
4. Day: Prototype the solution using mockups, wireframes, click dummies etc.
5. Day: Test the solution to verify or falsify your riskiest assumptions.
Run. Reflect. Repeat.
As long as you have figured out what the right thing to do is. Then it’s off to the development sprints to do the right thing right.
Design sprints are therefore not a substitute or alternative to e.g. Scrum iterations, but rather fit into the general process: Discover. Design. Develop. Deliver.
By the way: the phased approach of “Understand, Sketch, Decide, Prototype, Test” inspired our Data & AI Product Design Sprint template for Miro, which forms part of Datentreiber’s Data & AI Business Design Bench.
We have already used the format with some customers, but never as described in the book, i.e. over the course of five consecutive days. Typically, we spread the sprint sessions over two to five weeks, depending on the agility of the team.
I’d be interested to know: are you familiar with the design sprint format and did you manage to pull it off in a week? Let me know in the comments. 👇
Read the full book review on the Datentreiber blog:
Responses