4.4: Practices of Product Backlog Management - Video Tutorials & Practice Problems
Video duration:
3m
Play a video:
Video transcript
<v ->Now let's talk about practices</v> of product backlog management. When we speak of a well-architected, thoughtful backlog, we use terminology such as product backlog health or hygiene. What does it take to create and, most importantly, maintain a healthy backlog? A brief answer is that it takes a lot of thought and discipline. So some of the basic rules include that your product backlog has to be prioritized, top to bottom. There should be a well-thought through and communicated product backlog-management process. So in some companies, there is an intake process as well, where anyone can add items, epics, user stories, spikes and so forth to the product backlog. However, they have to set a specific flag, which indicates to the product owner that these are just ideas. They are subject to review and prioritization by the product owner. Sometimes there is a separate backlog that goes through the intake process. The intake process can be done by the product owner or, in some very large organizations, by a group that includes product owners, software engineering leaders, business stakeholders, and other relevant parties. Besides the intake process, it is important to ensure that there are no duplicates or overlaps. All user stories for at least one sprint in advance have to be well thought through. Acceptance criteria should be well documented. Overall, the quality of acceptance criteria is very important, because test cases are frequently based on acceptance criteria. So the quality of this acceptance criteria will define both product scope and the product quality. Well-defined acceptance criteria allow for accurate estimation of a user story. And we will talk more about it in less than five, but for now, suffice it to say that user story estimation is the amount of effort that is required for the team to complete this user story. And, finally, it is important that technical leader contributes to the product backlog. They do it in collaboration with the product owner who owns it and is the ultimate decision maker. This is important, because the product that needs to be built have to be safe, extensible, and cannot generate technical debt, which means that if there is technical debt, it is hard to manage, it is hard to provide good quality to the customer and keep a healthy backlog. I think that's similar to any human illness. Finally, it is important that technical leader contributes to the product backlog in collaboration with the product owner. It is important to ensure that the products that are being built are safe, extensible, and do not generate any technical debt or technical rework that will have to be done by engineers. The longer the technical debt is left untreated, the longer it takes to cure it, similar to any human illness.