A sprint in Jira is a time-boxed period when a Scrum team works on a defined set of work items toward a clear sprint goal. For software development and other agile teams, Jira sprints create a predictable rhythm for planning, daily execution, review, and improvement.
Jira, a popular project management tool, makes the mechanics straightforward: you can create a sprint in Jira from the backlog, add work items, set start and end dates, and start the sprint. The harder part is deciding what belongs in the sprint and how much work the team can realistically complete.
This guide covers how to create and manage sprints in Jira, plus a few practical ways to make sprint planning easier.
First, make sure you're working with a Scrum project and have the necessary permissions. Sprints apply to Scrum boards, not Kanban boards. If you're setting up a new Scrum project, make sure the board and backlog are configured for the team's workflow. In a company-managed project, creating and starting sprints generally requires the appropriate sprint-management permissions.
You should also have a reasonably organized product backlog. That doesn't mean every work item needs to be perfectly defined, but the team should have enough context to decide what is ready for the next sprint and what can wait for other sprints.
Before a sprint planning session, the product owner, Scrum Master, and development team should ideally agree on:
which work items are the highest priority;
the expected sprint goal;
estimates, such as story points;
dependencies or other constraints;
the team's realistic capacity;
potential solutions for any known delivery risks.
A common mistake is treating sprint planning as a simple exercise in filling a sprint with as many work items as possible. Capacity, not backlog size, should determine how much work you commit to.
Creating a sprint in Jira starts from the backlog screen.
From your Scrum project, go to the Backlog tab. Jira's Scrum backlog is where you prioritize work items and plan sprints.
Scroll down to the backlog section. On the right, you'll see the Create sprint button.
Select Create sprint. Jira creates a new sprint section above the backlog.
At this point, the sprint is a future sprint. It hasn't started yet, so you can plan it without affecting your current sprint.
Jira also allows you to create multiple sprints in advance. This can be useful when a Scrum team wants to plan things several iterations ahead rather than create each sprint at the last minute.
Now drag issues from the backlog into the new sprint.
You can add different types of work items, including:
Stories
Tasks
Bugs
Other work items used by your Jira project
Jira lets you drag individual issues or move multiple items at once. At the sprint level, the goal isn't simply to fill the sprint with all the work items that look important. Select the work that supports the sprint goal and fits the team's capacity.
This is where story points and historical velocity become useful. Instead of asking, "How much work can we fit?", ask, "How much work does this team usually complete in one sprint?"
Select the sprint's options and choose Edit sprint to add a sprint name or goal before starting it.
The sprint goal is more important than the sprint name. It should explain the outcome you're trying to achieve, rather than simply listing the work items.
For example:
Sprint goal: Enable users to complete checkout with a saved payment method.
This gives the team a decision-making framework when priorities change during the sprint and helps keep team collaboration focused on the same outcome.
Once the sprint backlog is ready, you're ready to start sprint.
In a company-managed project:
Go to the Backlog tab.
Find the sprint you want to start.
Select the Start sprint button.
Review or update the sprint name.
Set the start and end dates.
Add or confirm the sprint goal.
Select Start on the next screen.
Jira then moves you to the Active sprints view, where the team can manage the work.
The dates matter because the sprint begins as a defined time box. Jira also uses sprint data in its reporting, so changing scope or dates after the sprint begins can affect how progress is represented.
The sprint field is also useful when you need to identify which sprint an issue belongs to, particularly when working with reports, filters, or multiple sprints.
Yes, but not by default.
If your organization needs more than one sprint active at the same time, you can enable parallel sprints. This can make sense when multiple teams work from the same backlog but need separate sprint cycles, for example, a development team working alongside a design team.
For most teams, however, one active sprint is simpler and easier to manage.
Once the sprint is active, the team's focus shifts from planning to execution.
The Active sprints view becomes the team's operational workspace. Team members can move work items through the workflow, update statuses, and monitor the team's progress.
This is where practices such as daily scrum or daily standups become useful. The Scrum Master can use these conversations to identify blockers and help the team stay focused on the sprint goal.
One important distinction: sprint progress isn't the same as the number of completed issues. A team can close many small tasks while making little progress toward its actual goal. That's why the sprint goal should remain the main reference point.
Jira provides several reports that help the Scrum team understand what's happening during and after a sprint. These include the burndown chart, Sprint Report, and Velocity Chart. Each answers a fairly specific question: Are we on track? What did we complete? How much work do we usually deliver?
The limitation is that these reports focus on sprint progress and past performance. They don't give you a single view of your sprint health right now, like who is working on what, how work is distributed across projects, or how capacity and dependencies may affect delivery.
That's why we built Planyway for Jira. Planyway for Jira adds a broader sprint planning layer, with Gantt and Table views, resource and workload planning, time tracking, and cross-project visibility. Instead of planning each sprint in isolation, teams can see sprint work alongside the broader project schedule and team capacity.
More importantly, Planyway helps teams spot crucial blind spots before they affect sprint delivery.
You planned the sprint carefully, but two engineers ended up with 45 hours of work while a third has 20. You won't know until day 3 when someone's already behind.
In Planyway's workload view, every team member appears vertically with tasks plotted across days. Blue means capacity available. Red means overloaded. You spot the imbalance before the sprint starts — during planning, when you can still fix it.
See those dependency lines crossing sprint boundaries? In our roadmap view, conflicts like this are visible during planning. Without it, here's what happens: a task in Sprint 15 depends on an API change scheduled for Sprint 16. Jira links the issues but doesn't surface the timing conflict. You discover it on day 3, and now you're replanning mid-sprint.
The sprint scope hasn't changed. The burndown looks fine. But two tasks estimated at 4 hours each have quietly consumed 12. We built time tracking into the timeline for exactly this reason — so you see effort drift when you can still act on it, not two weeks later.
| Jira | Planyway | |
|---|---|---|
| When you find out | At the retrospective | In real time |
| Estimated vs. actual | Not visible at sprint level | Tracked per task, epic, and sprint |
| What you can do | Discuss what went wrong | Rebalance or cut scope while there's still time |
When the sprint's time-boxed period is over, it's time to complete the sprint.
In a company-managed project:
Go to Active sprints.
Select the sprint you want to close.
Select Complete Sprint.
Review any incomplete work.
Choose where those issues should go.
Complete the sprint.
Completed work moves out of the Active sprints view and into closed sprints. If there are incomplete issues, Jira lets you move them to the Backlog, an existing future sprint, or a new sprint.
Don't automatically carry every incomplete issue into the next sprint. First ask why it wasn't completed. Was the estimate wrong? Did priorities change? Was there an external dependency? Did the team take on too much work? That conversation is often more valuable than simply moving the issue to the next sprint.
When the team completes a sprint, it is not the end of the process. Use the Sprint Review to inspect what the team delivered and gather feedback from stakeholders. Then use the Sprint Retrospective to discuss what worked, what didn't, and what the team should change in the next sprint.
Review the sprint's progress, completed and incomplete work, velocity, and any issues that affected delivery. Use those insights to refine your backlog and make the next sprint planning session more realistic.
The goal isn't to make every sprint perfect. It's to create a repeatable cycle where the team plans based on real capacity, tracks progress during the sprint, and uses what it learned to improve the next one.
Jira gives you the structure: backlogs, sprint containers, boards, burndowns, and velocity. That structure is solid, and it works. What it doesn't give you is visibility into the human side — who's overloaded, where the hidden dependencies live, and whether the sprint is quietly consuming more effort than planned.
If you want that extra layer of visibility, Planyway is free to try on the Marketplace.
Go to the Backlog tab in your Scrum project, select Create sprint, add work items, set the sprint details, and select Start sprint when you're ready.
Yes. A newly created sprint is a future sprint. You can plan it in advance and start it later. Jira also supports creating multiple future sprints.
Yes. You need to enable parallel sprints to run multiple active sprints at the same time.
When you complete a sprint, Jira lets you move incomplete issues to the backlog, an existing future sprint, or a new sprint.
A sprint should include a clear sprint goal and a realistic set of work items that the Scrum team can complete within the time-boxed period. The goal should drive the selection of work — not simply the amount of capacity available.
Scrum teams commonly use a consistent sprint length, often one or two weeks. The exact duration matters less than keeping the sprint time-boxed and predictable enough for the team to establish a reliable delivery rhythm.
Mary from Planyway
0 comments