3

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?

3

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.

  • Shouldn't historical capacity be at least relatively straightforward to apply during holidays? Determine the fraction of a normal sprint ("this sprint is only 2 instead of three weeks, so 2/3rds a spring") and multiple that by your average velocity. Sure, the effects are probably not perfectly linear. But I expect it is closer than most teams gut expectations. – Chris Pitman Dec 3 '14 at 14:42
  • You can use a rough 'hours per day' historical average and then plug in the days off and you should get a good guess at your total hours capacity. Visual Studio Online/TFS have this type of planning capabilities in it and it can be helpful. However, people tend to get caught in the accuracy (or lack thereof) in the task hours estimates. – Jay S Dec 4 '14 at 12:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.