Problem: Before joining Pivotal Labs, I didn’t know what small, incremental, feature-based user stories looked like. I was writing 15-page requirement docs or working with developer-written user stories. But, since joining Pivotal Labs, I’ve learned what a really great user story can look like for my team. And I figured I’d share it with you.
When I write a story for a Pivotal Labs team, I find that the most successful backlogs are filled with individual user stories that are:
- The smallest possible change to the product that will actually bring incremental value to users.
- Clear to everyone about why this story matters . We’ve heard this again and again. No one wants to work on a story that doesn’t matter to users.
- Independent of other stories .
- A complete piece of value.
- Clear to everyone about when the feature is done. if a PM is writing stories and the “delivered” stories look different than the PM expected, it’s not necessarily the developer’s fault. It’s probably the PM’s fault for not communicating (in writing, design, and conversations) what the feature should look like.
Let’s jump into an example. Instead of starting with a new product, I decided to try this exercise with an app I’m really excited about — Cambridge-based hopper — an app for booking cheap flights. [Note, I’ve never actually worked on this app.]
Hopper is already a mature app, so I’ve written a sample user story based on a feature that already exists.
How this story would have come to be: Let’s assume Mike (our user persona) is searching for a new one-way flight. He can already see his search results listed by price of the flight. Now, let’s assume I talked to a bunch of users and learned that users get frustrated with the current search feature because a large subset of our users actually aren’t always price sensitive. Sometimes they are more concerned about the travel time than the price. When we asked users why they are time sensitive instead of price sensitive, we learned that they use hopper to book vacations and our users have a limited number of vacation days. Therefore, they want to make sure that their flight doesn’t interfere with their workday schedule and doesn’t add extra vacation time to their trip.
Based on that problem, the product and design team would have come up with this feature and user story.
Visual flow attached to story:
This story is:
- VALUABLE and prioritize-able. This feature is incrementally valuable to the app. The app works without it, but adding this feature increases the usability for our user, Mike. You can tell it’s value because the “why” is clear and comes form real user research.
- COMPLETE. It follows a full flow across many screens.
- INDEPENDENT and separate from other features. We could choose to implement this filter without implementing any other filters.
- SMALL. This provides a solution for one problem at a time. Two years ago, I might have written “search results can be filtered by price, departure, arrival, and stops.” But now I would break those 4 filters into independent stories so we can prioritize their value accordingly. It also provides the simplest and smallest solution I could think of. If someone on the team can find a simpler way to solve the problem, we could write an even smaller story to address the user need.
Now, let’s talk about what this story is not:
- This story is not just a front-end story or only a back-end story. Completing this story means that all parts of app work together according to the acceptance criteria.
- This story does not describe a button that doesn’t do anything. Clicking the button takes your somewhere and you’re able to complete a task.
- This story does not describe a full ‘view’ or full ‘screen.’ It only describes one feature on a complex page.
- This does not include error or edge cases. Those would be in separate stories, so they could be prioritized accordingly. In the past, I might have tried to fit all edge cases and errors into one story, but that meant that the engineers were working on solving for edge cases that will hardly ever happened. And it means that they’re not working on the next feature, which might be more important than the edge cases / errors.
- This does not replace a conversation. Conversation is another communication tool that we use to make sure we’re building the best thing together.
Interested in reading more about user stories? Check out:
- Principles To Effective Story Writing: The Pivotal Labs Way– an amazing, in-depth explanation of story writing written by Ryan Jones and Pablo Schuhmacher
- Adam Sigel’s recap of What engineers look for in a PM — also entitled “Building Trust with Engineers” — this talks about how much detail and explanation engineers look for in the user stories they like to work on.
- Product Managers from Twitter, AppNeta, and Ecovent showcase the good and the bad user stories they’ve written for their teams — written by me.
- Joanna Beltowska wrote this great piece on the Pivotal Blog entitled Be Good To Your Devs: Write User Stories That Are Easy To Understand
Want to join Labs? We’re hiring designers, software engineers, and Product Managers.
This is what my user stories look like was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
