Short definition
A Jira sprint is a fixed-length iteration - usually 1 to 4 weeks - during which a Scrum team completes a committed set of issues from the backlog. Sprints have a defined start and end date, a sprint goal, and a finite list of issues that move together through the team's workflow board until the sprint closes.
What a sprint actually is in Jira
Behind the planning ceremony, a Jira sprint is just a custom field of type Sprint attached to an issue, plus the start/end date metadata on the sprint object itself. When you drag an issue into a sprint on the backlog screen, Jira sets the Sprint field; when you “start sprint,” Jira records the start date and surfaces the issues on the active sprint board.
The board, the burndown, and the velocity chart are all just views over that Sprint field. JQL queries
like sprint in openSprints() and sprint = "Atlas Sprint 47" work on the same data.
Sprint planning and the sprint goal
A sprint has three artefacts in well-run Scrum:
- The sprint goal - one sentence describing what the team is trying to achieve, written by the product owner. The goal isn’t a list of tickets; it’s the outcome the tickets serve.
- The committed scope - the issues moved into the sprint at planning. Velocity from prior sprints determines how much story-point capacity the team has to commit.
- The sprint backlog - the same list, but viewable in real time on the active sprint board as work progresses through To Do, In Progress, In Review, and Done.
Velocity and the burndown
Jira’s Sprint Report and Burndown Chart use the sprint’s start and end timestamps plus the daily status of each issue to draw the work-remaining curve. Velocity is the sum of story points on issues that closed inside the sprint - issues moved out after sprint start or carried into the next sprint don’t count.
This is why teams that change sprint scope mid-sprint or pad the sprint with “buffer issues” get useless velocity numbers: the data Jira plots is exactly what the team did, including the dysfunctional bits.
Sprints on Kanban boards
Kanban boards don’t have sprints. If you need iterations, use a Scrum board. The two board types are distinct in Jira and you can’t enable both at once on the same board.
Common questions
What is a sprint in Jira?
A sprint is a fixed-length iteration - usually 1 to 4 weeks - during which a Scrum team completes a committed set of issues from the backlog. Sprints have a defined start and end date, a sprint goal, and a finite list of issues that move together through the team's workflow board until the sprint closes.
How long should a Jira sprint be?
Most teams pick 2 weeks. One week is too short to absorb interruptions; four weeks is long enough that priorities drift mid-sprint. Sprint length should stay constant once chosen - changing it every few cycles breaks velocity trending and makes burndown charts misleading.
What's the difference between a sprint and a version in Jira?
A sprint is a time-box (when work happens). A version is a release container (what ships together). One sprint can contribute to many versions, and one version can span many sprints. They're independent fields on a Jira issue; don't conflate them.
Can a Jira sprint span multiple projects?
Yes, on a board configured with a multi-project filter - the same sprint can include issues from any project the board's JQL filter matches. Common pattern: a 'platform team' board that pulls in issues from every product project the team supports.