At a recent workshop on agile requirements, I was surprised by the number of attendees who had been told that EVERYTHING in their product backlog had to be written in the form of a user story, and specifically in the format described in Mike Cohn’s great book User Stories Applied for Agile Software Development: As a <type of user>, I want <some feature>, so that <some goal>.
Now, I’m a huge proponent of writing user stories. So-called “Requirements” are the hardest part of software, and a user story, when done right, is a great way to make requirements a little bit better. Like many tools, they are most useful when used as intended, namely a quick way to describe a requirement with a bit of context, so that the team knows who to talk to for more details and what problem the feature is trying to solve. They are not the only tool we can use to make our requirements a little better, we have other things like Acceptance Criteria (actually an important part of a user story, the “confirmation” of the three Cs: Card, Conversation, and Confirmation). We have Story Maps, Use Cases, User Persona, and a host of other great tools to use. User Stories are probably the easiest to understand and teach, and maybe for that reason, they are the most common agile requirements tool. I love to use them, as well as the other tools.
But I am also lazy. I abhor anything that smells faintly of “busy work”. Writing a user story for every item in a product backlog smells pretty strongly of policy over pragmatism, or to put it another way, Processes and Tools over Individuals and Interactions. So jump the break and let’s look at when to use the User Story hammer and when to leave it in the toolbelt.
The Product Backlog: The System of Record for All Work
On a scrum team, the Product Backlog is what is known as a System of Record, or the authoritative data source for what we want teams to work on. In agile terms, it is also an information radiator, the one place where the priorities of the Product Owner are made clear and transparent to the Team and to stakeholders and anyone else that might happen by. Since it is both a System of Record and an Information Radiator, everything we want a team to work on should go in the Product Backlog. As my friend and Product Owner for Innovation Games Luke Hohmann is known to say, “my team doesn’t use the restroom unless it’s in the backlog”! For those worried about the sanity and health of Luke’s team, I’ll clarify that Luke is using hyperbole, but his point is that he is very strict about this: as a Product Owner, he is accountable for prioritizing the work of the team, so anything they are working on needs to be made transparent in the Product Backlog.
Since everything goes into the Product Backlog, that means that a Product Backlog will likely be composed of several items that are not direct descriptions of new functionality. Product Backlog Items (or PBIs for short) might include such categories of work as defect fixing, refactoring, architectural work, prototyping, and research. In that context, let’s look at a few items that might live in a product backlog, and decide if we are helping anyone by writing a user story.
Some Sample Product Backlog Items: to User Story or Not to User Story?
- Auto-Save every few minutes
- Add tooltips to the text style icons
- Fix bug# 1227
- Decrease cold launch time so that it is <1 second
- Choose between Java, Scala and Ruby
- Clean up the Document object so that it is faster/easier to support new file types in the future
I want to acknowledge right off the bat that these product backlog items are pretty big and need to be broken down, and that they all are crying out to me to add acceptance criteria. Let’s put that aside for now and examine whether writing user stories would be helpful for each of them, keeping in mind that the purpose of writing a User Story is to help provide additional context to the team, so that the team can do a better job implementing the product backlog item.
PBI #1: Auto-Save every few minutes.
This is a classic new feature request type of requirement. As it is written, we don’t have much detail at all – does every category of user types/persona want auto-save? What are they trying to accomplish by having auto-save? Let’s imagine that we spoke with our product owner Ginna and asked her to write a specific user story for PBI #1, and that she responded with this story: “As a video editor, I want Premiere Pro to auto-save the current project frequently, so that I can jump back to a previous version of the edit”. That provides a ton of useful context. It’s probably really useful to the team to have that context as they figure out how to build it. They might even come up with a cooler way to the solve the problem (the “So That” part of the user story) than what the original story described. It seems like Auto-Save is a great candidate PBI for writing a user story – it is new functionality, there is a specific user problem we’re trying to solve, and the context about the problem and user is helpful to the team as they go about starting to implement the feature.
PBI #2: add tooltips to the text style icons.
Let’s try writing a good user story for this one: “As a novice user, I want tooltips for the text icons, so that I can learn what the icons stand for”. This is a pretty good user story – it clarifies what user type wants the feature and the problem we’re trying to solve. Does it add a bunch of value, in that the team might do a better job of implementing the tooltips now that there’s a user story? This is a little less clear. Maybe, and it didn’t take a lot of work to write the story. This one falls into the “maybe” category.
PBI #3: Fix bug# 1227.
What’s that? You have a separate system for tracking bugs? Those aren’t in your product backlog? Hmmm, so how do you determine whether fixing that bug is more important than adding that feature? Do you have arguments about whether a bug that’s been entered is actually a feature? Regardless of whether you use a separate tool for tracking bugs, and I know that MANY teams do this for a variety of reasons, it is still important to track the work of the team in a single prioritized list. That means adding PBIs for bug fixing, which may take the form of “Fix this specific bug”, or, as is more common in my experience “fix 10 bugs”, or “fix the bugs in your queue” or “fix the bugs related to saving”. Ok, now that I’ve gotten that off my chest, let’s examine whether we should be writing a user story for this bug. In most cases, this will fall into the “no” category from my experience, especially if the bug is really a defect, “something that is not working like we meant it to”, and not a feature, “something that would work even better if we did this one little change”. A well written defect will explicitly state repro steps, expected behavior, and actual behavior. Additional context does not add anything that helps the team implement the bug fix.
PBI #4: Decrease the cold launch time so that it is <1 second.
Pretty clear, right? Are the specific users that we need to talk to about this? Do we need to know what problem we’re trying to solve? In My Humble Opinion, writing a user story here probable doesn’t add much value to the team as they figure out how to implement this.
I’ll make this one easy for you: choose Ruby. Kidding, kidding.
Who do you think wrote this PBI? Was it the product owner? Possibly, but it’s much more likely that the team wrote this as a way to clarify that they need some time to research these different frameworks and choose the best one. My opinion is that the best way to approach such research PBIs is to take a Set Based Concurrent Engineering approach. (Famous Toyota Prius Example from the Jeffrey Liker (PDF), simple software dev example). That said, would adding a User Story to this PBI be helpful to the team? Sometimes I’ve seen User Stories for things like this, something like “As an architect, I want to choose the best framework for our application, so that it is flexible and maintainable”. In my opinion, this is not adding much valuable context for team members. They already know why we need to choose a framework, and the user is them!
PBI #6: Clean up the Document object so that it is faster/easier to support new file types in the future.
Here we have a refactoring PBI. Again, who is the user? Probably the team. Since the team already knows who they are, and why they want to clean this up, writing a user story is not helpful. You might try it, something like “As a team member, I want the Document Object to be cleaner, so that I can quickly and easily add new file types in the future without hitting multiple parts of the codebase”. Maybe that adds value, maybe it doesn’t.
To sum it up…
User Stories are great – they help team members to better understand the context of what they’re building, which in most cases leads to faster, cleaner implementation and usually less rework. That does not mean that every item in the product backlog needs to take the form of a user story. Some tools make this worse by labeling every Product Backlog Item (PBI) a Story. This is unfortunate.Every item in the Product Backlog is a PBI. Some PBIs will also have User Stories associated with them. I think it is worth the quick conversation for nearly all PBIs about whether a story would help. In many cases, we can try to write one and see how it feels. Sometimes, it will feel circular and like a waste of time. Many times, they will help us clarify what we mean by the PBI. In short, use a User Story when they add valuable information to the team about the context of the thing we’re thinking about building.