Oh, the dreaded product backlog. What is this artifact of scrum that keeps being mentioned over and over, usually like “put it in the backlog”.
In reality, it is a pretty simple artifact.
The product backlog contains all changes to be made to the product in future iterations. This includes :
- Enhancements (yes, tech debt is also there)
- Fixes (yes, bugs are also there)
The owner of this backlog is, as the name says, the Product Owner.
The P.O. is responsible for keeping this list of changes prioritized. This means that whatever is on the top should be a higher priority than whatever is on the bottom.
Also, as you move from high to lower levels of the backlog, the amount of detail usually decreases. There is no point in detailing items at the bottom if they are not going to be picked up soon.
The P.O. is responsible, but this doesn’t mean that he/she is the only one that has to do it. The P.O. can ask the team for help with writing new features or enhancements. It doesn’t matter who does it, in the end, the P.O. is accountable for keeping the backlog healthy.
One backlog, one product. Not one team. This is a very important distinction. More than one team can work on the same backlog, but since each product only has one owner, that owner will have a single backlog for all the teams. You can then apply scaling frameworks like Nexus or Scrum@Scale to help facilitate this division of work.
It is very important to realize that the backlog is never complete. As long as there is a product, there is a backlog.
Not just that, the backlog is a living organism, constantly changing and adapting to market reality. What today is true next week could be a lie. This is why it is very important not to waste time refining low priority items. You never know if you will ever build them.