Jira Sprints: How to Create and Manage

Jira is one of the most flexible and customizable Project Management tools on the market. It’s also built from the ground up with Agile in mind making it one of the best solutions for managing Sprints in Scrum.

What is Scrum and how does it fit into Atlassian Jira?

Scrum is a lightweight Project management framework. It is designed to break down a large body of work into iterative increments.

Scrum was originally introduced as a way of improving collaboration in teams that are working on solving complex problems. In essence, the Scrum team breaks down the entire project into Sprints – short, time-boxed periods during which a Scrum team is to deliver an agreed-upon number of increments, AKA functional features. All five of the scrum events, such as sprint planning, daily scrum, sprint review, and retrospective take place during the sprint.

The Scrum framework is incomplete by design. It encourages the process of continuous learning and improving through your work. Your decisions will be based on observation, ability to adapt, and a fair bit of common sense.

You can learn more about Scrum from the Scrum guide and on Scrum.org. For now, I’ll just assume you know the basics and focus on the elements that are directly applicable in your Jira instance.

The Scrum team

The average Scrum team has three roles: Product owner, Scrum master, and Developers.

The Product Owner is accountable for the product value a Scrum team delivers. This person shares the goals of the Sprint, and should answer any questions the dev team might have regarding the product or users. PO is also responsible for Jira Themes & initiatives, Epics and User Stories. In terms of Jira, the Product Owner is responsible for translating the project plan into Jira, Jira roadmap design, as well as backlog management and prioritization.

The Scrum Master acts as the team’s coach. This person observes everyone’s activities and helps deliver a successful result. Scrum Master facilitates standups, helps to keep the scope in check during sprint planning, and hosts retrospectives. In terms of Jira, the Scrum Master is responsible for the Sprint board. He is usually the admin on the project and helps ensure that the cards are updated and flow through the established Jira workflow.

Developers deliver the work during the active Sprint. They have to determine what they can deliver during a Sprint. To them, Jira is a board with tasks they can contribute to.

Product backlog

Typically, the Product Owner creates the first batch of User Stories that are added to a backlog. These stories will be generalized as their main goal is to introduce a certain vector to the development process. Think of it as a place to store concepts and ideas. They may (or may not) become TODOs that will shape the product.

You can access your backlog in Jira from the backlog tab in the sidebar. You’ll then have to scroll down past planned sprints.

Sprint backlog

According to Jira best practices, after the initial user stories are refined, the team can agree to add them to the Sprint backlog. This is a separate pool of tickets that you’ll be working on during one Sprint. You’ll only want to add those stories that are immediately actionable.

You don’t have to cover 100% of the acceptance criteria at this stage, but make sure that the team understands the story well enough to be confident in their ability to deliver the result. Many companies use the INVEST method to set this Definition of ready in stone. You’ll want to move your issues from the backlog to the Sprint backlog in Jira after the Sprint planning session.

Story points

Jira issues have a custom field for Story Points. Engineers use them to measure the complexity of a story. The discussion regarding how many story points a story is worth happens during the Sprint Planning meeting, and the complexity is based on effort, uncertainty (engineers not being sure how they can deliver a feature), and risk.

The team will be burning these story points by completing the issues. How does this work?

The team discusses the work they need to do before the Sprint begins. All of the stories are reviewed and assigned with story points based on their complexity.
When the team commits to a Sprint, we know the stories we will be working on as well as their “worth” in points.
The team burns down stories that have met the Definition of Done by the end of the Sprint.
Any stories that have not been completed are moved back to the backlog and then refined and potentially re-estimated. These stories can then be moved back to the Sprint if the team decides on doing so.
When this practice is consistent for each sprint – the team will learn their velocity (the number of story points they typically burn during a Sprint) over time.

How long should a Sprint take?

A Sprint is always fixed in time. Teams do this to create consistency and accurately estimate the scope they can deliver throughout one Sprint. The nature of Scrum encourages teams to decide the perfect length of a Sprint that works for them based on Empiric evidence. The main point is in understanding why you need a time-boxed Sprint.

Force prioritization. You start thinking about what is the most important feature you want to deliver when you have a defined time frame to complete a body of work.
Demonstrate progress. The timeboxed iterations give an opportunity to regularly demonstrate progress on completed work. This gives a clear understanding of what’s going on in the project to the business side, and it also boosts team morale.
Avoid perfectionism and motivate closure. When you have an established deadline for the sprint, you plan things accordingly. You won’t have the time to try to make things perfect.
Improve planning. It’s easier to plan things for an established duration, especially if you have a couple of completed Sprints under your belt and know the scope the team can handle.
Continuous feedback. You have an opportunity to constantly give and receive feedback in an iterative and time-boxed Sprint.

You can decide on the optimal length of a Sprint. Base this decision on the specifics of product/project, team maturity, team size and the factors mentioned above. I would say that the optimal sprint length is when you can deliver a feature within your defined timebox. In this way, all the factors above start working for your team, and you are making the most value of your sprints.

Sprint planning

We’ve touched on the subject of Sprint Planning before. Let’s look at it in more detail. The Sprint capacity planning session is the meeting when you decide which tickets should make their journey from the product backlog and into the Sprint backlog. Every Sprint planning session is unique, but all must focus on answering three primary questions:

Why is THIS Sprint valuable?
What can we deliver during this Sprint?
How will we deliver the work we’ve planned?

Answering these questions will help you refine your stories. You’ll know their priorities and have an approximation of how much work each of them will require. The trick to Running a Sprint Planning session successfully is making sure that the whole team is prepared. The Product Owner needs to have a clear understanding of the Sprint’s goals. They should select the stories for the Sprint Planning session with this concept in mind. The Scrum Master can help by asking probing questions and making sure the scope doesn’t end up overblown. And the developers can use their analytical skills to try to understand stories, potential solutions, and the complexity of implementation.

How to create Sprints in Jira

Let’s face it, Jira has many issues with its UI. Sometimes finding the right button to enable or start something can be nothing short of a herculean feat. Case in point: finding closed Sprints is a hustle.

Luckily, starting a new Sprint is as simple as ABC. Navigate to the backlog from the sidebar and click the bright blue “Start Sprint” button once the issues from your Project backlog are refined, prioritized, and moved to the Sprint backlog.

Clicking on the “Start Sprint” button will open a pop-up window where you’ll fill in the details of your Sprint, such as:

Sprint name
Duration: You can select a desired duration from the drop-down menu
Start date / end date
And the goal of the Sprint.

Note that fields that are marked with a red asterisk are mandatory.

Parallel Sprints in Jira

Parallel Sprints can be a useful tool when you’d like to run several Sprints from the same backlog. This functionality can come in handy when you want to separate your teams, like developers and designers, while still working on the same goal.

Running parallel Sprints is slightly easier in team-managed projects. You can create as many of them as you need from the backlog.

Once you’ve created your parallel sprint – click on the “Start Sprint” button. This will create a new active Sprint in Jira simultaneously.

You can then select the Sprint you want to see on the board from the drop-down sprint selector.

Setting up parallel sprints in a company-managed project is a bit trickier. You’ll need a user with global Jira Admin permissions. This user can do the following if you are running your instance on Jira Data Center:

Select Administration (??) > Applications, then scroll down the page to the Jira Software section.
Under Jira Software configuration, select the Parallel Sprints checkbox.

And the following steps apply for Jira Cloud:

From the global navigation, select Settings () > Products.
Under Jira Software configuration, select the toggle for Parallel sprints.

Note: The velocity chart will not show the velocity per team.

How to list all Sprints?

I’ve seen people trying all kinds of crazy things with “Sprint JQL”. Sometimes it works for them, sometimes it doesn’t. In my experience, JQL is best used for issues only.

However, you can use the following string to list all Sprints and the issues within them based on the Sprint field. This can be handy when you are looking to review previously closed Sprints.

Sprint in (closedSprints(),openSprints()) AND project = “XYZ”

Yet, there’s a much simpler way of listing and reviewing your sprints – the Sprint report. The limitation to this convenience comes from the fact that the report is limited to company-managed projects and it is also board-specific.

That being said, it will show you the list of your Sprints along with associated issues. That being said, you can use the Sprint Burnup Chart in team-managed projects to achieve the same goal.

How to end a Sprint in Jira?

Technically, ending a Sprint is a matter of 2 clicks. Go to your backlog tab and click on the “Complete Sprint” button.

Clicking this button kicks off a different Sprint event – the Sprint Retrospective. This is a meeting where the whole Scrum team inspects how the Sprint went. Use this time to talk about individual performance, interactions, and processes. Try to find ways where you can improve or optimize something or maybe even adjust your Definition of Done.

We typically follow a format where each team member lists the “good’s” and the “improves”. This format of feedback works wonders as it gives everyone a chance to cherish a job well done while offering an opportunity to voice their opinion on things that might have been smoother.

Your incomplete issues will be moved into the backlog once you complete a Sprint.

How to measure relevant Sprint metrics in Jira?

While we are on the subject of reports, Jira offers a handy selection to help you analyze your team’s performance to adjust scope or make more accurate plans and estimates for the future Sprint. When talking about Sprints, there are three major reports you should focus on:

Burndown chart: Check on your team’s progress by comparing the numbers of Story Points that are left versus an approximation of an ideal burndown rate.
Burnup report: This report is the opposite of the burndown chart. It compares completed work (the number of burned Story Points) versus an ideal burndown rate and the scope.
Velocity chart: You can use this chart to plan your future sprints based on the amount of work that is typically done during a sprint.

Apps that help run Sprints

Smart Checklist: A Jira Checklist allows you to build actionable checklists and checklist templates. You can use them to enforce accountability and standardization. The app shines when the development team needs to design and refine your stories allowing you to add clear and visible Definition of Done and Acceptance Criteria checklists to your issues.

Planning Poker Online: This tool helps the team assign story points to their issues. The trick is that each member of the team assigns a certain value to an issue incognito. Then, when the cards are revealed, you’ll see whether the team has achieved a consensus regarding the complexity of the task. If you have different opinions – great. There’s room for discussion. The app has a Jira integration which makes it easy to include it into your process.

Easy Retro: This App helps run Sprint retrospectives. It offers a board that’s similar to the one you are used to seeing in Jira. The difference is that the lanes are dedicated to things that went well, things that require improvements, and to actionable items or the things you can improve in the next sprint. Easy retro also offers surveys that help with gathering feedback.