- The Product Backlog is one of the three artifacts of Scrum. And holds all of the things that are going to be developed for the product. Ensuring the items are added to the backlog and managing the Product Backlog, is all the responsibility of the product owner. But what does all of this management entail? The Product Backlog is a living document. As long as there is a product, there is a Product Backlog. The first thing about the Product Backlog is that it should list all of the items that, when complete, will make your product vision a product reality, a tangible real product. Each entry to the backlog is a Product Backlog Item or a PBI. It's not the sole responsibility of the product owner to add this items to the backlog. That can be done by anyone in the dev team as well as stake holders. Even the customers or users can make PBIs. PBIs need to be accessible. They need to be written in language that everyone is able to understand. Don't write a PBI that's full of jargon and that only a particular member of the dev team will understand. Remember the Agile principle that, simplicity is essential. You want to keep it as simple as possible. There are a few expected fields like name and item description. Other things like due dates, priority and PBI number are not necessary, but maybe helpful for product management or auditing. PBIs tend to fall into one of seven areas. Implementation. Core work to implement the product. Architecture. Architecture should emerge over several Sprints. Design. Design should emerge over several Sprints. Security. Security is essential in modern programming and should always be considered. QA or testing. This is included as part of the definition of done. Data. Data plays a central role in most product development. The schema can emerge over several Sprints. Performance. It's included in the definition of done. Well, you want to make sure that the backlog is properly organized. And here are some attributes of a quality backlog. The backlog is ordered, prioritize based on value. It's fit for purpose. There must have Product Backlog Items to reflect the minimum requirements of the product. It has the correct level of detail. The position of PBIs within the Product Backlog, often reflect their level of detail. Items with the least detail are commonly found in the bottom portion of the Product Backlog. It makes use of collaborative input. Input from the customer, stakeholders and the development team, can influence the Product Backlog. It's forecasted. PBIs towards the top of the Product Backlog, are forecasted. They're closer to being selected in a Sprint. It's dynamic. The Product Backlog is emergent and can change anytime. It's visible. The Product Backlog should be visible in a co-located location or available via a shared tool. It can accommodate two to three Sprints. Two to three weeks of PBI should be prepared at any time. This requires some forward planning. Scrum does not mean ad hoc. Another way to manage the backlog, is to use the deep characteristics of a groomed backlog. Detailed appropriately, emergent, estimated, and prioritized. With a structured and ordered Product Backlog, the next step is to prep the PBIs for inclusion into the Sprint Backlog. You'll want to do this in a Product Backlog refinement meeting. You should do this before the Sprint planning meeting. It shouldn't take more than 10% of the Sprint to avoid excessive meetings. Under refinement session, you'll add PBIs to the backlog. PBIs can be added to a Sprint Backlog for several reasons including, additional features, bug fix, technical specs and more. Remove PBIs from the backlog. Here is one example. The Sprint is completed early requiring additional PBIs for the Sprint Backlog. Reorder the Product Backlog. The product owner can reorder the Product Backlog as conditions change. Add further detail. Further detail can be added to PBIs at any time. Allow for emerging activities. PBIs can be added as design, architecture and other aspects emerge. You don't want to over-refine your backlog too. Use the 20, 30, 50 method. 20% of the Product Backlog should be detailed, mature. 30% of the Product Backlog should have complete user stories but lack other details. 50% of the Product Backlog contains PBIs without much detail. Managing the backlog is a core activity of any product owner. It helps facilitate productive Sprint planning sessions and adds clarity for the development team.