Join 31,816 readers for design news, cool links, and updates from Jake & JZ every... once in a while.
We’re big fans of the Design Sprint process here at busuu.
In the past 9 months, we’ve run a few design sprints with incredible results. We even routinely incorporate approaches and techniques (e.g. How Might We’s, Crazy 8s or Lightning Demos) in standalone meetings and workshops.
However, as process geeks, we came to realize that while esign Sprints gave us a shortcut to learning, the output was usually nowhere near “ready for development”.
That’s because the goal of a Design Sprint is not to raw-feed a Development Sprint with perfect inputs. The goal of a Design Sprint is speed of learning achieved through a user-tested prototype. Yet this does not suffice to produce the type of detailed user stories needed at the start of a development sprint, whose target outcome is a potentially shippable product increment — something that actually works and could be released to production.
So how do we bridge the output of a Design Sprint — usually a prototype and a huge amount of learning — and the input of a Development Sprint — clear, detailed user stories that your team can work on?
3 crucial things were missing before any output from a Design Sprint could ever be deemed ready for development.
Which begged the following questions:
In 2008, Jeff Patton wrote a seminal blog post on the idea of User Story Mapping, “The New Backlog” (highly recommended). Seeing much traction on his idea, he ended up writing a whole book on it.
We’ve been using the technique ourselves at busuu for quite a while and it’s been great way to kick-off big, meaty projects.
The great thing about User Story Mapping is that it solves the three challenges identified earlier . It helps:
1. design systems holistically instead of user stories living in isolation and identify edge cases, empty cases or dependencies ahead of time
2. create shared understanding of the Why, What and How with the development team
3. plan releases and define earliest testable / earliest usable / earliest lovable products
A user story map is essentially a 2-dimensional backlog, with time on the X-axis and necessity on the Y-axis.
At the top of the map are “big stories.” I call them user activities (borrowing the term from UX people like Larry Constantine and Don Norman). An activity is sort of a big thing that people do — something that has lots of steps, and doesn’t always have a precise workflow. If I was building an email system (which I’d never be foolish enough to do) I might have an activity called: “managing email”, and “configuring email servers”, and “setting up out of office responses.”
A story for an “activity” might read: As a consultant I want to manage my email so I can keep up with clients, colleagues, and friends.
But that’s way too big of a story to put into an iteration or sprint.
That story breaks down into other stories like “send message,” “read message,” “delete message,” “mark message as spam” — stuff like that. I call these user tasks. (Again a word used by UX people.)
And then, these user tasks themselves break into subtasks or task details below. Like “send attachments”, “empty deleted items” or “mark as spam”. This is usually the level of granularity user stories need to be ready for development.
First, a User Story Map is effective at helping us determine if we’ve identified all the stories, cases and dependencies in the new system. As Jeff Patton puts it,
Given a stack of index cards, or a spreadsheet full of user stories, I can stare at them for hours, discuss them for hours… but I always walk away with the nagging feeling that there’s something I’m missing. How often are you blindsided by overlooking important pieces of functionality when scoping a new piece of software?
Second, a User Story Map creates shared understanding by explaining what the system does as a whole. Instead of, say, if you’d just broken down the stories, put them in your backlog and waited for your team to work on it.
We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details — the pieces of functionality we’d like to build. In my head a see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations. After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag — then cut down the tree. That’s what a flat backlog is to me. A bag of context-free mulch.
Third, it’s an incredible aid to release planning, as prioritization happens on the map itself:
Prioritize the ribs — the stories hanging down from the backbone. Place them high to indicate they’re absolutely necessary, lower to indicate they’re less necessary.
From the prototype of the last Design Sprint we ran, I was able to write 70 or more stories in the first cut. Imagine having to prioritize that many against each other in a flat backlog!
After our last Design Sprint ended, we went through the prototype-test-prototype cycle many times to iterate on the hypotheses that had been invalidated and the usability problems that had been found in Day 5 of the Design Sprint.
After many iterations, we were eventually happy with what we had and made the call to build it. Considering the benefits of User Story Mapping, I decided to experiment with it as a bridge between this validated prototype and what would go into the backlog.
I gathered all engineers and designers from the Development team in a conference room. To bring context, I explained what the long-term goal of the Design Sprint had been and the challenges we were seeking to solve.
I booted up the prototype on my phone (made with Principle) we had user tested on Day 5 of the Design Sprint and projected it on the TV using AirPlay. I then proceeded to walk them through it.
I stood by the whiteboard and at each step, I would ask: “What’s the user activity here?” (yellow sticky notes), “What different user tasks do you see under this activity?” (green sticky notes) and “Any subtask or task details for this user task?” (pink sticky notes).
We also added a touch of our own: blue sticky notes below all others, for edge cases/empty cases/client-server dependencies. We were able to identify so many of them, especially with 12 engineers sitting in the room.
For instance, now that we have infinite swiping, do we need pagination for the list of exercises the user can correct? How do we deal with the potential loading times of new items in the swiping view?
Or, what do we show users who open the Friends tab — supposed to display the writing exercises their friends have written — when they don’t have any friends on the platform yet?
Finally, we used the board to create a staggered release plan, with a crisp definition of what would go in the first iteration — and most importantly what wouldn’t.
By the end of the session, everyone in the room had a deep understanding of what it was we wanted to build.
In the space of 2 hours, we had:
In the last two months, we launched several iterations of our apps on Android and iOS, where we reinvented the social experience on busuu, allowing you to connect with other language learners by friending them.
One of our core beliefs is that the best way to learn a language is through practice and human interaction. You can now make regular exchanges with native speakers of the language you are learning and make new friends all over the world to help you progress.
These iterations ended up including pretty much every story that you could see on our whiteboard above. It’s probably been the biggest feature work I’ve ever done, spanning 3 clients (mobile, web, iOS) and heavily reliant on the API team.
Even though it wasn’t easy, it’s pretty impressive how close the final result was to our original prototype — and the relatively small amounts of roadblocks and surprises encountered on the way. Much of the credit for that goes to this User Story Mapping session.
It’s now an integral part of our Design Sprint process, the best link we could have found to bridge two great ways to work.
