10 Steps for Writing Better User Stories
Whenever I talk to aspiring Product Managers, or leadership from companies that want to adopt Agile within their organization I get a lot of tactical questions about user stories. Should designs be attached? What comes first, the story or the design? How detailed should the acceptance criteria be?How do I write a story without implementation specifics? While answering these questions may improve the consistency, organization and style of your user stories, focusing on the life cycle of ideas will more efficiently map to user value delivery.
The following is a list of guidelines I follow when creating user stories (note, this is based on the content from my “Writing Better User Stories” workshop through General Assembly DEN).
1. Understand the goal
The goal of a user a story is to enable developers to deliver user value. Especially as you first learn agile and become familiar with the tools to start estimating it can be tempting to focus on vanity metrics like velocity — but velocity is worthless to your users. If you are on a team that is maintaining a high velocity but not delivering value to users, have a conversation with your leadership. There are other reasons to write user stories and perform agile experiments, but your team and leadership should be working from a common framing of those goals.
Once the whole team has a strategic understanding of their value, the team needs to have an understanding of the user’s problem. Hopefully this comes from evidence of actual user pain or customer feedback. This feedback comes in many forms, and as the Product Manager you must not only make sense of it but have empathy for the problem so that you can appropriately prioritize the need for a solution. If this is hard, and you are stuck on this part of the process — be patient — this is hard. Once the team can verbally articulate the problem faced by the users you can start bringing in ideas around solutions.
2. Be inspired
Something I see successful Product UX Designers do instinctively is curate good product design and effectively communicate how it can be applied to the problems you are solving. Chances are, even if you don’t knowingly approach solving problems this way, you are benefiting from iterations on design patterns that have now effectively shaped our behavior. Elements like navigation and settings are common design patterns that users understand and you’d be foolish to try and re-invent all of those every time.
That said it’s best to systemize a curation process among your team. UX teams often have formalized approaches, or spaces dedicated to analyzing design. Product teams also often evolve a formalized approach to understanding competitive products. These are important, but it’s equally important for your small delivery team to be sharing products and design ideas that apply directly to the problems they are solving. Of course while these inspirations can be a powerful reference point, they also can make you very susceptible to attachment bias — so much so that in certain scenarios it’s best to establish ground rules of when not to seek outside design paradigms.
3. Draw a map
I recently did the Design Sprint Workshop with Jake Knapp and one aspect of this approach I particularly like, is the inclusion of a step for drawing a map. To quote one of the slides from the presentation.
“The Map is messy. It never feels right. But if you do it, you’re doing it right.” Jake Knapp
A major reason I think drawing is important, is that the act of drawing (especially on a whiteboard) is a powerful forcing function for consensus among teams. This is in part because many people are visual learners, but is reinforced by the act of drawing itself — drawing is a leadership skill. It’s easy to dismiss scribbles on a whiteboard but the truth is drawing is a communication technique that pre-dates complex written language. If you passively observe teams those that draw reach consensus far faster. Additionally, an individuals that draws disproportionately contributes solutions to that team.
4. Plan for feedback
Drawing often can lead you to identifying the key user interaction for your product. Many people fall back to conversion rates, and shopping cart style workflows and funnels. This can be effective for many products but often feels transactional or irrelevant if your product is a backing service or API. Regardless, hopefully you can identify the “star metric” for your product during the design phase and build in engineering time to instrument your product to produce accurate and reliable metrics.
Too often, I see Product Managers run out of engineering resources or time to implement appropriate metrics. Don’t make this mistake. Remember, at this point your new product or feature is only a hypothesis — it needs a variable and control to sufficiently become a testable deployment.
5. Have a writing process
Once you have taken these steps, hopefully the ideas and words are starting to from naturally for you. Having writer’s block when it comes to user stories is usually either a lack of understanding the problem or a lack of consensus on ideas for a solution. It’s best to establish a writing routine and block uninterrupted time to write user stories. I also separate the writing process from the prioritization process as doing both at once becomes overwhelming quickly. I find when I focus, and write on a regular routine I can quickly produce high quality user stories most of the time but a portion of the work will seem illogical when I revisit later. That’s fine. It’s part of the writing process.
6. Know your audience
As any writer would acknowledge, understanding your audience is foundational in communicating effectively. User stories are just a powerful form of communication and understanding the team that will be implementing your user stories is hugely important. If you are new to the team don’t rush into writing stories — learn about your team first! What technologies do they prefer, what tools do they have access to and what common patterns have they adopted. Knowing these things will save you a tremendous amount of re-writing and shuffling later on. Additionally, consider secondary audience members like stakeholders, or testers as they may be viewing your stories as well.
7. Write your story
Once you have your coffee brewed and your inbox closed it’s time to break down the story into the following components.
User Value Statement — As a user I want to some action, so that I can some value. To many novice writers this step can feel awkward and mechanical but this common approach will yield benefits of consistency over time. If you are really struggling with this it may be worth reviewing the previous steps — you probably are not ready to write a user story for this feature. Also beware of statements like “as a Product Manager”, delivering value to yourself is not the intent of user stories.
Acceptance Criteria — Acceptance criteria should capture the key design constraints that apply to the solution without suggesting implementation specifics. For example if the story involved some sort of cache invalidation you might say something like “ensure the value is updated within 5 seconds”, not “set a ttl of 5 seconds”. The latter is bad for two reasons. The first is that implementation details are not relevant to the value the user will receive. Engineering methodologies are constantly changing and something as simple as a cache has dozens of implementations. It is the engineering teams job to choose the best approach, not yours. The second problem is the use of abbreviations which you should consciously avoid. While the primary audience for your user story will likely understand the abbreviation through context, limiting abbreviations makes your backlog more accessible to stakeholders and prospective team members which can have beneficial effects down the road.
Steps to Test — Many Product Manager suggest using Girkin syntax to write acceptance criteria (Given, When, Then) but I find including a separate section about testing to be a cleaner approach. On the surface this may sound redundant to acceptance criteria, but it should contain much more specific direction to follow. This will include things like what environments you may be testing in, any commands or actions you plan to take and the expected results you will see. Including steps to test saves a tremendous amount of time when it comes to testing and can often be the easiest place to start writing a story if you are stuck on some of the other components.
Title — While I usually start with a placeholder title, I almost always revisit the title of a user story after the body is written. Titles end up in emails and discussions so having a concise and communicative title ends up being important.
Resources and Taxonomy — Following this process should not yield lengthy prose about the feature and may in fact simplify some complex information that needs to be communicated to the developer. That’s where attachments work best. Spreadsheets, and designs are more effective than words for communicating large amounts of complex information and leaving them out of the user story itself gives engineers the ability to gain context before diving into the weeds. Additionally take the time to tag and classify your user stories in some way, this will help a lot when it comes time to prioritize.
8. Review and critique your writing
After writing your user stories I find it best to take a step back and let some time elapse before revisiting them with your team. Ideally this means revisiting them 24 hours later with one of the engineers on the team, but even if I don’t have this ability in my schedule I will at least take a 15 minute break before re-reading and editing my writing — again hopefully with an engineer or someone else on the team.
The final review for user stories is a planning meeting with the entire team. Hopefully at this point you have improved your writing enough that reading the story out loud doesn’t reveal any flaws in logic or stilted language. Managing an effective planning meeting could be its own post, but in the context of user stories consider this a key moment for feedback.
This is also your last chance to change the user story. More experienced PM’s will feel comfortable re-evaluating acceptance criteria and user value statements but this is often where PM’s that are still learning get frustrated with the process and make mistakes. If your team doesn’t understand the user story and is having trouble estimating, that’s ok. The user story is not ready and the value to your user is not fully understood — the last thing you want to do is starting to get attached to a solution and waste engineering resources building it.
9. Love your backlog
This is hard to teach, but really caring about your user stories is an important drive for Product Managers. This can also be challenging because once a story has gone through a formal review process with the team, you are not supposed to touch it, right? While this is true for the contents of the user story, the contract I have with my teams is that priority, and classification of the story may be added after the planning meetings. These changes do not change the complexity of the user story, and they provide sufficient tools for reprioritization. Having this informal contract also helps define clear boundaries for interruptions and priorities in your backlog.
10. Design a delivery system
My final piece of advice for teams is to look beyond the minimum viable product, and think more completely about the life cycle of your product and how your product including features will be tested by users. If you organization is new to lean simply shipping a smaller simpler product may be enough of a shift in approach, however for digital teams thinking about approaches to “dogfood” features, segment users and gain empirical evidence should be the focus.
Too often I see MVP become a catch all for the term “release” and the focus becomes what in and out of the release rather then, what portion of our users will be impacted by this new feature and how are we getting feedback from those users. While I regularly still use the term MVP, I recently have been revisiting the Alpha, Beta, and Generally Available as more meaningful labels for the release process.
I have probably written thousands of user stories at this point and following this process has allowed me to be a more effective Product Manager but I encourage you to adapt what works best for you, and share your thoughts below.
