3

I have a question on how capacity planning helps when the sign up the work at the beginning of the Sprint. Here is the scenario I am dealing with

At the beginning of every Sprint the team signs up work on what they think can be accomplished during the course of a Sprint. The team estimates the stories in Story points. As a first step in the Sprint planning, I estimate the capacity of the team – number of days each scrum member available during the course of the Sprint. Lately I realized that the calculating the capacity of team in terms of number of days is not making any sense because team is estimating in story points and NOT in hours – because story points should not be equated to number of days/hours. So, in this context, when the team is not in full capacity (Couple of team members not available for couple of days) how should the team sign up for the work (in Story points) with whatever capacity we end up with because we cannot take the historic velocity as the historic velocity is based on full team availability

Improve this question
5
  • 2
    If your team will be at eg 75% availability for a sprint, then their velocity for the sprint will be at 75% of historic velocity. If you know their availability in advance, then where's the problem?
    – David Arno
    Jan 8, 2015 at 11:04
  • @DavidArno - The problem is that the business has legacy processes remaining from traditional project management which capture resource availability in 1/4, 1/2 or full man days. Since Story points are relative and not equatable to hours then the relative scale is not useful to the business. The standard rebuttal will be "change the business perception" which cannot be done in 1 or 2 or even 10 sprints. It's a cultural shift and not every business accepts it; therefore Scrum must be adapted to include Story Estimation in hours - not a hugely complex task.
    – Venture2099
    Jan 8, 2015 at 12:22
  • While the questions are somewhat different, it seems like this answer is equally valid here.
    – Todd A. Jacobs ♦
    Jan 8, 2015 at 15:54
  • 1
    @ David & Venture. Both your points are valid. If the business needs something in hours, David's approach works with a few extra steps. Take 75% of the teams velocity and then derive how many hours of capacity that equates to. For instance take a hypothetical team (4 resources with a 40 SP velocity, at 7 hrs/day, /w 10 days in an iteration.) Your SP to hour conversion is then 40/(4*7*10) or .14sp/hr. Now the team at 75% capacity should have a ~30 SP velocity and their derived capacity should be ~210 hours (30/.1428). Your derived to planned cap should be +/- 30% of each other to be safe.
    – WBW
    Jan 8, 2015 at 23:07
  • 1
    I'd add that in my experience, business' are horrible at going back and looking at planned capacity vs actual capacity at the end of the iteration, so using a derived capacity with a fudge factor to get the iteration rolling is often good enough to satisfy the business' desire to understand if sufficient capacity is available to meet commitments.
    – WBW
    Jan 8, 2015 at 23:19

1 Answer 1

Reset to default
9

When I inherited the current Scrum Team I am working with the previous ScrumMaster had produced a points to hours conversion chart which allowed the team to estimate in points and the business to track estimates in hours.

Unfortunately that approach is the worst of both worlds. You do not have the flexibility of relative story points and you have extremely innaccurate estimations based on the Fibonnaci sequence.

We moved to estimating User Stories in hours which would be my recommendation for your team as well, supported by the arguments of Mike Cohn of Mountain Goat Software.

I don't use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term. It would be appropriate for a team to say “We have an average velocity of 20 story points and we have 6 sprints left; therefore we will finish about 120 points in those six sprints.” It would be inappropriate for a team to say, “We have an average velocity of 20 story points so we will finish in the next sprint.” It doesn't work that way. Suppose a basketball team is in the middle of their season. They've scored an average of 98 points per game through the 41 games thus far. It would be appropriate for them to say “We will probably average 98 points per game the rest of the season.” But they should not say before any one game, “Our average is 98 therefore we will score 98 tonight.” This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.

Chia Cheng of the Scrum Alliance also argues that Sprint Planning should be accomplished in hours rather than points.

The task-hour estimation, on the other hand, is a low-level estimation made to represent the actual effort in hours needed to accomplish all the requirements of a story. Such an estimation should be done during sprint planning for highest possible accuracy, as the actual development may start the next day. - See more at: https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours#sthash.aJgABGA6.dpuf

How we operate

Our Sprint Planning agenda includes the following capacity analysis

  • Calculate the working days in the Sprint Timebox (minus planning and review)
  • Annotate each Scrum Team Member on the Calendar unless absent
  • Each Scrum Team member has a theoretical 8 hours
  • Calculate the capacity of the team for the month in hours
  • Remove 20% of the capacity for standard industry productivity overhead

The remainder will give you a fairly accurate figure of total development time available to the Scrum team. Let's use a theoretical example.

  • Sprint is 10 days
  • 1 day is removed for Planning
  • 1 day is removed for Review, Retrospective and mandatory business employment meetings
  • 8 working days remain
  • Scrum Team is six strong and highly cross functional (no bottlenecks)
  • Team Member A is absent for 2 days
  • Team Member B is absent for 1 day
  • 6 Team Members x 8 days (48) - 3 days = 45 days of total development time
  • 360 hours minus 20% productivity overhead = 288 hours of development time in reality

We can then introduce the Product Owner and the User Stories to the capacity that we have available whilst always keeping 30% in reserve. We would in this instance commit to approximately 200 hours worth of user stories.

During each working day we maintain a close eye upon the Story estimates versus the actuals to ensure that what we committed to was accurate. If our capacity remains unused near the end of the Sprint we hold a quick Product Owner update to pull a sheaf of user stories from the Product Backlog to plan and start.

Improve this answer
2
  • +10 For pointing out the tasking approach. I've done the same but run into several problems especially on larger teams with complex stories: 1) individuals rather than teams providing the task estimate, 2) over-estimation in hours when tasking by individual contributors, 3) missing tasks that emerge after planning, and 4) the additional time that must be invested to fully document and manage tasks throughout the iteration?
    – WBW
    Jan 8, 2015 at 23:16
  • All the exact same problems I face @WBW - our retrospectives and some painful team culture shifts have begun to eliminate those problems but absolutely all of your points have occurred.
    – Venture2099
    Jan 8, 2015 at 23:25

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.