During our webinar—How Product Managers and Agile Development Teams Can See Eye to Eye—we received so many attendee questions we couldn’t address anywhere near the entire batch during the live event.
One question that time didn’t permit us to answer was how to break product features into user stories during the planning and development phases, and why those user stories, as opposed to larger product features, were the preferable units of development. The question struck us as so important that we decided to devote an entire article to answer it!
First, in case you’re unfamiliar with the term, a user story is a small, self-contained unit of development work designed to accomplish a specific goal within the product. It describes the intent or desired outcome of a small but complete slice of user functionality. A given product feature may be comprised of several user stories.
A story is usually written from the user’s perspective and follows the format: “As [a user persona], I want [to perform this action] so that [I can accomplish this goal].” As you can see, a user story doesn’t usually describe exactly how a feature is to be implemented, but rather what a user is hoping to achieve and why. The implementation details are usually included or attached as a part of the stories.
“The unit of collaboration in software development is, hopefully, a fine-grained user story.”
— Dan Podsedly, VP of Pivotal Labs and Pivotal Tracker’s “Godfather”
For example, a user story for our roadmap software might be written this way: “As a product manager, I want to search across the Notes in my company’s product roadmaps so I can quickly find initiatives that require my team’s resources.”
From Strategy to Execution: Why User Stories as Opposed to Features?
The key to understanding both the work involved in moving from product features to user stories and why that’s the way to go is to first understand that effective product management requires starting with the high-level strategy and then systematically working your way down to the details.
As we explain in our book, Product Roadmaps: Your Guide to Planning and Selling Your Strategy, if your organization is planning to kick off a new product, you’ll want to start at the highest level first.
If you started brainstorming ideas for product functionality, user workflow, or look and feel, without first establishing your product’s strategic purpose, its reason for being, you would likely develop an unfocused and unremarkable product.
But let’s say you’ve completed those first strategic stages of product planning, and you’re now ready to translate your roadmap’s plan—like the sample roadmap below—into actionable steps for your engineering team. Here are a few reasons why slicing the work into user stories makes more sense than suggesting fully-formed features.
1. Stories are vertical: They allow the development team to focus their efforts on a complete piece of functionality (no matter how small).
One reason for favoring user stories is that they are small vertical slices—meaning they represent an entire piece of functionality. In other words, a story should allow a user to complete some task, even if that task is small.
When a story is checked in by development, you can actually do something with that story—use it, test it, verify it. So it represents a good incremental step you can complete toward your larger goal or milestone.
If you instead task your engineers with working on a fully formed feature, they are much more likely, at any given moment—say, at the end of a sprint when it’s time to review their work—to be only partially finished with whatever items they are working on.
This means you’ll have far fewer opportunities at the end of your sprints to test, agree on, and then push live new portions of functionality—even very small ones—if your developers are all at varying levels of “still working on” their respective features. If your developers were working on small, hours-long user stories, on the other hand, you’ll often have new functionality to ship and gain feedback on.
2. Stories can easily fit into sprints, while features generally can’t.
Another benefit of breaking your product’s desired functionality into user stories is that, because they represent very small chunks of the product, stories make for more effective scheduling and collaboration.
Even if your company is an agile shop that runs very short sprints, a typical story will fit nicely into those sprint timeframes, such that you’ll always have a few completed stories to review when the sprint ends.
Moreover, if priorities change and you need to adjust your development schedule, it will be much easier to shift stories around on the agenda than it would be to ask your development team to halt progress on a large feature that’s 65% complete—and refocus on an entirely new, large feature.
3. Stories capture intent and desired outcomes, leaving the actual development instructions to the experts: the developers themselves.
Stories give the product manager the opportunity to describe, very specifically, what the desired outcome of a piece of functionality will be for a user—such that any skilled developer will be able to understand the intent, perhaps with a few clarifying questions.
This is preferable to offering specific instructions on coding or user workflow for several reasons. First, it allows the developers to bring their knowledge and experience to the project. They will often know better than the PM how to translate a story into the right series of user steps or actions.
Another reason for framing your stories with the desired outcome rather than detailed instructions is that it can preserve and even strengthen your relationship with your development team. Developers generally don’t want to be told how to do their jobs, and stories written with detailed development specs—whether intentionally or not—can have the effect of making your developers believe you don’t trust them or that you don’t think they bring any creative value to the project.
Properly worded stories give your developers the breathing room they need to do their best work.
Want More Effective User Stories? Break Them Down Further.
For your stories to be as effective as possible— they are clear to your developers, simple to complete, easy to test, and gain internal acceptance—you want to break them down into the smallest logical units that you can.
For example, let’s assume we were writing stories for a “New Admin Console” feature. In agile terms, we might call this an Epic. How broad or granular should you go?
Creating a story called “Admin manages users” would be too broad. That doesn’t give a developer enough detail about your desired outcome. What does “manage” mean in that context? What specific tasks should the Admin be able to do in terms of managing her users?
This is why, when you come up with the idea for this type of functionality, you need to break it down even further into several stories. For example:
- Admin adds a user
- Admin edits a user
- Admin deletes a user
Now your developers have a set of clear, highly specific tasks they know how to complete. And, as a bonus, you’ve broken down your complex “Admin manages users” story into enough component pieces that you could even afford to de-prioritize one if needed. For example, you could ship an early version of your product that allowed administrators to add and edit users, but not delete them.
If you had insisted on your original, complex story, the whole thing would’ve taken longer, and it would’ve meant you couldn’t ship any of it as quickly as you will by breaking it into smaller pieces.
“Because big stories have a lot of complexity, they have a lot of risk as well. What if you get 80% or 90% down the path and realize the story was based on erroneous assumptions? Break big stories into smaller stories—representing at most a few days of dev.”
— Dan Podsedly, VP of Pivotal Labs and Pivotal Tracker’s “Godfather”
3 Tips for Developing Effective User Stories
1. Make it a team effort
Product management really has to be a true team effort. And that can’t simply be a matter of your saying that it’s a team effort. You have to mean it, practice it, and build it into your routine.
That means optimizing your communication processes. It means being available to quickly respond to questions.
It also means not falling into the trap of having just one or two people on the cross-functional team—the PM and the engineering lead, for example—do all of the brainstorming and breaking down the stories into fully formed plans and then just presenting those to the rest of the team.
Your stories in many cases really should arise out of discussions with your larger cross-functional team.
2. Use the right tools
Optimizing your team’s ability to collaborate—whether in a large brainstorming session, during a quick stand-up, or even through a quick back-and-forth across time zones—requires the right tools.
This starts at the very beginning of your product strategy planning—with the right product roadmap application. And it extends to your cross-functional team’s ability to communicate quickly and effectively every day, no matter where they are—by using the right project collaboration software.
And ideally, it means finding tools like these that can talk to each other—so your team can check their daily progress against their big-picture goals, for example, and sync their roadmap’s progress with the current status of each individual task. ProductPlan and Pivotal Tracker have integrated our respective tools for just this reason.
3. Develop a strategy for collaborative story acceptance
Finally, one often-overlooked strategy is to bring more people into your story review process. When your developers check in a story as completed and you simply hand it off to QA, you miss a lot of opportunities both to catch issues with the story as coded and to distribute product and user-persona knowledge across your broader team.
It can be helpful to develop a plan for achieving “collaborative acceptance” for your user stories. What this means is bringing in your designers, your developers, the rest of your product team, and of course your testers, to review your stories. But the distinction here is that these groups aren’t going to be looking only for bugs in the code or typos in the UI.
Your broader team is going to bring their respective areas of expertise and understanding about your user personas to these reviews—and offer feedback from all angles, not just bug fixes.
The additional bonus of this strategy is that you will be growing a broader and deeper knowledge base in your company about your product and its users—which will ultimately lead to better, more effective user stories coming from all across your team.
