So what is a product backlog? It is a prioritized list of requirements, epics, stories, features or whatever you want to call it – things that the customer is looking for expressed in business languages and targeted towards business goals. The product backlog is the responsibility of the product owner.
The product roadmap and requirements provides the foundation for the product backlog. The product roadmap will break down into several epics and each epic will have several requirements and user stories.
Usually there are some fields which are needed for a product backlog to be inherently useful:
| Unique ID | This is to avoid losing track of stories when we rename them. |
| Name | A short, descriptive name of the story. |
| Importance | A method to denote the importance of the story. This can be sorted on the product backlog (higher up = more important) or a field with a number (higher number = higher priority). |
| Initial Estimate | The team’s initial assessment of how much work is needed to implement the story relative to other stories in the product backlog. The unit used is story points, which corresponds approximately to “ideal man days”. |
| How to Demo? | A brief description of how the story will be demoed during sprint review/demo. This field is critical as a way to prevent misunderstanding of how the story is interpreted among different members of the team. |
| Notes | Additional information about the story with links to other documents, GUI mockups from the designer, etc. |
Additional Fields
Some of the additional fields that are mostly for convenience purposes to help sort out priorities are listed below:
| Track | A categorisation applied to the story, for e.g. “optimisation” or “back office” which helps the product owner filter out items in a specify track to further elaborate on easily. |
| Component | A multi-select field denoting which project component will be affected by the user story. For e.g. “database”, “server”, “client”. This is especially useful projects where we have multiple scrum teams; this can help those teams pick up stories relevant to the team’s capabilities. |
| Requestor | This field can be used by the product owner to keep track of the stakeholder/customer who requested the story/item so that feedback can be communicated about progress on the item. |
| Bug Tracking ID | If there is a separate bug tracking system where bugs are reported; it is useful to capture the bug tracking ID in this field to reference the story/item to the bug it is working to resolve. |
Product Backlog Prioritization
It is important to keep the product backlog prioritized so that the team can know which work item to pick off to work on. We can use a field call priority (numerical) or depending on the tool being used to capture the product backlog, priority can be denoted by order (higher up = higher priority).
The development team does not work through the product backlog at the product owner’s pace. Instead they pull items from the product backlog as per the priorities defined and according to the capacity they have.
Tools like Trello provides this sorting capability and is one of the products of choice for many teams maintaining a product backlog:
Keep Things at the Business Level
The product backlog needs to be kept at the business level. There are times where the product owner might have a technical background and put down a technical story (a.k.a “tech story”) description in the product backlog. Tech stories are stories which lack connection with business goals.
The aim of not avoiding tech stories is to focus the team on work that brings user value.
Dealing with Tech Stories
There are a some ways in which we can tackle tech stories:
- No tech story: We do not create a tech story at all; if the team is aware of the work needed to be done; it is agreed upon and performed without the overhead of creating a story.
- Rephrase the story: If the story is too technical in nature, we can rephrase it so that it has more of a connection with a business goal. For e.g. “add an index to the users table” can be rephrased to “Improve user search performance”.
- Create tech stories as subtasks: Add the tech stories as sub-tasks to a business-level story so that it can be linked to a business goal with the aim of bringing out user value. The tech story can then be tracked together as part of the overall story.
The team can also agree on a percentage of time during the sprint planning process which will be allocated to dealing with tech stories. For e.g. we could say 20% of sprint time would be to address tech stories with the method of dealing with the story in line with one of the above three ways of handling tech story.
If the team is constantly wanting to put out tech stories for “refactoring”; this means that most likely refactoring is not being done frequently enough. The best way to deal with refactoring would be to perform them as part of the sprint in-line with the stories being worked on during the sprint. This prevents unnecessary refactoring which are not connected to business goals and making sure we are not refactoring for the sake of refactoring and end up with an over-engineered product.