There are a lot of posts and opinions about types of Product Backlog Item’s (PBI’s) and what you can or can’t consider an item on the backlog.
Some say the backlog can only contain items that deliver value to the product directly. Some say you can put anything on your product backlog, like technical things and meetings… I even saw holidays, lunch meetings and doctor appointments on a few backlogs. Others only use the user stories notation, also for bugs and technical debt.
| Scrum Guide: The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. |
So, according to the Scrum Guide, your product backlog is a prioritized list of items.
These items can be picked up by development team(s) and turned into a working increment.
There isn’t a formal definition of the items on a backlog, and I believe this is a good thing, because you can decide for yourself what’s appropriate and what’s not.
And that’s my message of this post. Decide for yourself. Experiment with different types of PBI’s and discuss it with your team. Use your retrospective to reflect and how to improve the quality of the backlog.
But to get you started, I’ll give some tips and tricks which I gathered over the years.
Value to the product
Let’s start with the value. Every item should be adding value to the product or process.
Value can be directly linked to a feature. A feature that enables a user to save 45 minutes every day is very valuable.
An item that unlocks new features is also very valuable. Creating a mechanism to easily check the user’s version of the operation system could be handy when the product depends on the system its running on. Indirectly, this item adds value to the product.
I wouldn’t put meetings, holidays or other personal and organisation related items on the backlog. They are, of course, very valuable to the concerned team members, but not to the product.
Value to the process
Items which add value to the process could also, indirectly be adding value to the product.
For instance, if CI (continuous integration) isn’t implemented yet and the development team will definitely benefit from it on a daily basis, it’s worth checking its value.
Ask questions like:
- What’s the risk of not having it?
- Is working without CI counterproductive and maybe even error-prone?
- Did the product already suffer from any bugs related to this?
- How does the process benefit from implementing this widely known technique?
Similar examples are: automated testing, database migration, redundancy ideas, monitoring and alerting, etc.
Discuss these process related items with the team and PO. Together you’ll need to figure out what’s beneficial to the process and product. Don’t drown in the technical part of these items, always think of the relation with the process, look at the cost, risks, necessary knowledge, etc. Try to time box and learn from improvements like these in the past.
Transparency and visibility
The backlog and its items need to be very transparent and visible.
Everybody; team members, stakeholders, people from operations, management, other PO’s and teams, etc., etc., need to be able to view the backlog items. This is crucial to the process. The process that depends on openness and trust. By adding the correct items you’re making the backlog transparent and you’re fuelling this openness.
Never complete
The backlog will never be complete. There will be changes during the entire lifecycle of the product. Priority will shift, requirements change and company strategies alter. And that’s fine. So, your PBI’s priority and the content will change too. Nothing to worry about, use this fact in your advantage.
PBI vs Task
The product backlog consists of items. An item can be composed of tasks. The difference is pretty straightforward. Tasks are pieces of work that need to be done to get the item done. Common tasks are design, development, database work, frontend, backend, testing, etc.
Testing
Writing test scenario’s and testing aren’t PBI’s. They are tasks and part of a PBI. In agile product development, testing is not a separate phase, but an integral part of software development and focuses on repairing defects immediately. Testing is probably also on your definition of Done.
| Scrum Guide: The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. |
Types
But what does the Scrum Guide mean with “an ordered list of everything“. What is everything?
There are many different types of product backlog items (PBI’s). Here are the most common and widely used. This enumeration isn’t complete, it’s just here to give you a head start.
User Story
The user story is probably the most common item on the product backlog. The user story is a user centred requirement and it’s a very powerful PBI when using it correctly. Please read my User Story blogpost to grasp my vision on this particular PBI.
Sliced user story
The story can be too big for a sprint. There are several ways to slice this story into smaller pieces. These small pieces are all on the backlog and can sometimes be notated as a user story, but is not necessary. Remember that all these slices contribute to the bigger original story (the cake).
Bug
A defect or bug is a fault in the product.
This can be anything from a user interface issue to a backend service not returning a value correctly. Bugs can for instance, cause product outages or can stand in the way of the user acceptance and needs to be solved. Some instantly, other can wait a bit.
I always put bugs on the backlog. Bugs are part of the software development process and you should not be surprised when defects occur. Do not hide them, be transparent and put them on the backlog.
- When it is a visible bug, you can add screenshots, reproducing steps and other essential information that can help the developer fix it.
- If the bug is a very technical issue, I always let the developer write the PBI and I’ll add the risk of not fixing it. By adding the risk component, you have a good and objective way to prioritize this PBI.
Bug tracking systems are pretty powerful for logging and tracking defects. If you use these kinds of systems there is a change you won’t place the bugs or defect on the backlog. You lose the transparency element here. And for that reason, I’m very careful with using those tracking systems.
Technical debt
Technical Debt (tech debt) is a metaphor developed by Ward Cunningham, an American computer programmer who developed the first wiki. It reflects the extra development effort that occurs when code is used which was easy to implement. This easy to implement code shall be replaced by code needed for the best overall and sustainable solution.
Tech debt isn’t necessary a bad thing. It can be deliberately used, just to prove a certain hypothesis. Afterwards you can clean up this piece of code and move on with a clean codebase.
My opinion is; always get rid of tech debt a.s.a.p. Don’t let it get in the way of your quest to reach the product objectives.
Design
Designing software, UI, database model, etc. are part of the software development process. And in many occasions, I placed a design item on the backlog. Let me be clear on this, I always strive to let the design be part of an item, for instance a user story. The entire story consists of tasks like design, development, testing, merging, build, etc. But sometimes it doesn’t make sense to do this.
If you want to get feedback on a certain part of the user interface, a mock-up can be very handy. This mock-up will be created by the development team. Designing is part of the team responsibilities, so this item should be placed on the backlog. The outcome of the feedback is input for the user story about this user interface and thus indirectly adding precious value.
Summary
Like I already mentioned, try to experiment with the different backlog items, discuss it with your team members and stakeholders, learn and move forward. Remember the importance of transparency of the backlog and its items. When the items become to technical, think in terms of risks, benefits to the process and value to the product.
Good luck with your PBI’s!
