As Jean’s colleague does, I set our capacity at 50% for all new teams and new team members. In every case to date, teams have had this percentage or slightly greater and increasing thereafter by upwards of 10% each iteration thereafter and stabilizing around 70%. That left over 30% is usually absorbed with meetings and understanding requirements of the project work.

New teams have usually hit their maximum potential for Sprint 4 for us when done in 2-week iteration periods and we usually switch to velocity based planning for Sprint 4.

I have actually created a spreadsheet which calculates all this for me and all new projects formed having new teams are estimated using this method.

It is rare that we get the same team on different projects, so capacity has been a real winner for us.

Thanks for the post. I remember a colleague in a previous company who was a real extreme programming pro. With regard to this capacity wrangle with new teams, he would not allow anyone on the team to commit over 4 hours per working day until they proved to him that they actually had more ideal hours per day than 4. They would then move to 5 hours per working day. Again, team members were not allowed to commit beyond 5 hours a day until they proved that they could meet commitments and actually be under-utilized.

While I have never been able to convince a new team to do this, I really like the idea of starting with a very low number in order to drive the point home. My usual tactic is to try to hold the team’s estimate of capacity to around 80% and then work backward from there based on whether they didn’t meet their commitment. Or, they met the commitment but with something of a death march regimen in order to do so.

Has anyone else been able to convince a team (and management) to work your way up from a very low number for capacity?

Jean

In looking back over the post, I never made it explicit – but the “Working Hours Available per Day” in the capacity calculation might be 8 or it might be 6. I let the team members decide this themselves.

I tend to apply the 70% rule-of-thumb after the capacity is calculated.

In other words…

6 hrs. per day * 8 working days = 48 hours of capacity.

After that capacity calculation, I will be most comfortable with 48 * 70% as a commitment. In this case 33 or 34 hours.

And I do recommend that each team member only works on one task at a time and works each item through to completion (rather than parallel work on multiple tasks).

Good post. We use a capacity of 6 hours per day although the working day is set to 7.5. That is, a capacity of 80%. We found that it works better than when we set the capacity to the “legal” 7.5 hours. It is nice to read some mathematical evidence of why this works. It is now easier to justify what we do.

Thanks
Marta

Also, traditional recommended estimation practice has targeted ~75% as expected top capacity (i.e., 6 hours/day). So that fits closely with your recommendation.

And one thing that wasn’t explicit in your post, but I’m reasonably sure you meant it, was that, no matter how many tasks make up the 70%, there is a limit to how many can be expected to be done in parallel due to task switching loss. So that’s another factor for capacity considerations. (And another of the things DeMarco discusses.)