Short answer: Before you drag issues into the sprint, know your team’s capacity for this sprint (working days minus holidays and absences), compare planned story points to that number as you plan, and treat nearly-done work as partially complete — not full points again.
Why Scrum sprints get over-committed in Jira
Jira sprint planning makes it easy to add issues to a sprint. It does not, by default, tell you when you have planned more than the team can finish. Without that signal, planning often looks like this:
- The Product Owner proposes a scope list from the product backlog.
- Story points are added or guessed on the fly.
- Someone asks “can we fit one more?” and the answer is usually yes.
- Holidays, part-time members, and support work are remembered after the sprint starts.
The result is predictable: mid-sprint scope cuts, rushed testing, or carry-over that makes the next planning session feel like déjà vu. Realistic planning is not about saying no to work — it is about making trade-offs before the sprint clock starts.
Capacity vs velocity in Jira
Teams new to story points often confuse two numbers:
| Term | What it means | Typical source |
|---|---|---|
| Velocity | Story points the team completed in past sprints | Sprint reports, closed-sprint history |
| Capacity | Story points the team can take on this sprint | Working days × efficiency, adjusted for time off |
Velocity is backward-looking. Capacity is forward-looking. A team that delivered 38 points last sprint might only have capacity for 30 this sprint if two people are on holiday or a release eats three days.
Use recent velocity as a sanity check — not as the sprint commitment by itself. For a deeper look at which number should drive commitment in Jira, see velocity vs. capacity in Jira.
Five steps to a realistic Scrum sprint plan
The Scrum Guide treats sprint planning as a collaborative event — these steps keep that intent while making capacity visible in Jira.
- Start with availability, not the backlog. List who is in the sprint, default working days per person, shared holidays, and known absences. That gives you a capacity number (or range) before anyone opens the backlog.
- Point unestimated work first. Do not pull vague issues into the sprint and hope estimates appear later. Run Scrum Poker or a quick sizing pass on the top backlog items so capacity math uses real numbers.
- Account for carry-over honestly. Issues still in progress from the previous sprint should not always count at 100% of their story points. An issue at 80% done has less remaining work than a fresh 8-pointer. Adjust completion % or remaining load so carry-over does not silently fill the sprint.
- Fill the sprint against capacity, not optimism. As you drag issues from backlog to sprint, watch running total vs. capacity. Stop when you are in range — often 85–95% of capacity — and negotiate what stays out with the Product Owner while everyone sees the same numbers.
- Close the loop after the sprint. Compare planned vs. completed points and note forecast error. Teams that review closed-sprint history get better at the next planning session without guessing.
Common mistakes (and what to do instead)
- Planning to last sprint’s velocity when the team shrank. Recalculate capacity when headcount or availability changes.
- Ignoring meetings and support. Use an efficiency percentage (e.g. 80%) so not every working day is treated as delivery time.
- Treating all story points as equal remaining work. In-progress items need completion modeling — see the capacity guide for status- or time-based options.
- No shared view during planning. If capacity lives in a spreadsheet and scope lives in Jira, the room will disagree. Keep load and capacity visible while issues move.
- Skipping retrospective data. If you never compare forecast to actual, every sprint starts from hope again.
Keep scope and capacity on one screen
ScrumNav supports this workflow in Jira Software Cloud: model sprint capacity from team days and time off, plan scope in one view with a live OK / over / under indicator, estimate with Scrum Poker, and learn from sprint reports after close. It does not replace conversation with the Product Owner — it gives the team one place to have that conversation with the same numbers visible.
New to the app? Start with the getting started guide.
Frequently asked questions
- What is the difference between sprint capacity and velocity?
- Velocity is past delivery (done story points per sprint). Capacity is what the team can take on this sprint given availability. Capacity drives commitment; velocity calibrates it. See velocity vs. capacity in Jira for the full breakdown.
- How much sprint scope should I leave as buffer?
- Many teams plan to 85–95% of calculated capacity so unexpected work, bugs, and meetings do not blow up the sprint. The right buffer depends on how predictable your work is — track forecast error over a few sprints and adjust.
- Should carry-over issues count at full story points?
- Usually not. Work that is nearly done should consume less of the remaining sprint budget than a fresh issue. Model completion percentage or remaining work so carry-over does not double-count effort.
- Does Jira show sprint capacity out of the box?
- Jira tracks story points on issues and sprint scope, but it does not model team availability, holidays, or a live load-vs-capacity bar during planning. Teams often use spreadsheets or apps like ScrumNav to connect scope to capacity inside Jira.
Next article
Once scope and capacity are on the same screen, the next question is which number drives commitment. See velocity vs. capacity in Jira — when past done SP should calibrate your sprint budget and when it misleads.
Plan your next sprint in Jira with capacity and scope in one view.