Scrum Artifact

Sprint Backlog

Sprint Backlog is a list of things to do to gathering tasks from the selected Product Backlog, that is, a list of problems Team will be developing in the next Sprint and a short plan of how they will accomplish these enhancements.

It is created during the Scrum Planning and lives until the current Sprint ending – for 1-4 weeks then. For each Command, each step creates the new Backlog for itself.

Initially, all this information on releases (that has to get to Sprint Backlog) is exposed by Product Owner. However, the decision on acceptance of work in Sprint will remain for Development Team. But it is a right tone if you first make a specific decision about how the team decides to enter a particular task in the Backlog list. Also, you should determine the degree of influence of Product Owner.

During the sprint, team members should update the Sprint Backlog as new data becomes available, but at least once a day. Many teams do this during the Daily Scrum. Once a day, the Scrum Master calculates how much work is left for the current sprint and builds a schedule.

The fact is that when you generate a Sprint Backlog, you may gain some problem with Product Owner: what they planned to complete during this sprint may not be the right plan and performance. In this case, the ability of the team and the product owner to interact with each other is used. You can change the priority of specific tasks so that the tasks that are important to the owner and rose them higher in priority.

Of course, the problem of removing an item (also crucial for the product!) from the Sprint Backlog list will not go away, but here you can choose one of two ways to solve the problem. One of them is to reduce the amount of work due to solutions and upgrades available in the default technologies and do not need revision. The second way is to split the tasks into several parts and arrange them in such a way that the development milestones still show the whole image of the product.

Ultimately, with the correct management of the Backlogs, both Sprint and Product, the team should have no problem with progress tracking. Besides, due attention to this part of the development will help not to be confused in tasks between teams: once they are distributed by Sprint Backlogs, one team will not take on the tasks of the other and vice versa.