Your team has a backlog full of important work, yet the next sprint still does not exist. People are unsure what to pick, when delivery begins, and which items deserve attention first. That uncertainty can delay planning and create confusion before development even starts.
The problem gets worse when someone starts the wrong sprint, adds too much work, or changes dates without telling the team. A few small setup mistakes can affect reports, commitments, and daily coordination.
Here's the solution: create the sprint in Jira, prepare its scope, review the commitment, and start it only when your team is ready. This guide shows you each step clearly, including the settings, permissions, and common issues that can interrupt sprint planning.
How to Create a New Sprint in Jira
Creating a new sprint in Jira means adding a planned work period to a Scrum board, choosing its backlog items, setting dates, and starting it when the team is ready. You usually create the sprint from the backlog before moving selected issues into it.
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 board connected to that project.
Choose Backlog in the board navigation. Jira displays the current backlog and any future sprints beneath the planning area.
Check the board name before continuing. A board can show work from several projects, so the wrong board may display unfamiliar tasks or a different team’s backlog.
2. Select Create sprint
On the backlog screen, select Create sprint. Jira adds a new sprint section above the backlog items or beneath any existing future sprint.
The sprint usually receives a default name, such as Sprint 4. You can rename it later, although a meaningful name helps everyone recognize the planning period.
For example, you might use Checkout Improvements for a focused release period. Some teams prefer a simple sequence, such as Mobile Sprint 12.
3. Move work into the sprint
Drag selected issues from the backlog into the new sprint. You can also use an issue’s action menu and choose the sprint field when that option appears.
Review each item before adding it. Confirm that the issue has a clear summary, a useful description, an owner, and enough detail for the team to estimate it.
If your board uses ranking, arrange the issues in priority order. The first items should represent the work your team is most likely to start.
4. Set the sprint details
Select the sprint’s action menu and choose Edit sprint when you need to change its name, goal, start date, or end date.
Write a short sprint goal that describes the outcome. For example, “Enable customers to save two payment methods” gives the team clearer direction than “Finish payment work.”
Choose dates that match your team’s normal cadence. A two-week sprint might begin on Monday and finish on the second Friday.
5. Review capacity and scope
Compare the planned work with your team’s availability. Account for holidays, support rotations, planned leave, testing time, and unfinished work carried forward.
Jira may show estimates through story points, time tracking, or another planning method configured for your board. Use the same method your team already understands.
Remove low-priority work when the sprint appears overloaded. A smaller commitment gives the team room to handle defects and unexpected requests.
6. Start the sprint
When planning is complete, select Start sprint. Jira asks you to confirm the sprint name and dates before activating it.
Once the sprint starts, its issues move into the active sprint view. Team members can then update statuses, add comments, record work, and monitor progress.
Review the confirmation carefully. Starting the sprint too early can create reporting problems and make the team’s commitment harder to interpret.
What You Need Before Sprint Planning
A sprint takes only a few clicks to create. Good planning takes more preparation because the team needs enough clarity to make a realistic commitment.
Confirm your Jira access
You need permission to create and manage sprints on the board. Jira administrators can control these permissions through project roles and board settings.
If the button is missing, contact your Jira administrator or project lead. The issue may involve access rights, board type, or the board’s configuration.
Prepare a refined backlog
Review the highest-priority issues before the planning meeting. Close duplicates, clarify vague requests, and divide oversized work into smaller pieces.
For example, “Improve account security” is too broad for a single sprint. Smaller issues might cover password reset warnings, login alerts, and session timeout settings.
Agree on the sprint goal
A sprint goal helps the team make trade-offs when new information appears. It also gives stakeholders a simple way to understand the sprint’s purpose.
Try describing the customer or business outcome first. “Reduce checkout errors on mobile devices” creates stronger direction than “Complete five tickets.”
Check team availability
Capacity affects how much work the team can reasonably accept. A team with two people on leave should plan less work than a fully available team.
Use recent completed work as a guide. If the team usually finishes between 25 and 35 story points, a commitment of 70 points requires careful justification.
How to Configure and Organize the Sprint
The sprint setup controls how clearly your team can track progress. Small choices around names, dates, ranking, and ownership make daily work easier.
Choose a useful sprint name
A sprint name should help people identify the period quickly. A number works well for stable recurring cycles, while a goal-based name helps focused teams.
| Naming approach | Example | Best use |
|---|---|---|
| Sequence | Sprint 18 | Regular delivery cycles |
| Theme | Search Reliability | Focused improvement work |
| Release link | Release 3.2 Sprint 2 | Work tied to a planned release |
Set realistic dates
Choose dates that match your team’s working rhythm. Avoid ending a sprint during a holiday period or immediately before a major operational deadline.
Consistent dates make reports easier to read. They also help stakeholders know when to expect reviews, demonstrations, and progress updates.
Rank issues before moving them
Issue ranking determines the order of work on the board. Place urgent customer-impacting work near the top, followed by items that support the sprint goal.
Do not treat every issue as equally important. When everything is urgent, the team loses a clear starting point.
Use labels and components carefully
Labels and components can help you group related work. For example, a component such as Checkout can identify work owned by a particular product area.
Keep naming consistent. Using mobile-checkout, MobileCheckout, and mobile_checkout creates unnecessary confusion in filters and reports.
How to Run a Better Sprint Planning Meeting
Jira can hold the plan, but your planning conversation determines whether the plan is useful. Keep the meeting focused on purpose, capacity, and risk.
Start with the goal
Read the proposed sprint goal before discussing individual issues. This gives the team a decision filter for every item under consideration.
Ask, “Does this issue help us achieve the goal?” If the answer is unclear, move the issue to a later sprint until its value becomes clearer.
Discuss uncertainty early
Ask team members about dependencies, technical risks, and unclear acceptance criteria. A five-minute discussion can prevent several days of blocked work.
For example, a front-end task may depend on an unfinished API change. Add the dependency to the plan before the sprint begins.
Estimate consistently
Choose one estimation method and apply it consistently. Story points can represent relative effort, while hours may suit teams with stable tasks and detailed time tracking.
Avoid changing estimation methods halfway through the sprint. Inconsistent estimates make historical comparisons less useful.
Leave room for reality
Planned work rarely accounts for every interruption. Reserve capacity for production support, code reviews, meetings, and defect fixes.
For example, a team with 80 available hours may plan 60 to 65 hours of sprint work. The remaining time absorbs normal delivery friction.
Using ONES.com Alongside Jira Planning
ONES.com can support teams that need a broader workspace around product planning, requirements, execution, and collaboration. It can complement Jira when your process extends beyond sprint boards.
The best fit depends on how your team manages planning and delivery. Review the workflow before adding another platform, especially when Jira already handles sprint execution effectively.
Capabilities worth evaluating
- Product and requirement planning: Organize product needs before they become sprint-ready work.
- Backlog organization: Group ideas, requirements, and delivery items into a clearer planning structure.
- Task and issue tracking: Monitor ownership, status, priority, and progress during execution.
- Sprint and iteration management: Plan time-boxed work and review progress against a defined goal.
- Roadmap visibility: Connect near-term sprint work with longer product milestones.
- Team collaboration: Keep discussions, decisions, and updates close to the work.
- Custom workflows: Adapt statuses and approvals to match your delivery process.
- Reporting and progress views: Help teams identify delays, workload concerns, and completion trends.
For example, a product team may use ONES.com for roadmap planning and requirements while using Jira for engineering execution. That arrangement can work when ownership and handoffs remain clear.
Here's why: adding a platform without defining responsibilities creates duplicate updates. Decide where planning lives, where engineering status lives, and how information moves between them.
Tracking Progress After the Sprint Starts
Starting the sprint is the beginning of execution. Your team should check progress regularly and respond quickly when the plan changes.
Use the active sprint board daily
Team members can move issues through statuses such as To Do, In Progress, and Done. The board provides a shared view of current work.
Look for issues that remain in progress for several days. A long-running item may need help, a smaller task breakdown, or a conversation about scope.
Watch the burndown chart
A burndown chart shows remaining work across the sprint period. A flat line may indicate delayed updates, blocked work, or underestimated complexity.
Do not treat the chart as a performance score. Use it as a signal that invites investigation.
Manage scope changes deliberately
New work sometimes appears after the sprint begins. Discuss its urgency and remove similar effort when the new request must enter the sprint.
For example, adding an urgent payment defect may require removing a lower-priority reporting improvement. This keeps the commitment visible.
Handle unfinished work correctly
When the sprint ends, Jira identifies incomplete issues. Decide whether each item belongs in the next sprint, returns to the backlog, or needs additional refinement.
Carry unfinished work forward only after reviewing its priority. Automatic movement can hide a change in business value.
Common Challenges
The Create sprint button is missing
Problem: You open the backlog but cannot find the option to create a sprint.
Solution: Confirm that the board is a Scrum board and that your account has sprint-management permission. Ask an administrator to review project roles and board access.
Issues do not appear in the backlog
Problem: The work you expect is absent from the planning view.
Solution: Check the board filter, project selection, issue status, and ranking settings. A board may exclude issues through its saved filter.
The sprint appears on the wrong board
Problem: You create the sprint in one board, then cannot find it elsewhere.
Solution: Review the board filter and project scope. Jira displays sprints according to board configuration, so two boards may show different work.
The sprint is overloaded
Problem: The planned work exceeds the team’s realistic capacity.
Solution: Compare the scope with recent delivery results, then remove lower-priority items. Protect the sprint goal before adding more tasks.
You started the sprint too early
Problem: The sprint began before the team finished planning.
Solution: Review the active work immediately. Jira may allow you to edit dates or move issues, depending on your permissions. Record the planning decision so reporting remains understandable.
FAQs
Can I create a sprint without starting it?
Yes. You can create a future sprint, add issues, set its name, and prepare the goal without activating it. This is useful when your team plans several cycles ahead. The sprint remains separate from the active sprint until someone selects Start sprint. Keep future sprints organized so the backlog does not become difficult to scan.
Can I create more than one future sprint?
Yes. Scrum boards can contain multiple future sprints, depending on your Jira configuration. This allows you to organize upcoming work across several planning periods. Avoid assigning every backlog item too far ahead because priorities can change. Keep the nearest sprint detailed and treat distant sprints as rough planning containers.
What happens to issues left unfinished?
At the end of a sprint, Jira shows incomplete issues and asks how you want to handle them. You can move them into a future sprint, return them to the backlog, or review their priority before making a decision. Discuss unfinished work during the review and retrospective. Repeated carryover may indicate oversized issues, interruptions, or unrealistic commitments.
Can I change sprint dates after starting it?
In many Jira configurations, a person with the right permission can edit an active sprint’s dates. However, changing dates can affect reports and how stakeholders interpret progress. Make the reason visible to the team, especially when the change results from a holiday, release delay, or planning mistake. Use date changes sparingly.
Can I add work after the sprint starts?
Yes, Jira generally allows teams to add issues to an active sprint. Before doing so, discuss the impact on the goal and capacity. If the new issue is urgent, remove or defer comparable work. Otherwise, the sprint may show progress that looks strong while the actual commitment keeps expanding.
Conclusion
Creating a sprint in Jira is straightforward: open the Scrum board, choose Create sprint, add prioritized issues, set the details, review capacity, and start the sprint.
The quality of the result depends on preparation. A clear goal, refined backlog, realistic dates, and visible trade-offs help your team work with confidence.
But here's the truth: a sprint solves little when the plan is overloaded or unclear. If planning feels chaotic, start with fewer issues, clarify the outcome, and use the active board to guide daily decisions.
The uncertainty that delays your team can become a practical delivery rhythm. Create the sprint carefully, keep the commitment visible, and improve the process after every cycle.
Top comments (0)