Short answer: In Jira, create a new sprint from the backlog view: click 'Create sprint' at the top of the backlog list, then drag stories into the empty sprint container, then click 'Start sprint' and set the duration and dates. Three settings most teams get wrong: sprint length (2 weeks is the right default), which issue types accept points (stories only), and the velocity calculation method (rolling-3 if the option exists).
To make a new sprint in Jira begins by opening the backlog view of your Scrum board. You will then click on Create sprint at the top of the backlog list. You can now then drag stories from the backlog into the empty sprint container. Finally, you will click Start sprint and set the duration and dates. That concludes the entire procedure. Most teams set wrong configuration settings for these three areas where friction occurs, and they live with them for years.
Why it matters: Jira is king on enterprise software, and its sprint mechanics is how most teams participate in the agile process. The defaults are complicated, the mechanics aren’t. Make sure you configure Jira's sprints properly. Teams that do so end up shipping in a more predictable manner. However, teams that take the default settings will face issues due to the default settings.
This guide walks you through the click-by-click for modern Jira (the current cloud version as of 2026), the three most important settings that are way more important than the click sequence, the most common config mistakes, plus when not to use Jira sprints at all. Target Roles include Scrum Master, Anchor, and Engineering Lead ones, who are setting up or rethinking Jira workflows.
How to create a new sprint in Jira
The process, methodically explained.
- Open your Scrum board in Jira. (Sprints don't exist in Kanban boards — if you have a kanban board, you'll need to switch board types or use a different project.)
- Click Backlog in the left sidebar.
- At the top of the backlog list, click Create sprint. An empty sprint container appears above the backlog.
- Drag stories from the backlog into the sprint container, or right-click each story and select "Move to sprint".
- Click Start sprint in the upper right.
- In the dialog:
- Sprint name — auto-generated or custom (e.g., "Sprint 14 — checkout").
- Duration — 1, 2, 3, or 4 weeks; or custom.
- Start date and End date — usually defaults to today and today + duration.
- Sprint goal — optional one-line theme.
- Click Start.
Different versions of Jira.
- Jira Cloud (current default) — the flow above.
- Jira Data Center / Server — same flow, slightly different UI; "Create sprint" is in the same backlog header.
- Jira Software Premium — has additional sprint features (cross-team sprints, advanced reports); the create flow is the same.
The mechanics seldom falter. It's the configuration that defines what the sprint actually means as it runs that fails.
The three settings most teams get wrong
1. Sprint length.
The most used defaults are 2 weeks. Some teams pick 1 week, some adjust to 3. Others settle on 4. The worst default is “longer because it gives the team more time.”
Active Defaults
- 2 weeks for most software product teams. Long enough to finish meaningful work, short enough to absorb planning overhead.
- 1 week for teams with high reactive workload (support-heavy, on-call rotations) or experimental products.
- 3–4 weeks only when the work has natural longer cycles (research-heavy, deeply technical migrations) and stakeholders accept slower cadence.
The truth is that most teams that do 3 week or 4 week sprints now got there because two weeks isn’t long enough. Two weeks is definitely not enough time for big stories, this is the honest answer. The solution lies in dividing stories into smaller ones instead of extending the sprint. Stories that fit within two weeks impose a smaller scope of thinking. For a deeper look at how cadence shapes outcomes, see this take on choosing the right iteration length.
2. Which issue types accept story points.
Any issue type can have a story point estimate in Jira by default. Work items like bugs and sub-tasks.
Inappropriate default choice. Only stories must have their story points Task and bug tracking occur but are not assigned points. Velocity’s purpose is forecasting user value and since tasks and bugs don’t deliver new user value, they don’t count. Martin Fowler's note on story points makes the same case from a different angle, and our own pointing-scales walkthrough covers which scale to pick once you've narrowed pointing to stories.
To set up
- Go to Project settings → Issue types.
- For each issue type, check whether "Story Points" is a field.
- Remove "Story Points" from Task, Bug, Sub-task, Epic. Keep it on Story.
This is a subjective view; many teams do it the other way (“We point everything”). While both methods are effective, using a points-everything pattern undermines the reliability of velocity as a forecasting tool.
3. Velocity calculation method.
In the default state, Jira version calculates either last-sprint or all-sprints averages. The appropriate response is rolling-3 as it indicates the last three completed sprints’ average. This connects to a broader argument about focusing on predictability over velocity — a stable 3-sprint window forecasts better than chasing a single high number.
To set up.
- Open the Velocity report for the board.
- In recent versions, the report shows multiple windows; pick "3 sprints".
- Older versions may require a custom report or external tooling.
If the rollover-3 report is not supported cleanly by Jira's built-in reports, you can do the math in a spreadsheet from the per-sprint completed-points data: sum the completed points of the last 3 sprints, and divide by 3.
LiteTracker has exactly these three settings configured in the default work: Stories-only points, rolling-3 velocity, 2-week default sprints. The decision to structure your code lets you do the right thing without a fight — see how that shows up in our pricing tier (unlimited users on free).
What to put in the sprint backlog
Three points to consider when dragging stories into a new sprint
Available effort for the sprint in person-days. Exclude holidays, on-call shifts, intentional interruptions. To calculate the daily story-point throughput, multiply by the rolling-3 velocity, team size, and days per sprint. Target the overall points-in-sprint at that.
Each story added to the sprint should have a clear acceptance criterion, an owner (or unassigned-but-ready-to-claim) and an estimate. If a story does not have one or the other, then it is “not ready”. Defer or refine.
The stories must be aligned with the sprint goal if there is one. A sprint with a goal of improving checkout, loaded with miscellaneous bugs, doesn’t make sense.
A functional sprint backlog comprises.
- 8–15 stories for a team of 5–7 engineers (the bandwidth matches typical attention).
- Total points roughly equal to the rolling-3 velocity.
- A 10–20% buffer (reserve some capacity for unplanned bug fixes).
- No "Epic" or "Theme" items pointed and committed — those don't fit in a sprint.
The most common Jira sprint mistakes
After using several Jira boards, these look familiar.
Teams add 30 stories to a 14-day sprint with a capacity for 12. Half get carried over to the next sprint. Velocity can be unreliable due to a range of variables being classified as "completed". Correct: work within your capacity.
Sprints that were started but then never formally closed generate velocity charts that have no completed sprints. In Jira, the “End sprint” action records a completion. Ensure that every sprint wraps up on time, even if some undertakings get carried over.
Carryover is treated as completion meaning any started work that is not accepted carries over to the next work iteration in scope and priority. The velocity count is for the sprint in which they accept them, not the one where they were worked. Attribute the points to the first sprint not the original.
Our Sprint slogan. Our goal will be “success Q3” or “ship great features”. This is a slogan, not a goal. Correction: Compose a sentence focusing on a specific user result. The Scrum Guide and our walkthrough on setting a goal for your iteration both stress concrete outcome wording.
A sprint is just a time-box, whilst version is a release version. A version could cover several sprints, and a sprint could fail to yield a release. Do not confuse them when reporting.
When NOT to use Jira sprints
The sincere examples.
- Pure kanban flow. If your work shape is reactive and continuous, sprints add overhead without benefit. Use a Kanban board in Jira instead.
- Single-engineer teams. Sprint ceremony for a team of one is theatre. Use the backlog without sprints.
- Pre-product-market-fit teams. The work shape changes too often; sprint forecasts won't stabilise.
- External-deliverable timelines. If you're working to a customer-imposed deadline that doesn't line up with sprint boundaries, the sprint cadence may produce false confidence. Plan around the deadline; use sprints as internal pacing.
For teams other than anchors: yes, run sprints. Conduct bi-weekly runs. Restrict to pointers. Apply rolling-3 velocity.
The Jira-shaped trade-off
Jira is customisable. That's both its strength and weakness.
The advantage of smaller stories is that the cycle time drops from days to hours and teams reach users up to 14x faster. And that advantage depends on a tracker that defaults to small-story discipline. You can configure Jira to make stories smaller (with mandatory acceptance criteria, story-size limits, and points-only-on-stories), but it doesn’t enforce it by default. A team that invests the effort to configure their tracker gets a tracker that enables the behaviours we want; a team that takes the defaults gets a tracker that disables them.
LiteTracker operates on an entirely different philosophy. It has limited knobs, default opinionations, and no need for configuration. The best behaviour is readily available (at login time). The compromise: reduced flexibility. Some teams like the flexibility of Jira; others like the opinions of LiteTracker — and for those moving across, the Jira importer handles the bulk transfer. Choose the one which best aligns with the needs of the team.
Frequently asked
How do I create a new sprint in Jira?
To create a sprint in Jira, open the Scrum board and select Backlog at the side bar. After that, click create sprint at the top of the backlog list. To begin a sprint, simply drag stories into the new sprint container and click on ‘Start sprint’ followed by setting the duration and dates.
Why don't I see a 'Create sprint' button?
You’re likely looking at a Kanban board, which does not have sprints. Or perhaps the project was set to Kanban type. Change the board type to Scrum or switch to the Scrum board on the project if the project has multiple types of boards.
What's the right sprint length?
Most software teams will use 2 weeks as a working default. For highly-reactive teams, aim for a one-week cadence. For work with naturally longer cycles and when stakeholders accept a slower cadence, aim for 3 to 4 weeks. At least three- week sprints help teams achieve a better outcome with their output.
Should I point tasks and bugs?
Certainly, Not in a healthy setup. Points should be attached only to stories. Tasks and bugs are tracked but not pointed. When everything is pointed, velocity will be a less reliable forecasting tool as the number reflects engineering activity rather than user-value throughput.
How do I set up rolling-3 velocity in Jira?
Access the board's velocity report. Select option '3 sprints' in the report settings under multiple averaging windows in the recent Jira Cloud versions. The earlier versions may require spreadsheet calculation from the per-sprint completed points.
What happens to stories that don't finish in the sprint?
The incomplete tasks are taken to next sprint. Their points are assigned in the sprint where they are accepted, not in the original planned sprint. Even if the work carries forward, formally end the sprint so that it’s recorded as complete.
Can I have overlapping sprints?
Indeed, Jira allows for concurrent sprints, enabling various teams to operate at different paces. Typically, there is only one active sprint on the same board; however, advanced configurations support multiple parallel sprints.
Should I use Jira's sprint goal field?
Yes, quickly. An outcome that would be the result of the sprint. If you don’t have a meaningful goal, skip it as empty goals are worse than no goals. Make it not a slogan.
Still stuck
Mechanically, it is simple to create a sprint in Jira. The friction lies in the three configuration settings length of sprint, pointed issue types, calculation of velocity. Most teams that complain that “Jira is broken” actually mean “Jira’s defaults are wrong for us”. The fix is configuration – not migration.
LiteTracker is the tracker for you if you want the opinionated defaults baked in: stories-only points, rolling-3 velocity, 2-week sprints, no Gantt charts. Unlimited users in free tier When migrating to a different tool isn’t an option, gain insight into how to configure Jira to behave a little differently.
In any case configure the three settings or battle them for eternity.