What are the different elements and pieces of information I should capture and track within my Product Backlog?
Prior to answering this question, let’s first baseline our definition of what a Product Backlog is. A Product Backlog, at its core, is a prioritized list of qualities, characteristics or features a product could have. Think of it as an inventory of all the options a team has of things they could build. Many Agile teams choose to state these options stated in the form of User Stories.
Now, lets think about the pieces of information that are needed to have a complete User Story. The minimum needed to capture a User Story:
- The story itself (As a <user role>, I need to <goal>, so that <desired benefit>.)
Typically referred to as the Story Description.
- The story’s Acceptance Criteria.
A User Story is even better when it has a Story Name. Why? Because we know referring to traditional requirements is hard. When you have a conversation with a stakeholder and ask, “Are off of the details captured for requirement 9.7.2 correct?” There is not much context there. Ideally you can name the User Stories in your backlog with short descriptive phrases that communicating and collaborating about your product backlog easier and more effective.
Next, lets think about what details we need in order to properly plan a sprint. What do you need?
- The story
- It’s Acceptance Criteria
- It’s Size
- It’s Priority
- Any supporting details/models that have been captured to give you additional context for planning the story’s tasks. Perhaps within Comments/Notes, or at a minimum a comment or note that refers to where the additional details are kept.
So, where does that leave us? At a minimum a backlog should have:
- Story Name
- Story Description
- Acceptance criteria
That may not be enough though, in fact -there are an infinite number of granular attributes about User Stories that you may capture in order to make the backlog useful for your team. That’s one of the great things about the Agile framework. Agile practitioners, trainers, or coaches won’t (or shouldn’t) tell you that backlog should only have this, it must have that, or it’s bad if it has something else. It’s the beauty of the Agile principle about self-organizing teams. We want you to create a backlog that is the best and most useful for your team.
Now, having said that…your backlog should be as lean as possible. Not lean as in the number of stories within in it, but lean as in the number of attributes and details you track. The more comprehensive it is, the more effort there is to manage it and our primary goal is to deliver potentially shippable increments of valuable solution early and continuously to our customer. It is not to have a beautiful Product Backlog.
To wrap this up, here is a list of other backlog attributes to consider (in no particular order). Happy grooming!
A column in your backlog that allows you to filter by the User Role for any given story can allow you to slice the backlog by user perspective to see if there is anything missing for that role, or if the priority of the stories for that role are accurate.
Is the story New, In Progress, or Accepted? (Look for another post coming soon that explores the status of backlog items in depth.)
Is it a User Story, Foundation, Spike, or Defect? (Revisit the post: Agile Q&A: Are there types of User Stories?)
Do you have a Product Roadmap with themes on it? Map the backlog item to the Theme it belongs to. It will help you view cohesive sets of stories, prioritize within the Theme and identify potentially missing stories.
Are you tracking an explicit feature list? It is likely that it will take many stories to complete a single feature. This will help you track a finer grain of granularity should managing something like a Feature Burn-Up be useful for showing progress that your team is making.
Is the story a Must Have, Satisfier, Delighter, or Dissatisfier?
Which release (number or name) are you targeting the story for?
What sprint (like a #) are you targeting the story for?
What sprint (likely a #) did you commit this story to for completion? This # could change if you commit it to a sprint, and then have to re-commit it to another sprint in the event it has to carry over.
What sprint (likely a #) did you actually start the story? This should never change.
What sprint (likely a #) did you complete – and get acceptance – for the story?
What day (a #, i.e. Day “6” of 10) of the sprint did you start the story? This can help track trends, are you starting everything on Day 1?
What day (#) of the sprint did all the tasks for the story get completed? This too can help track trends, are you waiting and leaving a lot in progress finishing everything on day 8, 9 or 10? This data can also be used for building a Burn-Up chart.