I love the idea behind design sprints, but I dislike design sprints.
I love the fact that design sprints get people to iterate with the customer.
I love that people try to understand that they should be figuring out how to best satisfy the customer’s needs.
I hate the fact that most teams do it without the customer(s) being present.
I hate that, from a lean perspective, it is almost complete waste.
There is no value produced (I should say no value added to the product) at the end of whatever time period has been spent coming up with the best design. The part I love is the day 5 user validation piece, there is so much to gain from this. What I hate is that it is happening with a prototype. The whole experience for the user(not UI, but UX) could be very different when the feature is a part of the product.
A design Sprint can very easily set you on the path to a modernized waterfall. However you try to sell it, a Design Sprint is BUFD(Big Up Front Design). At the end of it there is no customer validated product, at best there is customer validated design. If it takes a long time to build the feature out, customer’s needs, design preferences or even the customer themselves can change. The eventual, integrated experience might be very different from the perceived design as well. If your process looks a bit like Joshua 스크람 Partogi’s diagram below, your Design Sprints might be setting you up for “A More Agile Waterfall”.
Courtesy Joshua 스크람 Partogi
I would like to propose an alternative to Design Sprints : Cover Story.
This is not an official “Process” and it is not intend it to be so. This is an experiment to find the best way to facilitate early, fast discovery of problems and solutions. This is an experiment that might work well or fail miserably.
The Cover Story starts off as a design sprint, but progresses in a different manner. The idea is to get something functioning reviewed by the customer and to discover the true scope and direction of the feature.
Feature Kickoff — This is a 2–3 hr design sprint to kick things off. This is where the customer problems are brought to the team. The team members try to understand the problem and propose solutions. The proposed solutions can be broad, but center around the main user problem being solved. The solutions are collected, critiqued and combined to form 1 to 3 main ideas that can be implemented.
Hackathon — Once the solutions have been narrowed down to 1–3, depending on the number of team members, we embark on a 2 or 3 day Hackathon. The Designers, BAs, Devs, QAs, everyone tries to build a functioning feature that can be reviewed by the customers. The feature being built only needs to address the main problem that we are trying to solve. Auxiliary problems being solved is a bonus, but not necessary. The idea is to build it so that at the end of the cover story, the feature is in production. This means, tests, CI, deployment, all are part of the Hackathon.
Demo/Validation — All implemented solutions are presented to customers (or whatever representation you would use in a design sprint) as a part of the product. They are free to click around, play with the implementations and observe the flows and provide feedback. The feedback is used to determine which version solution would be a part of the product. The elements of the “rejected” solutions that the users loved, can be used to create future stories.
Integration — All code for the selected solution is checked into the master branch. This code is now part of regular builds that are sent to CI and production environments. Feature toggles and Beta tags might be used to highlight that the feature might still be in progress and is being added to.
Future Plans — The feedback received from the users can be used to generate stories for the immediate future. Any technical debt accrued in the hackathon should also be included as stories that need to be taken care of before we close out this feature. If the total number of outstanding enhancements and user requests crosses an acceptable threshold (5, 10, 15, 20 stories etc.), the remaining work should be split into multiple features that can be handled with their own cover stories.
I will be looking for teams within my own organization that want to try out this approach. My hope that it brings together the best of Design Sprints and Lean thinking to produce the best results without a lot of waste being generated in the process. Any waste that is created, though, hopefully contributes towards the delivery of value. After all value trumps waste (skipping the flow step here…or maybe not). The idea is to learn as much we can about the feature by actually working on the feature and using feedback to guide our future course. This is the simplest way I can think of implementing it.
There is also an initially unintended side effect here. If the feature is too big for the central idea to be implemented in a 2–3 day hackathon, the feature might already need to be broken up into smaller features. Too often are teams caught on working on small stories but large features. This might help right size features as well.
This is not an official “Process” and it is not intend it to be so. This is an experiment to find the best way to facilitate early, fast discovery of problems and solutions. This is an experiment that might work well or fail miserably. Feel free to form variations of this and give it a shot. If you cannot deploy immediately after the hackathon, use test environments. If you cannot get users for validation, get the product, sales or customer support team. Nothing here is a prescription, just a loose timeline for experimentation. If you decide to give it a shot, please do let me know how it goes for you. Hoping for some awesome results…
P.S. — Did I just re-brand Scrum as Cover Story? Sure seems awfully close to the first 1-week sprint for a feature.