- Having a task list helps plan what needs to get done. The product backlog helps everyone in the scrum team see what needs to be done for the product. The product backlog essentially is a to-do list of everything that is known that needs to be done in the product. It's used to see and describe all of the upcoming work on the product. It's a single source of requirements for any changes that need to be made for the product. It's made of a list of ticketed pieces of work, also known as items. A product backlog is dynamic and constantly gets updated as requirements change or new features to the product are added. The product owner is responsible for the product backlog. They keep up-to-date with all of the latest requirements and keep it priority-ordered. Okay, so what do the items in the product backlog look like? Well, it depends. Most will have the name of the feature and the description of what it should be when it's considered done. This description could be a test description, so once it passes the test it's considered done. Some teams may use software to track product backlog items. Others may use sticky notes and a giant wall. It's entirely down to the team and the process and workflow that works best for them individually. If all of the dev team are in a single office, it might make sense to use sticky notes, whereas a remote team may track items in the product backlog with software. So how big is the product backlog? Well, as the product is released and shared in the marketplace, users may ask for additional requirements, or the stakeholders may think of innovations to improve the product. These then get added to the product backlog by the product owner. Furthermore, business requirements, changes to market conditions, or even new technology may cause changes to the product backlog as well. This means that the product backlog for a living product will become larger and more exhaustive. Requirements never stop changing, and neither does the product backlog. The development team and the product owner need to work together in a process called refinement. This is a constantly-ongoing process in which the items added by the product owner are reviewed, estimated, and revised. It might be that the product owner has requested a piece of functionality that already exists, or is already a ticketed item. The refinement process also includes the ordering of tickets. This indicates when a ticket is likely to be worked on. The higher up the order, the sooner it'll get worked on, so items higher up in the backlog tend to be more highly detailed than items lower down. This is perfectly acceptable. As items move closer to the top, part of the refinement is to get them clearly described. The refinement process also means ensuring the ticketed item can be completed and done within an upcoming sprint. If it's estimated to be too big for the sprint time box, part of the refinement process is to see if it is actually a piece of functionality that can be further broken down into more manageable chunks. Refinement shouldn't take any more than 10% of a dev team's time. Depending on the size of the product backlog, multiple scrum teams may work on the same product backlog. Remember, it's used to see all of the upcoming work on the product. This means that stakeholders and a scrum team can also, using the order of the backlog, predict when a certain piece of functionality will be built into the product. Okay, so my product backlog is refined, I think. What happens next? Well, now that the backlog has items that can be done within a sprint, these items are selected for sprint planning. These items will get pulled into the sprint backlog, which'll be talked about in the next video. Keeping an up to date product backlog helps everyone know what is going to happen with the product, and helps the product owner forecast when a particular feature will be implemented. This forecast can then be broadcast to the wider organization.