Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

How to create a sprint in Jira: a practical guide for Scrum teams

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.

Before you create a sprint in Jira

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.

How to create sprint in Jira step-by-step click Create Sprint, drag issues to sprint container.gif

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.

How to create a sprint in Jira

Creating a sprint in Jira starts from the backlog screen.

1. Open the Backlog

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.

Jira sprint planning—dragging issues from backlog into sprint container with bulk select.gif

 

2. Select Create sprint

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.

3. Add work items to the sprint

Now drag issues from the backlog into the new sprint.

Jira sprint planning—dragging issues from backlog into sprint container with bulk select.gif

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?"

4. Give the sprint a name and goal

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.

How to start a sprint in Jira

Once the sprint backlog is ready, you're ready to start sprint.

 How to start a sprint in Jira click Start Sprint, set goal and dates, and the sprint moves from backlog to active.gif

In a company-managed project:

  1. Go to the Backlog tab.

  2. Find the sprint you want to start.

  3. Select the Start sprint button.

  4. Review or update the sprint name.

  5. Set the start and end dates.

  6. Add or confirm the sprint goal.

  7. 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.

Can you start more than one sprint?

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.

What happens after you start a sprint?

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.

How to track sprint progress in Jira

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?

burning room dog.jpg

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.

Workload imbalance

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.

Jira sprint workload planning with Planyway—capacity bars per person showing overallocation in red and available capacity in blue.gif

 

Cross-sprint dependencies

Planyway sprint roadmap with dependency visualization—epics grouped on left, sprints as bars, dependency arrows crossing sprint boundaries.gif

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.

Effort drift

Planyway time tracking—estimated vs actual hours per task showing effort drift on sprint timeline.gifThe 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

How to complete a sprint in Jira

When the sprint's time-boxed period is over, it's time to complete the sprint.

In a company-managed project:

  1. Go to Active sprints.

  2. Select the sprint you want to close.

  3. Select Complete Sprint.

  4. Review any incomplete work.

  5. Choose where those issues should go.

  6. 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.

What to do after completing a 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.

The Bottom Line

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.

FAQ

How do I create a sprint in Jira?

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.

Can I create a sprint without starting it?

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.

Can Jira have multiple active sprints?

Yes. You need to enable parallel sprints to run multiple active sprints at the same time.

What happens to incomplete issues when a sprint ends?

When you complete a sprint, Jira lets you move incomplete issues to the backlog, an existing future sprint, or a new sprint.

What should a sprint include?

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.

How long should one sprint be?

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.

 

0 comments

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events