TODO: this must all be redone.
- Reallocating teams (not people on a team)
- Remember Dunbar’s number
There’s always a need to plan out future work and ensure your existing teams can handle the anticipated work. Capacity planning is mapping out your planned work, comparing it to the team’s historical rate of work, and adjusting your plans to meet reality.
- The company is always running late with new products, can’t deliver features or bug fixes on time, and has systemic quality issues
- You suffer cold sweats on sleepless nights wondering if your teams have complete all the planned work
- Your teams waste countless days, weeks, and months trying to break down work and estimate precisely enough to eliminate all risk
- Your teams have plenty of talented team members, but they’re on the wrong teams and working on the wrong products
Sane capacity planning teaches you to live within your means. It helps remove the guesswork from your planning and brings data to the traditionaly fuzzy black art known as estimation. When we can effectively forecast your team’s capabilities, we can ensure your planning has boundaries in which it can safely expand.
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
- Collect data for the last 3 to 6 months for your teams
- Calculate the average number of stories per feature
- Calculate the average number of days per story
- Examine the next quarter’s backlog
- Calculate how long it will take the existing team to complete the work
- Track the team’s work iteration by iteration
- Measure the predicted performance versus the actual performance. How accurate was the prediction?
- How long did each story take during the quarter?
- How many stories per feature did the team’s break down during iteration planning
- How different was this quarter from the past quarters?
What Does it Look like?
When look at a team’s traditional capacity, as measured by iteration velocity, we can understand how much work the team has actually/really completed. We’ll use that to predict how much work the teams can complete in the future.
If the team is completing 0.8 features per month, don’t plan on the team completing 1.5 in the upcoming year. Instead, reduce your planning to this level. Assume capacity is a constant and reduce work to live within your team’s capacity. Capacity can be increased, but slowly and over time. Never plan for the increase, but instead focus on pruning work to live within the historical capacity limits.
Always show your work! Provide the numbers and calculations in a clear and readable way. Real data is the enemy of wishful thinking.
- You see the numbers and plan for pushing the teams hard to get 25% more work out of them
- You have no idea what the last quarter looked like
Grow the team to increase their productivity: invest in training, personal development time for developers, corporate-sponsored book clubs and brown-bag lunches to help introduce new skills and technologies.
How To Fail Spectacularly
- Do the math. See the numbers. Look at the projections. Then say “But I believe in the team”. Your belief isn’t the issue. It’s just data.
- Managers who plan by picking dates based on market forces, and then push teams hard to meet these fantastic, and completely arbitrary, deadlines.
- Team members start trying to stick work into existing features so they can “get more done”
- You see the numbers and focus exclusively on increasing capacity instead of reducing the forecasted work
- Encouraging teams to commit to 150% of their average velocity… if the team can hit amazing numbers iteration after iteration, they’re gaming the system to meet unreasonable expectations.