- Having a grander task list for a product helps see what needs to be done, but having a more immediate task list helps in seeing what needs to be done in the short term. That's where the Sprint Backlog comes in. If the product Backlog is the full list of required items, the Sprint Backlog is the list of those items that are going to be worked on in the Sprint. The Sprint Backlog is attached to the Sprint goal. Completing everything in the Sprint Backlog will help achieve the Sprint goal. This could be realizing a new user feature, or an update to an existing feature. This allows the development team to forecast what functionality will be ready for the next product increment. Well, yes, but there's a bit more. Continuous improvement should be an ongoing process in the Dev team. The Sprint Backlog also needs to include a priority process improvement from the Sprint retro. Also, the Sprint Backlog is subject to change during the Sprint itself. As work continues through the Sprint the Dev team will learn more about the items as they work through them. This is a natural part of working on an item. An item may be a bigger or smaller piece of work than originally anticipated. So the items description is subject to change as the item is worked on or completed. As the Dev team meets in the daily scrum, these changes can affect the Sprint Backlog. However it's only the Dev team who can change the Sprint Backlog. The Dev team owns the Sprint Backlog. Okay. But what's the point in changing everything if it's already been ordered and sized? Well things are rarely what they seem. Having a dynamic Sprint Backlog allows progress to be monitored. At any time during the Sprint the total work remaining can be surmised. This means that the Sprint Backlog is a highly visible, real-time picture of the work that the Dev team is doing. It allows the team to see if they're going to meet the Sprint goal or even pull in more work if there's enough capacity to do so. This also benefits the product owner, giving them visibility of the progress towards the product. Progress can be monitored using visuals. This enables everyone to see the progress of the Dev team and how the Sprint is going. Burndown charts are great for tracking progress visually. They have central line that shows the optimum progress, whilst a separate line tracks the real-time progress. Progress can be tracked throughout the Sprint using the Sprint Backlog. As tasks get completed it becomes easier to see if the Sprint goal will be achieved. The Sprint Backlog can also be used to help clarify a scrum teams capacity. The more Sprints a team completes, the easier it becomes to see how quickly pieces of work that are of relative size and effort can be completed. This makes it a very useful tool in the Sprint planning event.