I was participating in the VersionOne user forums and a question was being asked about capacity. I'm guessing the person was a scrum master or project manager and they were asking about whether they should plan their resource ideal capacity for 8 hour days or 6 hour days.
This is a question that comes up from managers a lot, but it sometimes gets confused with velocity. I've seen people thinking that sprint planning is based on understanding a teams capacity and scheduling to it. Though there is some overlap and dependency between these two concepts... here is some clarification.
Philosophically, you want to use story points and velocity to plan your sprint commitment. You want to use hours and capacity to measure how you track towards that commitment throughout the sprint. Thus, you are better planning capacity at a realistic level. If for your group that is 6 hours, then plan 6 instead of 8. Teams that do support work in addition to project work typically have a lower capacity. This will vary by team.
In other words, hours shouldn't be used to plan and commit to a sprint. Remember that estimates are faulty and full of human error. The point of story points is to normalize this error out. But, using hours throughout the sprint to track tasks and watch trends is a good way to raise red flags and work with the team. This balance is part of the magic provided by the scrum master and project manager.
This is where the old style PM asks, "what about known vacation and holiday issues?"
Yes, you obviously don't let the team commit to the same amount of story points as the last 3 sprints (your velocity) if you know they are all taking 2 days off for Thanksgiving. But a simple rounding math formula can help you figure that out. Determine the percentage of capacity lost (rounded in days) and remove that percentage from your expected velocity for the upcoming sprint. That simple approach will probably be 85% accurate or more. Any more time spent figuring it out will not improve your numbers enough to be worth the investment.
Update (11/25): Mike Cohn just posted today along these same lines.
I don't get why people are concerned with individual team member "Capacity Hours" during a sprint. Don't get me wrong. I do understand the need to know if someone will be working with the team full time, part time, or not at all for a given sprint but that's it.
ReplyDeleteOnce you have established a team velocity (average velocity for the last 3 sprints) then you can calculate your teams capacity (i.e sprint budget) for the upcoming sprints taking into consideration things like vacations, holidays, etc. Just as you stated by doing "simple rounding math formula".
Once the sprint has started teams should pay attention to working things in priority order and monitoring their sprint burndown on a daily basis (stand-up meeting).
The sprint burndown will give you all you need to know to start making early decisions if you need to add items or remove items from the sprint. Why try to micro manage down to each individual on the team?
Mike-
ReplyDeleteI totally agree with you in reference to a mature agile team.
But, if your team has specialized resources on it, I could understand why you would want to project that person's work based on their hours remaining since they are the only one who can do that specific work. I sometimes see this happening for a QA or UX role on a scrum team.