Your team finishes about half of every sprint. What's the most likely cause and fix?

Planning on nominal capacity while support, leave, meetings, reviews and unplanned work consume much of the time. Calculate real capacity from data, plan to about 80% of it around a sprint goal, and keep the support person off planned work.

What should a sprint goal look like?

One sentence describing an outcome (e.g. 'customers can pay with saved cards on mobile'), used to prioritise items and make trade-offs during the sprint.

How do you size the unplanned-work buffer?

From recent data: the share of time spent on incidents and urgent work over the last few sprints, adjusted each sprint as the trend changes.

Planning That Holds — The Team Lead Handbook

Scenario

Example team: the checkout team plans two-week sprints at "6 engineers × 10 days = 60 days" of work. Every sprint ends with 40–50% of items unfinished and carried over. Product stops trusting the plan; engineers stop caring about it.

What you see on the team

Planned work never fits; carry-over every sprint.
Support, incidents and meetings "steal" time nobody planned for.
End-of-sprint rushes and skipped tests.
Sprint goals that nobody remembers by the second day.

The common mistake

Planning nominal capacity (people × days) and filling it completely, as if nothing else will happen.

Why it happens

Optimism and pressure: plans are made when everyone is in the room and nothing is on fire. Support duty, leave, meetings, reviews and interruptions are each small, so they're ignored — but together they consume a large share of time. Basecamp's Shape Up takes this seriously with fixed time and variable scope: you decide how much time a problem is worth, then shape the scope to fit.

The playbook

Calculate real capacity for the planning period:

Real sprint capacity for a team of sixTry it yourself

engineers = 6
days = 10
nominal = engineers * days

leave_days = 4                          # holidays and leave this sprint
support_rotation = days                 # one person on support for the whole sprint
meetings_share = 0.15                   # standups, planning, retro, 1:1s, design reviews
review_and_interrupt_share = 0.10       # code reviews, questions, small requests
unplanned_buffer = 0.15                 # incidents and urgent work (from last 3 sprints)

available = nominal - leave_days - support_rotation
focused = available * (1 - meetings_share - review_and_interrupt_share)
plannable = focused * (1 - unplanned_buffer)

print(f"nominal capacity        {nominal:5.1f} days")
print(f"after leave and support {available:5.1f} days")
print(f"after meetings/reviews  {focused:5.1f} days")
print(f"plannable (buffer kept) {plannable:5.1f} days  -> {plannable / nominal:.0%} of nominal")

Output

nominal capacity         60.0 days
after leave and support  46.0 days
after meetings/reviews   34.5 days
plannable (buffer kept)  29.3 days  -> 49% of nominal

In this example only about half of nominal capacity can be planned. Teams that plan 100% will carry over roughly half — which is exactly what the checkout team sees.

Plan to ~80% of real capacity and use the buffer for unplanned work.

Use a sprint goal — one sentence describing the outcome — and prioritise items that serve it.

Measure the plan's accuracy (planned vs done) and adjust the numbers each sprint from data, not hope.

Make support visible: the person on support doesn't take planned items.

What to say

In planning:

"Last three sprints we finished about 55% of what we planned. This time I've calculated real capacity — leave, support, meetings — and it's about 29 days, not 60. Let's pick the goal first and fill to about 24 days. If we finish early, we pull from the top of the backlog."

Trade-offs

Lower commitments can look like less ambition; delivering reliably builds more trust than over-promising.
Buffers get filled with "just one more thing"; protect them for unplanned work.
Capacity maths varies by team; use your own data from the last few sprints.

Signals it's working

Planned vs done rises to a stable 80–90%.
Carry-over shrinks; sprint goals are met most of the time.
Fewer end-of-sprint rushes.
Product uses the plan for its own commitments again.

Key points

Nominal capacity (people × days) overstates what can be planned — often by half.
Subtract leave, support, meetings, reviews and an unplanned buffer from your own data.
Plan to ~80% of real capacity around a single sprint goal.
Track planned vs done and adjust from data.