A practical guide for product managers and product owners in an increasingly scrum world.
Recently, I convinced several high performers from other areas of my company to join the Product Management team. We needed people who understood our product well to help prioritize the next generation of features. There was one big catch: They weren’t product managers and didn’t know anything about the scrum methodology or being a product owner. What follows is the guide I created for my new team to teach the basics of user stories, backlogs, and more.
When a product succeeds, it’s because everyone on the team did what they needed to do. But, when a product fails, it’s the product manager’s fault.
— Marty Cagan, Inspired
This quote from the quintessential product management book, Inspired, by Marty Cagan, is a really concise summary of the product manager dichotomy. Writing quality user stories organized into epics and building a solid backlog are the best ways to set your team up for successful software launches while avoiding catastrophic failures.
People Also Read: What is Product Quality? A Practical Definition
User Stories
Definition of User Story
User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.
User stories are short, simple descriptions but power constructs of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a <role or persona> , I can <goal or need>, so that <why>
As a <user class>, I want to <perform or do something, so that <I can get value or benefit>
User stories need to meet specific criteria to be considered “ready” by the scrum team. The most popular is INVEST:
Independent: The lowest level of functional decomposition — they should stand on their own and allow for the business to change direction with minimal cost and impact to emerging requirements
Negotiable: High level enough that implementation is flexible — there should be enough room to inspect and adapt the implementation based on constraints and business requirements
Valuable: Demonstrated value to the business and the user — each user story represents an increment of product that can be demonstrated to a potential customer of the system
Estimable: Sufficient knowledge about how the user story will be developed (and tested) that the scrum team can provide a high-level estimate for how long the user story will take to implement
Small: Sized to Fit. Such that the work to deliver the user story can be completed in a sprint to facilitate faster time to market and feedback from customers
Testable: Using well-defined acceptance criteria prior to any implementation work — what will it take to satisfy our customer’s need and how will we verify that those needs have been met
If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).
Let’s expand on testable criteria. Every great user story has even better acceptance criteria! Acceptance criteria is focused on the intended outcome as a result of the action specified in the user story. It should always focus on “what” instead of “how”. Here is a simple format to follow when writing your acceptance criteria:
Given <some pre-condition(s)>, when <some action(s)>, then <expected result/behavior>
Pre-conditions are optional — they don’t always exist.
Estimation
So far I have covered how to write a user story and acceptance criteria. Now you will need to work with the scrum team to estimate the “bigness” of each user story measured in story points. Bigness encapsulates three key factors:
- The amount of effort to deliver the user story
- The complexity of the work
- The risk or uncertainty in doing the work
Everything involved in getting a user story to “done” goes into the estimate — including research, testing, and any activity to get the story over the finish line. For example, if your definition of “done” includes creating automated tests (always a good idea) then the work and complexity of creating each test should be factored into the estimate.
Let me digress a moment. Estimation can be a difficult concept for teams that are accustomed to providing time-based absolute estimates. Story points, conversely, are relative estimates. Defining a reference story is a great way to help teams transition to estimating using story points. Check out this YouTube video to learn more.
Each user story should be estimated such that it can be completed in one sprint. If the bigness is larger than what can be done in a single sprint then you, as product manager, need to break it up. The most common story pointing systems uses the Fibonacci sequence to estimate relative bigness. I have seen teams vary between 8 points and 13 points as something that can be completed in a sprint. As the product manager, you should assume that user stories larger than 8 will not be accepted into a sprint.
After a few sprints you will be able to calculate a very useful planning metric: Velocity. Velocity is the average number of story points the scrum team completed over the last three sprints. This is a great metric to plan and forecast what the team can accomplish in future sprints. Be careful though, this metric is specific to each team and is not a good measure of performance. Always use story points and velocity as planning tools.
Suggested Read: Why you should stop focusing on adding just new features to your product
Epics
There are situations where you will deal with a story that must span multiple sprints, a larger project, or a new feature. You will have a set of user stories to accomplish your task but need a way to stay organized and understand when the project or feature is “done”. In these situations we use a construct called an epic. Epics are simply larger user stories. They are used to group user stories that when delivered result in the completion of a project or large feature. Just like user stories, epics also have a beginning and end. Once the project is over or feature delivered the epic is closed.
Product Backlog
The product backlog is the list of all the work that needs to get done. It usually contains user stories, bugs, technical tasks, and knowledge acquisition. The backlog is periodically refined by the product owner and scrum team to ensure 2–3 sprints worth of work is always defined and prioritized.
A solid backlog should be DEEP:
Detailed: Sufficiently detailed such that any member of the scrum team can work on the user stories independently
Emergent: Flexible, work will fluctuate based on the needs of the team, business, or customer
Estimated: Size and complexity is estimated using story points — If a story comes with a high estimate it is likely large enough to break apart into more than one user story
Prioritized: User stories are ordered in the backlog based on product priority — If all stories in the sprint are completed early the team should pull in the next user story on the backlog
Backlog refinement sessions are led by product managers.
You will always want your user stories to meet the INVEST criteria. Some simple tips to make that refinement meeting run smoothly:
- Invite the whole team! That includes UX, testers, etc.
- Have your user stories written and distributed to the team so they can review before the refinement session.
- Prioritize the user stories.
- Limit conversation per user story using a timer — if it takes longer than the allotted time you probably need to go back and define the user story better.
- Estimate a reference story so that you can estimate the rest of your stories relative to the reference.
- Spend enough time on refinement — if you’re just starting out you may need to spend a couple of full days to refine the backlog.
Closing Thoughts
That’s it. You’re a pro. Just kidding. Like all skills, repetition will lead to mastery. The first few sprints will feel overwhelming. Time and experience are your friend. Stick to the ceremonies and foster a culture of participation — you’ll be amazed at the results! Good luck and happy backlog refining!
References