Capacity planning is an important, but often undervalued aspect of any type of management. My take on it in the context of software development is something I call Horizon Planning.
These are the basics of it:
- Maintain a living Horizon Plan, at all times. It lists all the available coding capacity to the end of the horizon, all the remaining requirement for coding, and roughly balances them.
- Continuously update the plan with the estimated remaining coding capacity and estimated remaining coding requirement.
- When the horizon plan gets out of balance, involve all the stakeholders early and adjust the plan.
- Measure ideal hours spent on feature work to close the loop on improving estimation accuracy for capacity and requirement.
All of this is easier said than done. It requires careful definitions, an appreciation for the schedule risks inherent in software development, and careful and consistent management attention.
I’ve implemented this methodology in six different companies I’ve had the honour of managing, with anywhere from 12 to 200 coders. It has always delivered on its promise and resulted in great success for the company. Colleagues who have taken the methodology and adapted it for their own use report equal success. In every job interview for the top spot, I speak about the methodology and the benefits it brings. I say what it will fix, and I can be very concrete about how I will fix it. I always get hired as a result, and I usually deliver beyond expectations.
I consider Horizon Planning to the be the linchpin of Modern Software Management. It’s the key to keeping promises, delivering quality software, good architecture, good productivity, and attracting and retaining great talent.
Sanity goes a long way.
Benefits of Horizon Planning
- Having at least a fighting chance of delivering a certain feature set within a certain time.
- Keeping the plan “real” in the face of evolving uncertainties.
- Granting full transparency to all stakeholders in easy-to-understand terms.
- Involving stakeholders in business decisions, while separating those cleanly from technical decisions.
- Creating consensus and “elbow room” to work on tech debt reduction and infrastructure improvement.
- Involving everybody in managing the uncertainty of software development in a way that they feel they have a voice.
- Not overcommitting to customers, prospects, and senior stakeholders.
- Being able to “show your work”.
- Defending the software org against baseless promises made by others.
- Pivoting quickly to incorporate new work into the plan (by removing other, now less important work).
- Reserving adequate time to build it right the first time (mostly).
- Bringing sanity to software development.
Steps Involved in Horizon Planning
- Make a clear definition of the “Effective Coder Day” (ECD).
- Ideal hours divided by 8. 1 ECD = 8 ideal (uninterrupted) coding hours.
- Only include individual contributor work by coders associated with a “Feature”.
- Features can be user features, architectural improvements, or projects.
- Do not include defect investigate/fix (outside of the development of the Features), meetings, or overhead.
- Do not include non-coders (they will be accounted for separately).
- List the candidate Feature set.
- High level, business meaningful items.
- Rough estimates in ECDs assuming an “average” coder.
- Establish the planning horizon.
- Start date, end date (maybe development cutoff date and stabilization period if applicable)
- Count the workdays between.
- Estimate the available coding power.
- List anybody who will contribute to the coding.
- For each coder, estimate their “work factor” (w), which translates to how many ideal hours per workday they are able to perform individual contributor work on Features.
- Estimate they vacation they intend to take during the horizon.
- Compute the ECDs available from each coder over the horizon.
- Choose the Feature set.
- Choose the mix of Features such that the sum of the estimated Feature ECDs is 75% of the Capacity ECDs.
- Continuously re-estimate and adjust the plan.
- As often as feasible, update the plan to restate remaining capacity and remaining requirement in ECDs.
- As the requirements become more concrete and the software design is better established, the remaining requirement in ECDs will start converging towards reality.
- If the plan gets too far out of balance, gather the stakeholders and adjust the plan.
- Track the estimates.
- Have coders keep track of ideal hours spent on Features.
- Reflect on these measurement to improve feature estimation accuracy over time.
- Reflect on those measurements to improve work factor estimation.
Throughout this website and on the @modsoftman YouTube channel I will go over Horizon Planning in more depth.
You can download a sample spreadsheet to help you to understand and implement Horizon Planning at Horizon Planning Spreadsheet.