A question that I see often is:
How do you (Should you | Can you) use user stories to properly document requirements for a product?
There are some people nodding in agreement “yes, I’ve often wondered that myself.” There are others who are cringing.
User stories weren’t intended to be requirements. Kent Beck originally came up with the idea for user stories and described it to Jeff Patton this way:
If we get together and talk about the problem we’re solving with software, who’ll use it, and why, then together we can arrive at a solution, and build shared understanding along the way.
From User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton
User Stories were intended as a means of providing some structure to conversation, to act as placeholders if you will. The ultimate aim of that conversation is to make sure everyone working on a product has a shared understanding of the product and what outcomes it’s intended to produce.
They weren’t intended as a documentation vehicle.
I find conversations with my team about what we need to build are invaluable. I also find that hand waving, sketching, pointing, and moving cards around during those conversations help us get to shared understanding much quicker.
User stories help us to organize our work and our conversations. Models, acceptance criteria, and examples help us during the conversation to make sure we’re all on the same page and help us afterward to remember what we talked about so we can go build it.
We don’t rely on user stories themselves to describe what we’re building. They’re the outline. The description comes in the form of the models, acceptance criteria, and examples we create during our conversations and keep around as we build the product.
We may use some tool to track our product backlog. The user stories in that tool are items that we use for planning discussions. For the stories that we’re about ready to deliver, we have a conversation and record relevant acceptance criteria and examples in that item and link out to relevant models. It’s helpful to keep that information grouped together in the context of that story, although we’ll find that some information is helpful to group in the context of the broader product.
Afterwards, some of that information may be incorporated into system documentation if we think it will help with future updates to the product. Some of it is thrown away because it is no longer relevant given the new context of the product.
So instead of asking “How can we use user stories to document our requirements”, perhaps a better question to ask is “how can we build and maintain shared understanding of our product and it’s intended outcomes?”
From the Agile Alliance
Agile Alliance is a great place to go to get information about all things agile software development related. (I am admittedly a little biased). Including several great resources on working with a product backlog.
Product Backlog Management: Tips from a Seasoned Product Owner
Here are some product backlog management tips for product owners and teams from an experienced product owner and coach.
What do user story conversations look like?
User stories are placeholders for a conversation. Who should be included in those conversations? When do you have these conversations? What should you talk about? How do you remember what you said?
Epics have taken on a variety of meanings in software development. Are they big user stories? Are they a different kind of backlog item? Does it really matter?
Continual Backlog Refinement, Get Stories to Ready
This session from Agile2013 introduces real world strategies for working across roles to look ahead and actively prepare your user stories for upcoming iterations. Note: You need to be an Agile Alliance Subscriber to view this content. You can get your free subscriber account here.
Are you frustrated with lengthy and inconclusive backlog refinement sessions? This workshop provides techniques to improve the speed and effectiveness of portfolio, program and team level backlog refinement. Note: You need to be an Agile Alliance Subscriber to view this content. You can get your free subscriber account here.
Cultivating Agile Requirements
This Agile2014 video shows how to create an adaptable process to handle constant backlog change and provide valuable information at the right time for your team and stakeholders. Note: You need to be an Agile Alliance Member to view this content. Find out more about Agile Alliance membership.
Like What You See?
This is a sample issue of Inside Product. If you’d like to get weekly pointers to resources for product people, sign up for the newsletter.