How Much Work Should a Team Take Into a Sprint?

Start with capacity

Before deciding how much work to take into a sprint, estimate the team's available capacity.

• Team members who are available
• Working days
• Leave
• Holidays
• Meetings
• Other planned activities
• Known support or operational work

A five-person team might have 50 person-days in a two-week sprint. After leave, meetings and support work, the usable capacity may be much lower.

Add a simple decision framework

Use recent velocity carefully

Historical velocity is useful but it should not become a target. It tells you what the team has recently delivered under certain conditions.

• Sprint 128 points
• Sprint 231 points
• Sprint 329 points
• Sprint 430 points
• Sprint 527 points

If the next sprint includes leave, support work or resolved dependencies, the team may need to plan less than it did in a previous sprint.

Do not copy the previous sprint by default

A common mistake is to repeat the last sprint's workload because it worked before.

The next sprint may have different conditions. Consider:

• Two people are on leave.
• A major dependency is unresolved.
• Several stories are technically complex.
• Production support is expected.
• The team is working on unfamiliar technology.

Check the complexity of the work

The same number of points can feel very different depending on the work involved.

• Significant technical uncertainty
• External dependencies
• New technology
• Multiple integrations
• Unclear requirements

A sprint with several uncertain or highly dependent items is often harder to deliver than the raw point total suggests.

Include dependencies and uncertainty

Dependencies can reduce the team's ability to complete the sprint plan even when capacity looks healthy.

• Unexpected defects
• Production issues
• Technical investigations
• Requirement clarification
• Dependency delays
• Unplanned support work

The team should leave enough room for normal uncertainty instead of filling every available slot.

A practical way to decide

1. 1

   Calculate available capacity

   Understand the team's actual availability for the sprint.

2. 2

   Review recent delivery

   Look at recent velocity or completed work to understand the team's historical delivery pattern.

3. 3

   Check the upcoming work

   Look at complexity, dependencies, uncertainty, and priority.

4. 4

   Build a realistic plan

   Select the highest-priority work that the team believes it can reasonably complete.

5. 5

   Avoid filling every available slot

   Leave enough room to deal with normal uncertainty and unexpected work.

Example: a realistic plan

A team may have a strong sprint capacity but still decide to take on a smaller backlog because:

• One developer is away for three days.
• A QA member is away for two days.
• The team has additional support responsibilities.
• One planned feature has significant technical uncertainty.

In this case, the best sprint plan is not the one that fits the most work on paper. It is the one the team can carry through with a realistic chance of success.