In the previous post in this series I provided some insights into Product Backlog. In this post I will explore Sprint Backlog.
Sprint Backlog
It is a set a selected Product Backlog Items from the Product Backlog for the sprint and a plan of how to create a potentially releasable “done” increment that realizes the sprint goal from the selected product backlog items.
Scrum Team collaborates during the Sprint Planning event to create the Sprint Backlog. The Product Owner usually tells “What” needs to be done in the upcoming sprint and the Development Team decides on “How” they are going to implement the desired functionality. Product Backlog Items need to be in a “Ready” state that is they should be – detailed enough, ordered and estimated – before they can be pulled in to the sprint.
Sprint Backlog is a forecast about the functionality that can be delivered in the upcoming sprint. It is not a commitment, it keeps changing as more is learned about the work to be performed during the course of the sprint. Since the work keeps emerging and the associated plan keeps changing, it is also termed as a living artifact.
The Development Team owns the sprint backlog. The Development teams inspects and adapts it, at-least once everyday during the daily scrum. New work gets added to the sprint backlog as needed. When some work is completed, remaining work is updated. When work is identified as unnecessary it gets removed. It is solely owned by the Development Team and only the Development Team can make any changes to it.
As the Product Backlog, Sprint Backlog also helps in raising transparency. It raises transparency for the development team by making all the work visible to the Development Team. The Development Team uses the sprint backlog to track its remaining work throughout the sprint and thus manages its progress.
