These two terms get used interchangeably all the time, and it causes real confusion — especially when someone from the PMO asks an agile team for a “resource plan” and the team hands back a sprint capacity chart. They’re related, but they answer genuinely different questions at different altitudes.
Let’s untangle them.
The core distinction
Capacity planning answers: How much work can this team realistically take on in the next sprint? It’s short-term, team-owned, and measured in the team’s working unit — hours or story points.
Resource planning answers: Which people, skills, and budget do we allocate across which projects over the coming months? It’s longer-term, manager- or PMO-owned, and measured in headcount, roles, and cost.
One is about this team, next sprint. The other is about which people on which projects, next quarter. Same general idea — matching work to people — but a very different zoom level.
Side by side
| Capacity planning | Resource planning | |
|---|---|---|
| Question it answers | How much can we commit this sprint? | Who works on what, over months? |
| Time horizon | One sprint (1–4 weeks) | Quarters to a year+ |
| Owned by | The team (with the scrum master facilitating) | Managers, PMO, portfolio leads |
| Unit | Hours or story points | Headcount, roles, FTE, budget |
| Scope | One team | Many teams / projects |
| Changes how often | Every sprint | Quarterly-ish |
| Main risk it manages | Over-committing a sprint | Mis-allocating or overloading people across initiatives |
Why agile teams live in capacity planning
If you’re on a Scrum team, capacity planning is your daily bread. Every sprint, you work out how much your team can actually do — and “actually” is the operative word, because it means starting from the team’s theoretical maximum and subtracting reality: public holidays, individual PTO, and the overhead tax of meetings, reviews, and on-call. (The full method is in how to calculate team capacity for a sprint.)
That number is short-lived by design. It’s recalculated every sprint because the inputs change every sprint — different people are out, the calendar’s shaped differently, the on-call rotation moved. Capacity planning is inherently a rolling, near-term exercise, and it belongs to the team because the team is the only group that actually knows its own availability and the true size of the work.
Why resource planning sits above the team
Resource planning operates on a longer fuse. It’s the work of deciding that Product A gets four engineers and Product B gets six, that you need to hire a second designer in Q3, that your one Kubernetes specialist has to be split across three initiatives and that’s going to be a bottleneck.
Those decisions can’t be made sprint by sprint — they involve hiring lead times, budget cycles, and trade-offs across teams that no single team can see. So they live with managers, program leads, or a PMO, and they get revisited quarterly rather than every two weeks.
Crucially, resource planning sets the boundaries that capacity planning operates within. The org decides a team is six people with a certain skill mix (resource planning). The team then decides how much those six people can commit to next sprint (capacity planning). One feeds the other.
Where they get tangled — and where it goes wrong
The confusion usually shows up at the seam between them. A few classic failure modes:
- Treating capacity as a resource plan. A team’s sprint capacity is not a six-month staffing forecast. Extrapolating “we did 187 hours last sprint” into a quarterly commitment ignores that the inputs change constantly.
- Treating a resource plan as capacity. “The plan says you have six engineers, so that’s 480 hours” — no. Six engineers on paper is not 480 assignable hours once you subtract holidays, PTO, and overhead. Resource allocation is the ceiling; capacity is what’s actually left under it.
- Double-counting split people. When resource planning splits a specialist 50/50 across two teams, both teams have to reflect that in their capacity math. They usually don’t, and that person quietly becomes everyone’s bottleneck.
The healthiest setup keeps the two distinct but connected: resource planning sets who’s on the team and roughly how their time splits across initiatives; capacity planning takes those people and works out, honestly, how much they can commit to in the very next sprint.
A quick way to tell which one you’re doing
Ask yourself two questions:
- What’s my time horizon? Days to a few weeks → capacity planning. Months to a year → resource planning.
- Who owns the decision? The team → capacity. A manager, PMO, or portfolio lead → resource.
If you’re a developer or scrum master sweating whether next sprint fits, you’re doing capacity planning. If you’re a director deciding how to staff three products next quarter, that’s resource planning. Different problems, different tools, different people.
Where Ekko fits
Ekko is squarely a capacity planning tool — the short-horizon, team-owned, this-sprint-fits-or-it-doesn’t kind. It lives inside Jira and answers the question “can this team take on this work next sprint?” by showing real available capacity (time off and overhead already subtracted) right next to the plan, recalculating as you assign. It deliberately doesn’t try to be a portfolio resource-management suite; it does the team-level capacity job well and stays out of the months-long staffing decisions that belong a level up. If you want to see how the sprint-level piece works, the capacity docs walk through it.
Knowing which planning you’re actually doing saves a lot of crossed wires. Capacity is the team’s near-term budget. Resourcing is the org’s long-term allocation. Keep them in their lanes and they reinforce each other instead of getting mistaken for one another.
Frequently asked questions
- Is capacity planning the same as resource planning?
- No. Capacity planning is short-term and team-level — how much work a team can commit to in the next sprint, given real availability. Resource planning is longer-term and organizational — how people, skills, and budget are allocated across multiple projects over months or quarters. They operate at different time horizons and are usually owned by different roles.
- Which one do agile teams use?
- Agile teams primarily do capacity planning, sprint by sprint. Resource planning still happens, but above the team — at the program, portfolio, or management level — and it sets the context (team size and composition) that the team then plans capacity within.
- Do you need resource planning if you do agile?
- Most organizations of any size do, even if they're agile at the team level. Someone still decides how many engineers a product gets, when to hire, and how to split specialists across initiatives. Agile doesn't remove those decisions; it just pushes the sprint-level "how much can we do" decision down to the team.
- What time horizon does each cover?
- Capacity planning typically covers one sprint — one to four weeks ahead. Resource planning typically covers quarters to a year, sometimes longer for hiring and budgeting. The shorter the horizon, the more the team owns it; the longer the horizon, the more it sits with management.