Capacity-First Planning

Big projects fail all the time. The failure may not be apparent—no one gets fired, and no public criticism emerges—but that’s typical of a product failure: Nothing happens.

We like to blame budget for failures. Corporate slashed expenses! We’re in a hiring freeze! Our resources weren’t approved! All companies are cost-constrained, yet budget remains a scapegoat for a lack of execution. While there are many ways to fail at execution, poor planning is the root. No plan is perfect—it may be too rigid, too detailed, or too high-level—but plans have more surface area for failure the larger they get because they’re increasingly divorced from reality.

A good product manager remains ambitious while creating pragmatic plans, and one approach they employ is capacity-first planning.

Capacity-First

The usual plan emerges from a grand vision. Teams imagine the future, outline a waterfall of activities, and then plead for funding to make their PowerPoint slide a reality. Even if the ever-elusive budget comes, it’s never enough, so they haphazardly cut scope, resulting in a convoluted chimera of a product.

Our eyes are bigger than our story points.

Capacity-first planning flips the narrative. Instead of begging for resources, we start with the time and resources available (i.e., half an engineer’s time and a summer intern) and accept them as fixed constraints. We can only modify the scope if we can’t increase time or resources. And that unlocks creative freedom.

A Common Language for Capacity

Capacity is a function of time and resources, where “resources” are the people capable of executing the work, and “time” is their available working hours.

Let’s develop a common language around capacity by defining “story points.” The Scrum Bible decrees that story points are a team’s understanding of complexity and should not reflect time. While complexity-based points can be a useful abstraction, it’s more practical to start with a de-scrummified and easy-to-measure concept: hours.

In an eight-hour workday, an engineer will spend a few hours on meetings and administrative tasks, like email. After factoring in breaks and lunch, one would be hard-pressed to achieve more than five hours of work. With your team, agree on a realistic number of daily working hours and equate that to one story point.

5 hours = 1 working day = 1 story point

To estimate capacity for an iteration, start with the number of workdays and multiply by the people on your team. If you have two and a half full-time engineers and a two-week sprint equals ten working days, you’d have a 25-point capacity.

2.5 people x 10 working days = 25 points

You can easily tweak this to reflect the nuances of your iteration. If an engineer plans a vacation for three days this sprint, only count seven points for her in the capacity.

The Appetite Razor

37signals—the company behind software like Basecamp—operates its projects based on “appetite.” They discuss how much capacity they’re willing to invest into the idea before starting work. An appetite of three weeks creates an incredibly different set of conditions than an idea worth three days.

When you have a firm grasp of capacity, you can have appetite-based conversations with engineering. You can negotiate what scope is critical and efficiently align the goals of a project. Expressing appetite can prevent overbuilding by making incremental progress without constructing unnecessary infrastructure.

Capacity-first planning is not an excuse to cut corners. An expression of appetite should encompass all work needed to accomplish the project—design, development, deployment, documentation, etc. But sometimes, a promising idea is infested with unknowns and is too risky to stomach, so your appetite shrinks. When you have a small appetite, consider a timeboxed spike to do a feasibility analysis or prototype the idea. Whereas the output of a standard project is working code, the output of a spike is information.

Whatever your appetite, if the team doesn’t have the capacity, you’ll need to cut scope. This humanist approach avoids burnout and fosters better morale, as team members needn’t overperform to produce miracles. A respected team is a reliable team and a reliable team consistently executes. Some argue that execution is less important than strategy, but they’re debating a false dichotomy because execution is the strategy. And capacity-first planning creates a culture of execution.