Creating a sprint in Jira can feel confusing when the button is hidden, your board uses a different layout, or your work is sitting in the wrong backlog. A small setup mistake can leave tickets unassigned, dates unclear, and your team unsure about the sprint goal. Then, when the sprint starts, changing the plan becomes harder and progress reports become less useful. But here's the truth: creating a sprint only takes a few minutes when you follow the right order. I’ll show you where to find the sprint controls, how to add work, which settings matter, and what to do after the sprint begins. You’ll also see how company-managed and team-managed projects differ.
How to Create a Sprint in Jira
To create a sprint in Jira, open your Scrum board, go to the backlog, select Create sprint, add work items, enter dates and a goal, then choose Start sprint when your team is ready.
1. Open the Correct Scrum Board
Sign in to Jira and open the Scrum project that contains the work you want to plan. Then open the project’s board and select Backlog in the navigation.
Sprints are a Scrum feature, so you may not see sprint controls on a Kanban board. If the project has several boards, confirm that you are viewing the board connected to the intended project and team.
Here’s why: the board determines which backlog items appear, which filters Jira applies, and where the sprint will be created.
2. Select Create Sprint
On the backlog screen, look for the Create sprint button. Jira usually displays it above the backlog or near the sprint planning controls.
Jira creates an empty sprint container. At this stage, the sprint has no committed work, dates, or goal. You can add those details before starting it.
If you cannot see the button, check your project permissions and board type. You may need permission to manage sprints, or you may be viewing a board that does not support Scrum planning.
3. Add Work Items to the Sprint
Drag backlog issues into the new sprint, or use the issue selection controls to move them. You can add stories, tasks, bugs, and other work items that belong in the upcoming iteration.
For example, a product team might add these items:
- Build the password reset screen.
- Fix the mobile checkout error.
- Write acceptance criteria for the payment update.
Review each item before committing it. Check the assignee, priority, estimate, dependencies, and acceptance criteria. A sprint becomes easier to manage when every item has enough detail for the team to discuss it.
4. Set the Sprint Goal
Open the sprint details and write a short goal that describes the outcome you want. A useful goal focuses on customer or business value.
For example, “Make account recovery usable on mobile” is clearer than “Complete login tickets.” The first goal gives the team a decision-making guide when new requests appear.
A good sprint goal should help you answer one question: if the team completes only the most important work, what meaningful result should be visible?
5. Add Start and End Dates
Set the sprint start date, end date, and time zone. Many teams use one- or two-week sprints, although Jira allows different planning periods.
Choose dates that match your team’s real working calendar. If your team does not work weekends, avoid setting a sprint to end on a weekend unless your reporting process expects that schedule.
Dates affect burndown charts, velocity calculations, sprint reports, and calendar planning. A simple date error can make a completed sprint appear longer or shorter than it was.
6. Review Capacity Before Starting
Compare the planned work with the team’s available capacity. Consider holidays, training, support duties, planned leave, and unfinished work from the previous sprint.
For example, a team with four developers may have the capacity of only three developers during a week with scheduled maintenance. Reducing planned work can protect the sprint goal and lower mid-sprint reshuffling.
You might be wondering: how much work should you add? Use recent delivery patterns as a guide, then adjust for known changes. Jira’s velocity report can help, but judgment still matters.
7. Start the Sprint
When the team agrees on the scope, select Start sprint. Jira may ask you to confirm the dates and sprint goal before it begins.
After starting, the sprint appears on the active board. Team members can update issue statuses, record work, add comments, and monitor progress through the board and reports.
Before you click the button, confirm three things:
- The sprint goal is clear.
- The planned work fits the team’s capacity.
- The start and end dates match your working calendar.
What You Need Before Sprint Planning
A sprint can be created quickly, yet good planning begins before you select the button. Prepare a clean backlog, a realistic goal, and enough issue detail for useful estimation.
A Scrum Board
Jira connects sprint planning to Scrum boards. A board can display work from one project or from several projects through a saved filter.
If your board filter includes unrelated work, the backlog may become difficult to review. Ask your Jira administrator to check the board filter when issues seem missing or unexpected items appear.
A Prioritized Backlog
Place the most important work near the top of the backlog. This gives the product owner and delivery team a clear starting point during planning.
Suppose the top three items support a product launch, while the next five are minor cleanup tasks. The team should discuss the launch work first, then use remaining capacity for lower-priority improvements.
Ready-to-Plan Issues
Each issue should explain the expected outcome, relevant constraints, and acceptance conditions. A vague title such as “Improve search” gives the team little planning guidance.
A stronger issue might say, “Let shoppers filter results by price range on mobile.” It identifies the audience, behavior, and platform in one sentence.
Estimates and Dependencies
Estimates help your team compare planned work with available capacity. Dependencies show whether one issue must wait for another team or technical change.
For example, a reporting dashboard may depend on an analytics event being added first. Adding both issues to one sprint may be reasonable, but the team should understand the order.
Company-Managed and Team-Managed Sprint Differences
Jira’s project types can present different menus and planning screens. The overall workflow remains similar, but the location of settings and permission behavior may vary.
Company-Managed Projects
Company-managed projects use settings administered across the Jira site. Board filters, workflows, permissions, and sprint controls may be managed by Jira or project administrators.
These projects often support standardized processes across several teams. If you cannot create or start a sprint, ask an administrator to review your board access and sprint permissions.
Team-Managed Projects
Team-managed projects give a specific team more control over project configuration. The navigation may look different, and some options may appear directly within the project sidebar.
Open the team’s backlog and look for sprint planning controls there. If the sprint button is absent, confirm that the project uses Scrum and that you have the required role.
Why the Difference Matters
Two Jira projects can use similar issue types while showing different sprint controls. This explains why instructions from a colleague may not match your screen exactly.
Focus on the workflow rather than one button location: open the Scrum backlog, create a sprint, add work, set planning details, and start it after agreement.
How to Plan the Sprint Without Overloading It
Creating a sprint is the mechanical part. Planning a useful sprint requires choices about value, capacity, risk, and unfinished work.
Start With the Goal
Discuss the outcome before selecting a long list of tickets. The goal gives the team a reason for choosing one item over another.
For example, a goal to “reduce checkout failures” may prioritize payment validation and error handling over unrelated visual refinements.
Check the Team’s Capacity
Capacity represents the time people can realistically spend on sprint work. Subtract meetings, support coverage, leave, and other obligations from the available working time.
A team with 160 theoretical hours may have only 110 practical hours for planned work. Planning against the larger number creates pressure before the sprint even begins.
Discuss Unfinished Work
Review the previous sprint before pulling additional work. An unfinished item may need refinement, a smaller scope, or a new estimate.
Move it into the next sprint only after the team understands its remaining effort. Carrying work forward without discussion can distort progress reporting.
Protect the Sprint Goal
Urgent work sometimes arrives after the sprint starts. Discuss the impact before adding it to the active sprint.
If the new request is essential, remove or defer work with similar effort. This keeps the sprint’s workload visible and makes trade-offs easier to explain.
Managing an Active Sprint in Jira
After you start the sprint, Jira becomes a daily coordination space. Use the board to track progress and the reports to identify patterns.
Update Issue Statuses
Move issues through the workflow as work progresses. A common flow includes To Do, In Progress, and Done.
Your workflow may include review, testing, or approval stages. Keep statuses meaningful so the board shows where work is actually waiting.
Monitor the Burndown Chart
The burndown chart compares remaining work with the time left in the sprint. A flat line can indicate blocked work, delayed updates, or underestimated complexity.
Use the chart as a conversation starter. It does not explain the reason behind a change, so discuss the relevant issues with the team.
Handle Scope Changes Carefully
Jira allows you to add or remove work from an active sprint, depending on your permissions. Record the reason for significant changes in an issue comment or team channel.
For example, if a security fix replaces a planned design task, the team should understand why the original task moved and what effect the change has on the goal.
Complete or Close the Sprint
When the sprint ends, select Complete sprint from the active sprint view. Jira asks how to handle unfinished issues.
You can move incomplete work into the backlog or a future sprint. Review the choices carefully because they affect sprint reports and the next planning session.
Using ONES.com for Sprint Planning and Delivery
ONES.com is a project management platform that can support sprint planning, issue tracking, product work, and team collaboration in one workspace. It may suit teams that want an alternative workflow alongside Jira or a broader product delivery environment.
The best part? You can evaluate a platform by comparing its capabilities with your team’s actual process. Look for support across planning, execution, communication, and reporting rather than focusing on one sprint button.
Capabilities to Review
- Backlog management: Organize, prioritize, and refine product work before planning an iteration.
- Sprint planning: Group selected work into an iteration with goals, dates, and ownership.
- Issue tracking: Assign work, set priorities, manage statuses, and follow progress.
- Product roadmaps: Connect near-term sprint work with larger product milestones.
- Workflow customization: Adapt statuses and approval stages to match your delivery process.
- Team collaboration: Keep comments, discussions, and task context close to the work.
- Reports and dashboards: Review progress, workload, delivery patterns, and project health.
- Permission controls: Manage access across teams, projects, and work areas.
- Integrations: Connect planning and delivery activity with the services your team already uses.
For example, a growing product team may need sprint tracking plus roadmap visibility and cross-team dependencies. A smaller team may care more about quick planning and a simple board.
Before switching platforms, map your current Jira workflow. List your issue types, statuses, reports, permissions, and integrations. Then compare those needs with the capabilities available in ONES.com.
Common Challenges
The Create Sprint Button Is Missing
Problem: You open the backlog but cannot find the sprint control.
Solution: Confirm that the board uses Scrum, then check your project role and sprint permissions. A Jira administrator may need to grant access or correct the board configuration.
Issues Do Not Appear in the Backlog
Problem: A work item exists, yet it does not appear in your sprint planning view.
Solution: Check the board filter, project selection, issue status, and issue type. The board may exclude the item through its filter or workflow configuration.
The Sprint Is Overloaded
Problem: The team selects more work than it can finish during the planned period.
Solution: Compare estimates with real capacity. Remove lower-priority items, split oversized work, and protect the sprint goal.
The Wrong Sprint Started
Problem: You started the wrong sprint or used incorrect dates.
Solution: Review the active sprint settings immediately. Depending on your permissions, you may be able to edit details, move issues, or complete the sprint and recreate the plan.
Unfinished Issues Keep Carrying Forward
Problem: Several items move from sprint to sprint without reaching completion.
Solution: Investigate the cause during the retrospective. Break down large issues, identify blocked work, refine acceptance criteria, or reduce the amount planned next time.
FAQs
Can I create a sprint in a Kanban project?
Jira sprints belong to Scrum boards, so a standard Kanban board does not provide the same sprint planning workflow. If your team wants timeboxed planning, create or use a Scrum board with the appropriate project configuration. You should also confirm that the board filter includes the work your team plans to manage.
Can I add issues after a sprint starts?
In many Jira configurations, you can add issues to an active sprint if you have the required permission. Discuss the change with the team first, because adding work affects capacity and may reduce the chance of meeting the sprint goal. When you add one item, consider removing or deferring another item of similar effort.
What happens to unfinished work when a sprint ends?
When you complete a sprint, Jira gives you options for unfinished issues. You can move them into the backlog or place them in a future sprint. Review each item before choosing an action. Some issues need refinement or a new estimate, while others may no longer support the product goal.
Can a sprint have no goal?
Jira may allow you to start a sprint without a clearly written goal, depending on the project configuration. Still, writing one gives the team a shared focus and helps with scope decisions. A goal can be short, such as “Enable mobile password recovery,” as long as it describes the intended outcome.
How long should a Jira sprint last?
Many Scrum teams use one- or two-week sprints, but the best length depends on how quickly your team can plan, build, test, and review meaningful work. A shorter sprint can provide faster feedback, while a longer sprint may suit complex work. Choose a consistent rhythm, then review it during retrospectives.
Conclusion
Creating a sprint in Jira follows a simple sequence: open the Scrum backlog, create the sprint, add prioritized work, write a goal, set dates, review capacity, and start the sprint.
But here's the truth: the button is only the beginning. Clear issues, realistic capacity, and disciplined scope management determine whether the sprint helps your team deliver value.
If sprint planning feels chaotic, start with one improvement. Write a stronger goal, remove overloaded work, or review unfinished items before the next planning session. With a repeatable process, Jira becomes easier to use and your team gains a clearer path from backlog to completion.
Top comments (0)