Sprints are the core unit of the agile scrum methodology and set the pace for the team’s entire workload. Jira, meanwhile – perhaps the most powerful task management tool available today – was built from the group up with agile in mind. In short, it’s an ideal platform to track, measure and manage your sprints.
This guide will take you from the starting blocks to the finish line for using sprints in Jira and give you step-to-step details of how the task tracking platform can help you.
The scrum methodology focuses on iterative development and the continuous delivery of working products and features. Rather than periodically launching brand new items or major updates, scrum calls for the development team to commit to making releases and shipping within short, regular cycles – known as sprints.
Releases may be made over the course of the sprint or at its conclusion. The key thing is self-organization, continuous delivery, and iterative development. This rapid cycling means that the team can get customer feedback fast and observe how real people use the product.
This saves the team from creating features that aren’t actually wanted by customers and allows usability issues to be caught early, with changes being made on the fly based on actual user activity.
Scrum also calls for a transparent working style, with the team setting targets and reflecting on project outcomes. All of this builds accountability into the process. The agile principle of self-organization, directing the course of the project, also endows the team with a sense of responsibility and achievement for successful outcomes.
All of this contributes to making sprints fast, efficient, and cost-effective. Jira, meanwhile, helps to make it quick, simple, and easy to launch and manage sprints.
Scrum teams come with several roles that aren’t necessarily self-explanatory.
Perhaps the most important role for managing scrum projects is that of the scrum master. It’s their job to coach the team through the scrum methodology, ensuring that the framework is followed and helping the team to develop and optimize their workflow.
The scrum master effectively owns the scrum process. A key task that they’ll often handle is scheduling events such as standups, sprint planning meetings, sprint reviews, and retrospectives. They might also handle admin tasks on boards, overseeing reporting and identifying blockers and points of friction.
The scrum master generally shouldn’t be the product manager/ product owner, however. The product manager is focused on delivering solutions to customer needs and overseeing the value that the team is delivering for all the stakeholders involved. They may handle key tasks such as grooming the backlog and helping to prioritize tasks, though. The scrum master’s job, on the other hand, is to oversee and finetune the process and to help to redirect projects if they’re falling off the rails.
A role with more overlap is that of the project manager – but rather than directing the team, the scrum master is a facilitator who ensures the flow of the project alongside their colleagues. Of course, there’s also the development team: all the people, engineers or not, who will be putting work into the project and driving it towards a successful outcome.
The first step of a sprint – prior to launch – is sprint planning.
The base layer of the project is formed by the product backlog. This is the full list of project features, functionality, and tasks that have been defined. Because of the importance of the backlog at this stage, it’ll make sense for the project manager to refine it before the meeting and to ensure that it’s up to date.
You may well arrive at the meeting with a broad plan for the sprint – or this may get defined as you go. During sprint planning, product backlog items, whether they’re specific technical jobs or broad feature requests, are then moved onto the active sprint.
The team should gauge how important these tasks are and the amount of time required to complete them. By doing so, the team can put together a realistic workload for the sprint, as well as defining the features and functionality that will be released within the period. The team can also prioritize and group tasks that should be held back for future sprints. The key thing is that the team is aligned and understands what they’re working towards.
It’s worth remembering that estimates are just that and that timelines may change over the course of the sprint, based on requirements. Additionally, if work comes with dependencies from other teams and departments, it may make sense to leave until the next sprint, when it can be fully specced out and then properly slotted into the plan.
In some cases, additional details may be required to flesh out user stories into actual tasks, issues, and epics that can be worked on.
And Jira is a fantastic platform for this discussion – after all, there’s a reason that your to-do list of issues in Jira is called the backlog. When ready, you can then simply begin moving issues from the backlog to the sprint – see below for details on creating a sprint.
We’ll assume that you’ve got a scrum project set up, but if you don’t, you can read here for advice on getting started.
The next step is to create your sprint. To do so, head to the Backlog, and with at least one issue in place, click “Create Sprint”.
On the next screen, you’ll be presented with the option to set a duration for the sprint and to define its objective (for example, naming it after a specific feature, theme, or goal). You can now start populating your sprint.
To start the sprint, you’ll need to have the “Manage sprint” permission set for the relevant project or projects. Admins can bypass this issue by making sure all permission schemes have “manage sprint” ticked for the relevant users and groups. To review project permissions, click “Settings” then “Projects”, then go to the relevant project, followed by “Permissions” and you’ll find “Manage Sprints” – where you can edit the settings.
There are also shortcuts for managing the sprint. By integrating tools like BitBucket with Jira, you can automatically progress issues through the workflow using trigger functionality. This means that tasks get automatically updated as soon as the code has been reviewed, saving the team time and logging updates instantly.
A key part of scrum is transparency – and the sprint is punctuated by daily standup meetings, assessing what the team is working on and potential challenges and setbacks that are coming up. This keeps everyone informed, up to date, and connected. The meetings should be short and can be held with the team literally standing up.
You may want to bring up feedback on Jira reports to track progress on the sprint (see below) – but standups shouldn’t be digging into too much detail. That said, you should go into the meeting prepared. Using Jira’s filters to review your open issues and recently updated items will give you a good overview of the team’s activity, to get you started.
Sprint reviews or iteration reviews should be scheduled either at the end of the sprint or when the team has hit a milestone. They give the team an opportunity to demonstrate and exhibit their completed work and for the team to ask questions and to share and explore feedback.
The work on show likely should have gone through QA already, but the team will need to agree on how ongoing bug testing and fixing is handled for tasks to be marked as complete and ready for demonstration.
The review also isn’t a performance review – that kind of analysis should be held back for the retrospective. However, if the team is struggling with their workload or addressing technical debt then this may become apparent at this stage.
Managing sprints in Jira is easy thanks to the range of powerful reports that the platform provides. These provide a wealth of information as you progress through the sprint helping you evaluate your performance once the sprint is complete.
From your sprint, you can find reports in the left sidebar.
The most relevant management tool is the (aptly named) Sprint Report. This shows the status of all the issues in the sprint and whether they’ve been completed or not, or have recently been added. This broadly illustrates the status of the sprint as it progresses, as well as the scale of new work that is being added (which can present problems if mismanaged). The report also includes the Burndown Chart…
The Burndown Chart shows the work left to complete in the sprint and allows you to compare what has been forecast to what has actually happened. The report is updated automatically and is extremely useful for providing a simple picture of the team’s workload evaluating whether plans are being born out in reality.
The report is a particularly useful one and can indicate if the team is failing to keep up with targets or if targets are being set too low. It’ll also make clear if tasks aren’t being sufficiently broken down; or if an excessive number of issues is being added during the course of the sprint.
The Velocity Chart, meanwhile, shows the work that the team has finished in each sprint. This is useful for indicating the team’s capacity.
The Control Chart displays how long each issue has taken to complete and the team’s average time to complete tasks. This illustrates how many issues the team can typically handle within a given period – which is crucial for planning.
The Cumulative flow chart shows how issues are adding up in each issue status. As the sprint progresses, the to-do items should gradually disappear – but significant bumps or changes of direction may indicate problems.
To end the sprint, the team needs to mark it off as being finished. To do this, go to “Active sprints”, in the left sidebar, and then click “Complete Sprint”.
Doing so will move any remaining issues on the sprint to the backlog. These can then be assessed at your next sprint planning meeting.
In the meantime, the team should hold a sprint retrospective. Whereas the sprint review is a celebration, the retrospective is a time for constructive criticism: what went right and what went wrong? This gives the team the chance to focus on successes and to work towards continuous improvement. Jira’s reports are absolutely invaluable here.
Are issues being assigned without enough detail at the planning stages? Or are an excessive number of new issues being generated during the sprint? The retrospective is the time to identify issues and to discuss how the workflow can be adjusted to help the team deliver.
While Jira works out of the box as an ideal tool for managing sprints, one of the great benefits of the platform is the huge range of upgrades, enhancements, and extensions available via the Atlassian Marketplace. Here are a few of the best apps to assist with running sprints in Jira.
Extending Structure for Jira, Structure.Gantt is an extremely powerful tool for delivering agile in Jira. Using the app, you can analyze and manage project timelines and visualize sprint data at the macro and the micro-level. All of this means that you can plan more efficiently and more effectively and ensure that your sprints are running to plan and on target.
You can find Structure.Gantt in the Atlassian Marketplace here.
Every sprint starts with a planning meeting – and Planning Poker can help to make it quick and easy. The app enables you and your team to rate and score tasks in real-time with a points allocation system. Planning Poker supports multiple device types and can handle groups of 30 or more participants, meaning that it’s suitable for teams of all sizes.
You can find Planning Poker on the Atlassian marketplace here.
This app is designed to help you plan out your sprint workload and how you’ll allocate your team’s resources, by time and by story points. You can view overall capacity and drill down to individual roles and team members.
The app also logs targets and performance, making it easy to review projections over time – and of course, all of this is plugged directly into your dashboards. A free trial is on offer and the app is available for Cloud, Server, and Data Center instances.
You can find Sprint Capacity Planning & Tracking on the Atlassian marketplace here.
Jira was built with agile and scrum in mind, which arguably means that it’s the perfect platform for you to manage the framework. With this guide in hand, you should be fully set to manage your sprints through Jira, from the planning meeting through to the retrospective – and you should have answers ready for the why, who, what, and when of how to handle sprints.