Sprint planning in Jira is where your team turns a prioritized backlog into a realistic, committed plan for the next sprint. Do it well and the team ships predictably; do it on gut feel and you over-commit, carry work over, and lose trust. This guide walks through how to run sprint planning in Jira step by step, then collects Divim’s deeper guides and the tools that make capacity-aware planning the default.
What is sprint planning in Jira?
Sprint planning is the Scrum event that opens every sprint. The team agrees on a sprint goal, selects backlog items it can realistically finish, and breaks them down enough to start. In Jira, this happens on the Backlog view of a Scrum board: create a sprint, drag prioritized issues into it, estimate with story points, and start the sprint when the plan matches the team’s capacity.
How to do sprint planning in Jira: 6 steps
- Refine the backlog first. Walk into planning with a backlog that’s already prioritized, estimated, and clarified. Backlog refinement in Jira makes planning fast instead of a two-hour debate.
- Create the sprint. On your Scrum board’s Backlog, click Create sprint. You can provision several sprints ahead for release or PI planning.
- Set a clear sprint goal. One sentence describing the outcome the sprint should deliver. The goal keeps scope decisions honest when trade-offs come up mid-sprint.
- Plan against real capacity, not headcount. Subtract holidays, PTO, meetings, and part-time allocation before you commit. This is the step most teams skip — and the reason sprints spill over. See capacity planning in Jira.
- Pull work in until you hit capacity. Drag issues into the sprint, estimate with story points, and stop when committed points match your team’s proven velocity and available capacity — not when the backlog looks tidy.
- Start the sprint. Click Start sprint, set the duration, and confirm the goal. From here the board tracks progress against the plan.
What a good sprint planning meeting covers
An effective sprint planning meeting answers two questions: what can we deliver this sprint, and how will we deliver it. Keep it timeboxed (roughly two hours per week of sprint length), review the sprint goal and team capacity up front, walk the prioritized backlog, confirm estimates, and end with a committed sprint backlog everyone understands. Anything that turns into a deep design debate should move to refinement, not planning.
Sprint planning vs. capacity planning
Velocity tells you how fast a team usually goes; capacity tells you how far it can go this sprint. Strong teams plan both together so commitments reflect who is actually available. Divim’s guide to aligning sprint planning with capacity planning shows how to make that repeatable in Jira.
AI-assisted sprint planning in Jira: what it helps with (and what it doesn’t)
Jira’s AI features — and a growing set of marketplace tools — increasingly promise to draft a sprint for you: suggesting which issues to pull, flagging over-commitment, and summarising capacity. Used well, AI sprint planning speeds up the mechanical parts. The pros: it can surface a starting set of issues from a refined backlog, estimate against historical velocity, and catch an obvious capacity overrun before you start the sprint. The cons: AI doesn’t know your team’s context — a teammate ramping back from leave, a fragile dependency, or a goal that matters more than raw throughput — so a blindly accepted AI plan over-commits just as easily as a human one. Treat AI as a fast first draft, then apply judgment on the sprint goal, real capacity, and dependencies before you commit. See AI vs. manual planning for agile teams.
Common sprint planning mistakes (and how to avoid them)
- Planning by headcount instead of capacity. Five developers rarely means five full sprints of throughput once leave, meetings, and support duties are removed.
- No sprint goal. Without a goal, the sprint becomes a to-do list and the team can’t make smart trade-offs mid-sprint.
- Skipping refinement. Unrefined items turn planning into estimation chaos. Refine ahead of time.
- Over-committing to look productive. Carryover erodes trust faster than a slightly smaller, fully-delivered commitment.
Start here
- Aligning Sprint Planning with Capacity Planning: A Practical Guide
- Velocity vs. Capacity: What Agile Teams Get Wrong
- How to Calculate Team Capacity When Half Your Team Is Part-Time
- Planning Sprints Around Holidays, PTO, and Training Days
- Streamline Agile Planning with Divim’s Sprint and Capacity Planning
Get the app
Sprint Planning with Capacity Planning for Jira puts past velocity, planned capacity, and allocation on one screen — adjust capacity per sprint (days off included) and stop over-committing before the sprint starts.
Try Sprint Planning & Capacity free on the Atlassian Marketplace →
Frequently asked questions
How do I create a sprint in Jira? On your Scrum board’s Backlog view, click Create sprint, drag prioritized issues into it, then click Start sprint and set the duration and goal.
How long should a sprint planning meeting be? A common guideline is up to two hours for each week of sprint length — so about four hours for a two-week sprint, often less once refinement is solid.
What is the difference between sprint planning and release planning? Sprint planning commits one team to a single iteration; release planning in Jira decides which sprints roll up into a shippable release and when it ships.
Can AI help with sprint planning in Jira? Yes — AI can draft a sprint from a refined backlog, estimate against past velocity, and flag over-commitment, which speeds planning up. It works best as a first pass: you still set the sprint goal and sanity-check capacity, dependencies, and who’s actually available before starting the sprint.