Creating an Effective Sprint Backlog
28 July 2016
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
For a sprint to achieve its goal, creating an effective sprint backlog is one of the most critical tasks you can complete. If handled correctly, an effective backlog can do wonders for any team and project. One way of creating an effective sprint backlog is to combine the velocity-driven approach with the commitment-driven approach.
A velocity-driven approach means the team picks up as many top stories as necessary for the total of story-point estimates to equal the team's historical velocity. Under the commitment-driven approach, the team identifies its capacity by deriving the total available hours in the upcoming sprint for all team members. Then, each selected story is split into tasks, and each task is usually estimated in hours. When the total of task hours equals the team capacity, the team can commit to those stories only. Other stories remain in the product backlog to be picked up in the next sprint. If too few stories are selected, the team can add more stories later on, splitting them into tasks, estimating them, and matching the total estimated hours with available capacity.
The combined approaches help with forecasting whether the team will be able to deliver according to prior sprints or whether the team velocity is going to decrease or increase. Subject to the condition that the team composition will not changing during the project, it provides the team with one more chance to look at the reasons behind decreasing or increasing velocity during sprints.
If the team knows its velocity at the start of the sprint, it should be able to achieve its goals within that sprint, but this is ultimately determined by how effectively the team capacity is leveraged. Team members often forget to exclude meeting times, break time, and time spent on any other activity that is not part of the sprint. They simply give the actual office time. And to have the effective team capacity, each team member should specify those hours that they are expecting to spend only on sprint work. This ensures that calculated team capacity hours are the hours the team is going to actually spend working for the sprint.
In a nutshell, combining both approaches helps provide a much more accurate forecast of the amount of work the team can do. It's also shines a light on the reasons for any increase or decrease in velocity. The combined approach ensures that the real essence of Scrum is captured, by achieving the sprint goal and delivering a shippable product at the end of every sprint.
Current rating: 4.4 (5 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.