Sprint Planning for Small Engineering Teams That Do Everything
Most sprint planning advice assumes a team that only builds features. Small teams do not work like that: the same four to eight engineers build, fix, test, review and keep production running. Planning for that reality is simple once you plan for all of the work, not just the new work.
68 issues of demand against 57 typically completed: about 11 more than the team has recently delivered — before any interrupts.
On a small team, inherited work and one production incident can fill the sprint — plan after them, not before.
What makes small-team planning different
In a large organisation, a feature team can plan mostly feature work because QA, support and operations belong to someone else. In a small team there is nobody else. Every bug, support request, review and deployment competes with the roadmap for the same few people.
That changes what a sprint plan has to account for:
- Existing WIP — work carried in from the last sprint, which the team will pick up first.
- Planned new work — what the plan usually focuses on.
- Work that will arrive after planning — bugs, support, urgent requests.
- Kinds of work — how many different categories the team will juggle at once.
A plan that sizes only the second item is planning perhaps 60% of the sprint.
Why standard planning fails small teams
The typical failure is not overambition about features. It is a plan built from new work only, compared with a velocity number that already included interrupts and carryover. The sprint starts with the same amount of new work as last time, plus last sprint’s unfinished work, plus whatever arrives on Tuesday — and carries over again.
Two sprints of that and the team is carrying the same issues forward every time. See WIP debt. Six sprints of it and stakeholders stop trusting any commitment the team makes.
A small team’s sprint is not a feature budget. It is everything the team will handle — and most of it was not in the plan.
The planning arithmetic
Demand = carried-in work + new commitment = 24 + 44 = 68 issues, against a median of 57 completed
Use the team’s own history, in the same unit (points or issues), over the last six or so closed sprints.
Median throughput = median completed work per sprint
Expected interrupts = median added-work load × median throughput
Room for planned work = median throughput − expected interrupts
Room for new work = room for planned work − carryover in- Find median throughput — completed work per sprint. Use the median, not the average; one unusual sprint should not set the plan.
- Find the median interrupt load — the share of work handled that arrived after planning. See engineering interrupt load.
- Subtract expected interrupts from median throughput. What is left is room for planned work.
- Subtract carryover in. What is left is room for new work.
- Check the work mix of the plan. If it asks each engineer to touch several kinds of work, expect less to finish.
A worked example
| Item | Points |
|---|---|
| Median throughput (last 6 sprints) | 48 |
| Median added-work load | 20% → about 10 points |
| Room for planned work | 38 |
| Expected carryover in | 14 |
| Room for new work | 24 |
If the draft plan has 40 points of new work, it is 16 points — two-thirds — above what the team’s history supports, before anything goes wrong.
How to read the result
- Planned roadmap work 48%
- Added mid-sprint 14%
- Production bugs 22%
- Support & operations 16%
Only 48% of the sprint went to the plan the roadmap assumed.
A team can look slow on the roadmap while half its sprint goes to bugs, support and unplanned work.
- Room for new work near zero means the team is spending the sprint finishing the last one. That is a WIP problem, not a planning-new-work problem.
- Large expected interrupts mean feature commitments must shrink or intake must change. Both are leadership decisions.
- A plan inside the numbers that still carries over points at testing or review queues, or at fragmentation. See sprint context switching.
The arithmetic is deliberately conservative. Teams that plan this way and finish early pull in more work — which is a better problem than carrying over.
Apply this to your team’s delivery
Create a free account, set up your organization and project, then import a Jira CSV. Start with the available evidence; add sprint dates and history for stronger analysis.
Common mistakes
- Planning new work against total velocity. Velocity already includes carryover and interrupts; subtract them.
- Leaving carryover out of the plan because it “was already planned”.
- Assuming this sprint will be quiet. Plan to the median interrupt load, not the best sprint.
- Assigning every kind of work to every engineer. Rotating support or batching operational work is cheap and effective.
- Using per-person numbers to compare engineers. In small teams, differences in mix reflect who holds which responsibilities.
A planning checklist for small teams
- Review every issue that has carried over twice or more: finish, split or return it.
- Size carryover in first; it goes at the top of the sprint.
- Reserve room for interrupts equal to the team’s median added-work load.
- Plan new work into what remains.
- Decide who is on interrupt duty this sprint.
- Check the plan’s work mix: how many kinds of work will each engineer touch?
- After the sprint, compare effective demand with throughput and adjust.
Questions for the planning meeting
- Are we accounting for existing WIP before adding new feature commitments?
- How much work will arrive after planning, and who absorbs it?
- What leaves the sprint when something urgent arrives?
Example
A five-person startup team kept committing about 45 points of new work against a median throughput of 50 and carried over every sprint. The data showed a median of 15 points carrying in and a 22% added-work load. Room for new work: 50 − 11 − 15 = 24 points.
The team planned 25 points of new work for the next sprint, rotated support duty and reviewed four stale issues at planning. It finished the sprint with 3 points carried over — the first time in two months under 10 — and pulled in two small stories in the last days.
Related metrics and how the Workload & Carryover report helps
See it on your own data in the Workload & carryover report.
Related: why work carries over, engineering capacity planning, sprint capacity and the Capacity & Commitment report for next-sprint planning.
The Workload & Carryover report gives a small team every number in this method from a Jira export: effective demand against median throughput, added and interrupt load, work mix, carryover age and context load. An optional small-team mode shows each engineer’s work mix as shares, never rankings, and stays in your browser.
Frequently asked questions
- How should a small engineering team plan sprints?
- Plan total demand, not only new work: start from median throughput, subtract expected interrupts and carried-in work, and plan new work into what remains.
- How much capacity should a small team reserve for bugs and support?
- Reserve roughly the team’s own median added-work load — commonly 10–25% for teams that own production. Measure it from the last six sprints rather than guessing.
Related guides
Why work carries over
The six recurring reasons work carries over between sprints — overcommitment, interruptions, WIP accumulation, testing and review queues, fragmentation — and how to tell them apart with Jira data.
Interrupt load
How to measure engineering interrupt load from Jira — work added after sprint start as a share of all work handled — why not every addition is an interruption, and how to plan around it.
WIP debt
What WIP debt is, how to measure recurring carryover and carryover age from the Jira Sprint field, why issues that carry three or four times need a decision, and how to pay the debt down.
Engineering capacity planning
A practical guide to engineering team capacity planning: capacity vs velocity and throughput, carryover and existing WIP, planned vs unplanned work, median throughput, and the mistakes that make sprints overcommit.