Sprint Planning With Part-Time and Shared People
Most sprint planning advice assumes five people who work full-time on one thing. Real teams have someone at three days a week, someone split across two projects, a tech lead who is half in meetings, and a contractor who leaves in a month. This is how to plan sprints for that team — and why the tools make it harder than it needs to be.
The assumption underneath the tools
It is worth being precise about what Jira does here, because the behaviour is reasonable and the result is misleading.
In a Jira plan, capacity belongs to a team and is set per iteration. Jira then distributes it among the team's members using a simple rule that Atlassian states directly: the team's capacity per iteration, divided by the number of people in the team, is the capacity of one team member. A five-person team with 20 story points of capacity gives every person four points.
That is a sensible default and it is wrong for almost every real team. Your three-day-a-week developer gets the same four points as the person who is there five days. Your tech lead, who spends half her week in design reviews and interviews, gets four points. The person shared with another project gets four points there too, so between the two plans they have been given eight points of work for one person's week — and neither plan can see the other.
Premium and Enterprise also offer individual capacity planning, where you allocate work to named people in hours, days or percentages. It comes with a limitation Atlassian states plainly: capacity plans use a fixed 40-hour work week, and your own time-tracking or working-day settings are not reflected in them. There is no automatic handling of leave or holidays either — you can enter leave as a tracked item, but nothing subtracts it for you.
So even the per-person view starts from "everyone works forty hours" and requires you to remember, every sprint, for every person, to record everything that makes that untrue.
Four kinds of not-full-time, and what each costs
Contracted part-time
The easy one: three days a week is 60% of a full week, every sprint, predictably. It is easy because it is stable — and it is still wrong in most plans, because nothing carries the 60% into the capacity number.
Split across projects
Harder, because the split is rarely what it says on paper. "Half on each" usually means fully on whichever one is on fire. Two effects follow. Their real contribution to your sprint is lower than half, because switching between two contexts costs time that appears in neither plan. And their availability is not steady — it collapses whenever the other project has a deadline, which is exactly when you will not hear about it.
Part of the week is not project work
The tech lead in design reviews, the person on the support rota, interviews, on-call, mentoring. None of it is estimated work, so none of it appears anywhere in a capacity number, and all of it consumes the week. This is usually the largest and most invisible reduction on a team.
Ramping up or winding down
A new joiner is not at full contribution for their first few sprints, and the person who onboards them is not either. A leaver's last sprints are handover. Both are temporary and both are real, and a capacity number taken from the team's history accounts for neither.
Working out the real number
Per person, for the coming sprint, in whatever unit you estimate in:
- Start from their contracted time for the sprint — not the team average, not forty hours.
- Subtract booked leave and any company holiday falling inside the sprint.
- Subtract the share of their week that is not project work — support, meetings, interviews, on-call.
- Multiply by the fraction genuinely allocated to this project, if they are shared.
- Apply the team's delivery record: if the team historically finishes about 80% of what it commits to, plan to 80%, not 100%.
Total those, and that is the sprint's capacity. It will be noticeably lower than the number you have been using, and the gap between the two is the amount by which your sprints have been quietly overcommitted.
The particular problem of shared people
Shared people deserve their own treatment, because they cause a failure the others do not: two plans can each look healthy while the person in both is committed twice over.
Each project's board sees its own half. Neither sees the total. The person knows, and usually says nothing until something slips, because from where they sit both requests are reasonable.
Three things help, in order of how much they help.
Write the split down as a number. "Sam is 50% on this project" is a fact both sides can plan against. "Sam helps out with us" is not.
Look at people across projects, not projects one at a time. The only view that catches double-booking is one that lists a person and everything they are committed to. If nothing in your setup produces that view, double-booking will be discovered rather than prevented.
Prefer whole days to split days. Two days on one project and three on another beats being half on both every day. Context switching is the tax nobody estimates, and splitting by day is the cheapest way to reduce it.
A worked example
A team of five, two-week sprint, estimating in story points, historical delivered velocity 30.
| Person | Situation | Share of a full sprint |
|---|---|---|
| Alex | Full-time, no leave | 100% |
| Maya | Tech lead, about half her week in reviews and interviews | 50% |
| Sam | Three days a week | 60% |
| Dana | Split 50/50 with another project, and away for two days | 40% |
| Chris | Joined three weeks ago, still ramping | 60% |
That totals 3.1 full-time people, not 5. The velocity of 30 was measured on a team that averaged nearer four and a half, so this sprint's realistic capacity is roughly 30 × (3.1 ÷ 4.5), which is about 21 points.
Jira, left alone, would divide the team capacity of 30 into six points each and show a 30-point sprint as fitting comfortably. It is at about 143%.
And Dana, given six points here and six on the other project, has been handed twelve points of work for four days of availability.
Four practices that help
Record availability as a number, per person, per sprint. Somewhere both the team and whoever is planning can see it. The format matters far less than it existing.
Plan to the lowest realistic figure, not the average one. A team of mixed availability has more variance than a full-time one, so the safe commitment is nearer the bottom of the range.
Do not spread work evenly. Even distribution is what the tools do by default and it is exactly wrong here. Load follows availability.
Re-check when someone's split changes. A shared person going from half-time to fully committed elsewhere changes your capacity immediately, and it is the sort of change that gets communicated late, if at all.
Planning for the team you actually have
Project Commander is a Jira app built for this case rather than the five-identical-people one. It works on every Jira Cloud edition, including Free and Standard.
Capacity per person, not a team total divided by heads
Each person has their own weekly hours or points. Nobody is assumed to be like anybody else, and nobody is assumed to work forty hours.
Leave and holidays subtracted automatically
Entered once, per person, and taken out of their capacity from then on — rather than remembered by hand at every sprint planning.
Shared people visible across every project at once
The view that catches double-booking: each person, and how their time is divided across all the projects that have a claim on it.
And the sprint judged on that basis
Plan for the team you actually have
Project Commander gives every person their own capacity, subtracts their leave and holidays automatically, and shows anyone committed on more than one project at once. Free on the Atlassian Marketplace, or try the demo first.