Scrum: Capacity vs Velocity when planning a sprint

Question

We have completed 11 sprints so far in our current project. In most sprints we have not been burning down well and usually finish with our velocity gradient flattening as we approach the end of the sprint. However, having looked back at our last few burn downs it seems we are consistent with how much work we carry over to the next sprint.

Currently we use capacity driven planning where we allocate 50 hours per person in a two week cycle. But I am wondering if it would be better to use the averaged velocities of past sprints as an aid for planning seeing as the velocities are generally consistent?

Answer 1

In my opinion, there are two different types of planning involved here.

Velocity-based planning: Velocity is usually tracked as completed story points in a sprint. You should have a good idea after 11 sprints of your average story point velocity and should be able to forecast how many 'points' your team can accomplish in an upcoming sprint.

After doing your story estimation, the number of stories you choose to tackle in the upcoming sprint should be based on this historical sprint velocity.

Capacity (hours) planning: After you have selected your stories, the task planning begins and you start estimating what will be done and how long each task will take. This will let you see how many hours of work you believe you have to do. Based on your average capacity on the team, this will help you validate whether the initial point-based planning is still on track.

My thoughts: I use capacity mostly to make sure I am tracking actual availability within a given sprint. On average, the team might have about 50 hours per person, but what about a sprint starting on December 15th? Suddenly a lot of folks are taking holidays and vacation time and the sprint capacity is affected. For this reason, I don't believe in using historical capacity's to estimate the current capabilities of the team.

My advice would be to use your story-point velocity that you have established to determine which stories to take on, and then build out the true capacity for the upcoming sprint based on resource availability.