What’s Product Backlog?
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
The Scrum Guide
Any work that developers do is pulled from Product Backlog. A single pieces of work that make it up are called Product Backlog Items, or just items. Interestingly, they can take any form. The most commonly used are user stories although they’re not part of Scrum. Product Backlog is a great tool to discover what we don’t know that we don’t know. To put it simply, it’s a list of everything that (we believe) needs to be done as part of a product (at a given moment). It’s more that requirements gathering, as this activity also embraces their prioritization that will meet the Business needs. These are determinded by the Product Goal. At the same time, everything is done to make costs as low as possible. PB is created in the very beginning by the Product Owner and stakeholders (the business side) and developers who provide the technical input.
The DEEP approach
DEEP stands for Detailed enough, Emergent, Estimated and Prioritized. That’s what Product Backlog Items are like. Items should be small enough for the Scrum Team to turn them into an Increment within a Sprint. Any work selected from the Product Backlog can be taken as a hypothesis, as we aren’t 100% sure we’re going the right direction until the client gets the working piece of the product and gives their feedback. The Scrum Events are the for the change to take place. That’s sometimes called the inspect-and-adapt loop. Any change is reflected by the Product Backlog. During the Product Backlog Refinement sessions, Items are renegotiated, re-estimated and reordered. Product Backlog is never complete, and never the same. Size estimates need to be reasonably accurate without being overly precise. We’II talk about estimation in a separate post. It’s the Product Owner who
Product Owner takes care of PBIs
The Product Owner representing the business side is accountable for establishing work to be done. They manage the Product Backlog by preparing, ordering, and translating PBIs for those who will turn them into a working potentially releasable product (MVP). Of course, they are allowed to do delegate these duties to anyone else; however, it’s still the PO who is accountable for PB. Furthermore, the PO ensures that the PB is transparent, visible and understood to all, including stakeholders. The Product Backlog must be written in such a way that is perfectly understandable. The way it’s written down might be the standard agreed and discussed by everyone.
Priority or Order?
The latest version of the Scrum Guide reads Product Backlog is ordered, and not like it was before, prioritized. First, let’s define what “prioritize” means. To prioritize means to order tasks in terms of importance so that you can deal with the most important. The problem is, once being asked what item out of the Product Backlog is the most important, the client might say “this and that”, or much worse “all items are equally important”. Then, the PO might have a tough task of talking them into putting off doing the work of higher priority due to lack of favourable conditions. This might be, for instance, some developers being on sick leave. Only the Scrum Police can stop the Product Owner from ordering the PB by priority. Work can be order by ROI, value, technical or business dependencies, sheer urgency. Before starting the most critical work, we first need to define what to do to reach how.
Tools to create and keep the Product Backlog
There are a number of ways the PB might be created. Some pretty common ones are:
PBIs can be kept either as a post-it-note cards or in electrical form. It doesn’t really matter. What matters is everyone has access to them. Although it’s Product Owner who is accountable for the PB, anyone can write the requirements down. The best idea though is that the whole Scrum Team do so, and as a result, these responsible for the actual work will have a better understanding of it.
