Starting a sprint in Jira can feel simple until the button is missing, the wrong board is open, or your dates create confusion for the team. One small setup mistake can leave issues outside the sprint and make progress reports unreliable.
That frustration grows when your backlog contains several unfinished items, multiple boards share the same project, or your team has never agreed on sprint length. You may also wonder whether to create the sprint first or add work before starting it.
Here's the good news: you can create a sprint in Jira in a few clear steps. This guide shows where to find the option, how to configure the sprint, what to check before starting, and how to avoid common Scrum workflow problems.
How to Create a New Sprint in Jira
To create a new sprint in Jira, open your Scrum board, go to Backlog, select Create sprint, name the sprint, add work, and start it when your team is ready. The exact labels may vary slightly between Jira Cloud plans and board configurations.
Before you begin
Make sure you are working with a Scrum board. Kanban boards usually do not use sprints, so the creation option may not appear.
You also need the right project permissions. If you cannot create or start a sprint, ask a Jira administrator to check your board access and sprint permissions.
Choose the correct board before you begin. The board controls which backlog items appear and which project settings affect the sprint.
Step 1: Open the correct Scrum board
- Sign in to Jira.
- Open the project connected to your Scrum board.
- Choose Backlog in the project navigation.
- Check the board name and project before making changes.
For example, a product team may have separate boards for mobile work, platform work, and support requests. Creating a sprint from the wrong board can make the sprint appear empty or show unrelated issues.
Step 2: Select Create sprint
In the Backlog view, look for the Create sprint button. Jira commonly places it above the backlog or near the sprint planning area.
Select the button once. Jira will add a new, future sprint to the board. It may appear above the backlog with a default name and no planned dates.
If you do not see the option, confirm that the board uses Scrum and that you have permission to manage sprints.
Step 3: Give the sprint a useful name
Open the sprint details and replace the default name with something your team can recognize quickly.
Good names include:
- Sprint 24
- Checkout reliability
- Mobile onboarding improvements
- April release preparation
A short name works best. Avoid names such as “New Sprint” because they provide no context during planning or reporting.
If your team uses sprint numbers, keep the naming pattern consistent. A consistent format makes past work easier to find during reviews.
Step 4: Add backlog items
Drag issues from the backlog into the new sprint. You can also open an issue and change its sprint field when that option is available.
Review each issue before adding it. Check that the item has a clear description, an owner, an estimate, and acceptance criteria when appropriate.
For example, “Improve search” is too broad for many teams. “Add filtering by product category to the search results” gives the team a clearer outcome.
Keep the sprint focused. Moving every backlog item into one sprint makes prioritization harder and reduces the value of the sprint goal.
Step 5: Set the sprint goal and dates
Open the sprint details and add a short goal. The goal should describe the result your team wants to achieve, rather than listing every task.
A useful goal might be, “Help new customers complete account setup without support.” That goal gives the team a decision filter during planning.
Choose the start and end dates based on your team’s agreed cadence. Many teams use one- or two-week sprints.
Keep the time zone in mind when team members work across regions. A sprint ending at midnight in one location may end earlier for another teammate.
Step 6: Start the sprint
When planning is complete, select Start sprint. Jira will ask you to confirm details such as the sprint name, dates, and goal.
Review the confirmation carefully. Starting the sprint changes how Jira groups issues and how reports measure progress.
After you start it, the sprint becomes active. Your team can then move issues through workflow statuses and track progress on the active board.
Here's why this matters: Jira reports use sprint activity to calculate charts, completed work, scope changes, and other delivery signals.
What Happens After You Start a Sprint?
Once the sprint is active, Jira places its issues in the current sprint view. Team members can update statuses, add work, estimate changes, and record progress.
Issues move through the workflow
An issue may move from To Do to In Progress and then Done. Your workflow may use different names, such as Selected for Development, Testing, and Ready for Release.
The board displays these states as columns. Moving an issue across the board updates its status and gives the team a shared view of progress.
Jira tracks scope changes
If you add issues after the sprint starts, Jira may show that work as a scope change. That can affect reports and make the sprint harder to interpret.
For example, a team begins with eight issues and adds four more halfway through. The team may still finish eight issues, yet the report shows a very different result.
Use mid-sprint additions carefully. Add work only when the team understands the impact on the sprint goal.
Reports become available
Jira can provide sprint reports, burndown charts, velocity information, and other planning views. These reports become more useful when your team keeps estimates and statuses current.
A burndown chart can reveal that work is moving slowly. It can also reveal that the team added several issues after the sprint began.
Use reports as conversation starters. A chart can show a pattern, but your team still needs to discuss the reason behind it.
How to Plan a Better Jira Sprint
Creating a sprint takes seconds. Creating one that your team can complete requires thoughtful planning.
Start with a clear outcome
Write the sprint goal before selecting a large group of issues. The goal helps you decide which work belongs together.
Suppose your goal is to reduce checkout failures. A payment validation issue may belong in the sprint, while a color change for the settings page probably does not.
This approach prevents the backlog from becoming a random collection of tasks.
Use capacity instead of optimism
Estimate how much work the team can complete during the sprint. Consider holidays, meetings, support duties, planned leave, and technical maintenance.
A team with 40 available hours does not have 40 hours for planned development. Regular interruptions reduce practical capacity.
Leave room for unexpected work when your team handles production incidents or customer requests.
Check issue readiness
Before adding an issue, ask whether the team understands the requested result. A vague item often creates delays during development.
Useful readiness checks include:
- The expected outcome is clear.
- Acceptance criteria explain completion.
- Dependencies are visible.
- The team can estimate the work.
- The issue is small enough for the sprint.
You might be wondering whether every issue needs perfect detail. It does not. The team needs enough clarity to begin confidently and identify open questions early.
Order work by value and dependency
Place urgent or high-value work near the top of the sprint. Put prerequisite tasks before work that depends on them.
For example, an API change should usually precede a user interface update that relies on the new response.
Ordering issues reduces waiting and helps the team spot blocked work sooner.
How to Edit, Pause, or Complete a Sprint
Jira lets you adjust sprint details, though every change should have a clear reason. Frequent changes can make planning history difficult to understand.
Editing an active sprint
You may be able to change the sprint name, goal, or dates after starting it. Open the active sprint settings and choose the relevant edit option.
Change dates when circumstances genuinely affect the schedule, such as a company shutdown or an agreed change in cadence.
Avoid extending every sprint because work is unfinished. Discuss the cause and improve estimation or scope selection instead.
Moving an issue into another sprint
You can move an issue between sprints when priorities change. Jira may warn you when the move affects an active sprint or future sprint.
Record the reason in the issue conversation or team notes. That context helps during the retrospective.
Completing a sprint
When the sprint ends, open the active sprint view and select Complete sprint. Jira will ask where unfinished issues should go.
You can usually move incomplete issues into the backlog or a future sprint. Choose based on current priority rather than automatically carrying everything forward.
For example, an unfinished compliance task may belong in the next sprint. A low-value enhancement may need refinement before it returns to planning.
Handling an abandoned sprint
If the sprint goal is no longer relevant, you may need to complete it early. Jira will ask what should happen to unfinished issues.
Discuss the decision with the team and product owner. Ending a sprint changes reporting history, so use this option deliberately.
Jira Sprint Setup Compared With Other Planning Methods
A Jira sprint gives your team a timeboxed planning container. That structure differs from a continuous flow approach, where work moves through the system without fixed sprint boundaries.
| Approach | Useful when | Main planning signal |
|---|---|---|
| Scrum sprint | The team plans toward a short-term goal. | Completed work during a fixed period |
| Kanban flow | Priorities change frequently. | Work movement and cycle time |
| Release planning | Several teams coordinate toward a launch. | Milestones and dependencies |
Neither approach fits every team. A support team with unpredictable requests may prefer continuous flow, while a product team building a feature may benefit from a sprint goal.
Use Jira’s sprint feature when a timebox helps your team focus. Avoid creating artificial sprints when the workflow does not need them.
Using ONES for Sprint and Project Coordination
ONES is a project management platform that can help teams coordinate planning, delivery, and cross-team work alongside an Agile workflow.
It may suit teams that want a broader workspace for requirements, tasks, collaboration, and delivery visibility. You can evaluate it when Jira’s setup feels too fragmented for your organization.
Capabilities worth evaluating
- Backlog and sprint planning: Organize work, prioritize tasks, and plan short delivery cycles.
- Custom workflows: Adapt statuses and approvals to match your team’s process.
- Issue and task tracking: Assign owners, set priorities, and follow progress through completion.
- Requirements management: Connect product needs with planned engineering work.
- Roadmap visibility: Present upcoming initiatives and delivery milestones in one view.
- Dependency tracking: Identify relationships between teams, tasks, and planned outcomes.
- Reports and dashboards: Monitor progress, workload, risks, and delivery trends.
- Team collaboration: Keep discussions, decisions, and updates connected to the relevant work.
The best part? You do not need to change tools simply because a feature exists. Compare the platform with your team’s actual workflow, permission needs, reporting habits, and delivery goals.
When another platform may help
Consider another platform when your team needs more connected planning across product, engineering, quality, and operations.
For example, a growing organization may want a roadmap view linked to requirements, development tasks, and release milestones. A single planning environment can reduce repeated status updates.
Evaluate migration carefully. Review permissions, workflow rules, integrations, reporting needs, and historical records before making a decision.
Common Challenges
The Create sprint button is missing
Problem: You open the backlog but cannot find the sprint creation option.
Solution: Confirm that the board is a Scrum board. Then ask an administrator to review your project role and sprint permissions.
The sprint contains the wrong issues
Problem: Issues from another project or team appear in the sprint.
Solution: Check the board filter and project selection. A shared board may display work across several projects.
The sprint starts with too much work
Problem: The team adds every high-priority issue and quickly becomes overloaded.
Solution: Compare planned work with realistic capacity. Move lower-priority items back to the backlog.
Unfinished issues carry forward repeatedly
Problem: The same issues appear in several consecutive sprints.
Solution: Break large issues into smaller outcomes, improve acceptance criteria, and review blockers during the sprint.
Reports do not match team expectations
Problem: Burndown or velocity charts look unusual.
Solution: Review late additions, estimate changes, reopened issues, and status transitions. These details often explain unexpected report patterns.
FAQs
Can I create a sprint without starting it?
Yes. Jira lets you create a future sprint in the backlog before it becomes active. You can name it, set a goal, choose dates, and add issues during planning. This gives your team time to prepare without changing the current sprint. Start it only when the team has agreed on the scope and timing.
Can I create more than one future sprint?
Yes, you can create multiple future sprints in many Jira Scrum configurations. This can help with short-term planning, although detailed plans may change. Keep near-term sprints well defined and treat distant sprints as flexible planning containers. Too many planned sprints can create unnecessary maintenance.
Why can’t I start a sprint in Jira?
The common reasons include missing permissions, an incorrect board type, an active sprint already running, or a board filter that prevents proper planning. Check whether you have permission to manage sprints and whether the board is Scrum. If the issue continues, ask your Jira administrator to inspect the board configuration.
Can I add an issue after the sprint starts?
Usually, yes. Jira allows teams to add issues to an active sprint when permissions and board settings allow it. However, late additions change the sprint scope and can affect reporting. Discuss the trade-off with the team before adding work. If the request is not urgent, place it in the backlog instead.
What should happen to incomplete work?
When you complete a sprint, Jira generally lets you move unfinished issues to the backlog or another future sprint. Review each item before carrying it forward. Some work may need a clearer scope, a lower priority, or cancellation. Automatically moving everything forward can hide planning problems.
Conclusion
To create a new sprint in Jira, open the correct Scrum board, enter Backlog, select Create sprint, name it, add suitable issues, set the goal and dates, then start it when planning is complete.
But here's the truth: the button is the easy part. A useful sprint depends on a focused goal, realistic capacity, clear issues, and disciplined scope management.
If sprint planning feels chaotic, review your board configuration, permissions, issue quality, and team cadence. You can also compare broader platforms such as ONES when your planning needs extend across several teams.
The result is a sprint your team can understand, execute, and review with confidence.
Top comments (0)