Resource planning for engineering workstreams matches proposed work with the actual availability of the people and capabilities it requires. Start with existing commitments, operational responsibilities, planned absence, and scarce specialties. Then compare feasible sequences. Counting headcount or assigning the same engineer to several full-time plans does not create capacity.
The purpose is to make tradeoffs visible before teams promise delivery dates. A useful capacity view is role-specific, time-bounded, and honest about uncertainty. It supports discussion with the people doing the work; it should not become a surveillance score or a minute-by-minute forecast of individual productivity.
The Kanban Guide describes controlling work in progress and starting work when capacity is available. That principle is relevant here, but the planning table below is an original practical aid, not a prescribed Kanban resource-management method.
Separate people, skills, effort, and elapsed time
A team may have six engineers while only one can review a particular infrastructure change. Total headcount conceals that bottleneck. List the capabilities each workstream requires: implementation, domain decisions, security review, data work, testing, and operational acceptance.
Effort is the contribution required. Elapsed time includes waiting and sequence. Two person-weeks of work do not necessarily fit into one calendar week with two available people, especially when tasks depend on one another or need a scarce reviewer.
Availability also differs from assignable project time. On-call work, incident response, maintenance, hiring, mentoring, and existing commitments consume capacity. Make those responsibilities visible without pretending they can all be predicted precisely. Use historical patterns where appropriate, and label any reserve as a planning assumption.
Do not compare story points across teams as if they were a common resource currency. For cross-workstream planning, concrete role availability and dependency conditions are usually easier to explain than a combined points total.
Build a capacity view for one planning horizon
Start with a short horizon where participants understand current commitments. Four weeks might be useful for one organization, while another needs a different window. The horizon is a planning choice, not a universal engineering standard.
| Role or capability | Gross availability | Existing commitments | Operational allowance | Proposed new allocation |
|---|---|---|---|---|
| Backend implementation | Available contribution in the window | Work already accepted | Expected support and maintenance | Workstream-specific contribution |
| Platform review | Named review capacity | Existing reviews and migrations | Incident and on-call responsibility | Decision or review slots |
| Data validation | Available analytical contribution | Reporting and quality duties | Unplanned data investigation | Reconciliation work |
| Product decisions | Decision-maker availability | Existing initiatives | Operational decisions | Required acceptance choices |
Use one consistent unit for a given comparison, such as days of contribution within the window. Do not mix a person’s calendar days with another person’s focused implementation days without explanation.
A shared board can collect constraints and competing requests during the planning discussion. Keep the authoritative allocations and schedules in your organization’s resource or project systems. Nextretro should not be presented as automatically forecasting staffing or resolving dependencies.
Worked example: three streams share one reviewer
Consider a hypothetical engineering group planning four weeks of work. It wants to run a reporting project, an authentication improvement, and an infrastructure migration. Each stream’s individual plan assumes the same platform specialist will be available when needed.
For illustration, the specialist has 20 working days in the window. Five are already committed to operational responsibilities, three to planned absence, and four to accepted migration work. That leaves eight days before new requests. The reporting project asks for four days, and authentication asks for six. Together they require ten days, even before uncertainty.
These are invented planning figures, not productivity benchmarks. Their value is that they expose a contradiction: the separate workstream plans collectively assume more specialist contribution than is available.
The group considers sequencing authentication before reporting, reducing reporting’s initial scope, pairing another engineer to build capability, or changing the target dates. It does not solve the mismatch by assigning percentages that add to more than the person can provide.
Choose an explicit tradeoff
When demand exceeds capacity, name what will change. Options include reducing scope, delaying a start, finishing existing work first, changing sequence, developing another person’s capability, or adding genuinely available support. Each option has consequences.
Adding people may require onboarding and supervision from the same constrained specialist. Record that cost rather than treating new headcount as immediately interchangeable capacity. Similarly, parallelizing work can increase coordination or integration effort. Check the actual dependency before promising a shorter duration.
Use a decision record with the constrained capability, affected streams, options considered, chosen sequence, remaining uncertainty, and next review point. Identify who can approve changes to scope or commitments. A workshop can reveal the conflict, but it cannot manufacture authority to resolve it.
If work has already started in too many places, prioritize completing or safely stopping items before adding more. Inspect unfinished work and blocked dependencies. A high allocation rate is not evidence that useful outcomes are flowing.
Revisit assumptions as work unfolds
Review the capacity view when a major incident, absence, scope change, or dependency alters the plan. Keep updates proportional. The goal is to notice material changes, not to make engineers report every interruption.
Compare planned contribution with the reasons work actually waited. Did the scarce reviewer become the bottleneck? Did an acceptance decision arrive late? Did a supposedly independent task require unexpected integration? These observations help improve the next planning conversation.
An agile retrospective can examine one finished or delayed workstream without turning capacity planning into individual blame. Use a format from retrospective ideas to separate facts, assumptions, and the next improvement.
Do not interpret low recorded utilization as waste without context. Slack capacity can support urgent work, learning, and recovery. The relevant question is whether the arrangement supports reliable delivery and sustainable work, not whether every calendar cell is filled.
Frequently asked questions
Should engineering capacity be planned at 100 percent?
Avoid assuming all available time can be committed to new project work. Existing responsibilities, interruptions, and uncertainty need explicit treatment. The appropriate allowance depends on the team’s actual work and should be reviewed rather than copied from a universal percentage.
Can one engineer work across several streams?
Yes, but account for the total contribution, sequencing, and coordination burden. Multiple allocations must fit within actual availability. Where a specialist becomes a repeated dependency, consider sequencing work or developing additional capability.
How is capacity planning different from scheduling?
Capacity planning checks whether the required capabilities are available within a horizon. Scheduling coordinates specific activities, dependencies, and dates. A schedule built on unavailable capacity is not made credible by adding more detail.