The Sprint Backlog is one of three scrum artifacts. It used to forecast the functionality of the next product increment. It contains an objective set of coherent Product Backlog Increments to accomplish during the sprint. A PBI is the work needed to deliver a “done” increment. The Sprint Backlog contains the plan for completing the product increment. It aims to achieve the Sprint Goal. It is created during the Sprint Planning event.
It is highly visible meaning it makes visible all the necessary work to achieve the sprint goal. It is a real-time picture of the work and its progress is tracked in the daily scrum.
The Sprint Backlog is created by the Developers, and it belongs solely to the Developers. The Sprint Backlog emerges during the sprint as work progresses and the Developers understand more about what is needed. It unifies the Developers under one objective instead of separate initiatives. It provides the Developers with guidance on why they are building the increment. It also provides the Developers with some flexibility about the work. If the work to meet the Sprint Goal turns out to be different than expected, the Developers and the Product Owner negotiate a new scope for the sprint.
· Items are added by the Developers as new work is required
· items that are found to be unnecessary are removed
· The estimates of the remaining work are updated as work is completed
Here are some tips for Distributed Teams for keeping their Sprint Backlog:
· Keep a clear "Definition of Done” and publish it
· Use a digital product management tool and give all team members access
· Create a working agreement: “The team will update the Sprint Backlog in real-time as the work is performed”.
· Share the Sprint Backlog via desktop sharing during the Daily Scrum
· Record a 30 second show and tell of “done” backlog items for the PO to view and accept as the work is completed. This does not replace conversations as needed but improves flow.
