Get certified - Transform your world of work today

Close

Creating an Effective Sprint Backlog

28 July 2016

Shipra Aggarwal
NCR Corporation


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.
 

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.



Article Rating

Current rating: 4.4 (5 ratings)

Comments

Tim Baffa, CSM, 7/28/2016 4:33:25 PM
I completely agree on the benefit of the combined approach. My preference however is to simply use the aggregate number of team hours per sprint (capacity) as another metric for the team to use in determining their sprint forecast.

For example, say a team has a velocity of 100, and usually averages around 300 hours of capacity per sprint. If that capacity number is higher for the upcoming sprint (fewer outside meetings, reduced out of sprint obligations/work), then the team may consider a forecast higher than 100 story points.

If the team capacity is less than 300 for the upcoming sprint (i.e. - vacation), the team may want to consider a lower forecast than 100.
Shipra Aggarwal, CSP,CSM, 7/29/2016 5:37:43 AM
Condition being, same team is working on sprints.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe