As a Scrum Master, your focus is to support your team and ensure they’re able to get their work done. Let’s walk through a sprint to see what Jira can offer.
Planning a sprint
While you’re planning a sprint, it’s going to be important that you and your team have good visibility into your backlog. As you might’ve guessed, the best place to do this is the backlog of your scrum board. As your backlog is groomed, it should be very straightforward to see directly from the board which issue is the highest priority for the team (because it’s at the top). Your estimates will be displayed on the cards and you can expand and collapse the side panels to see things like links to epics or targeted releases.
If you are looking for a different view for sprint planning, you can also use Jira dashboards to visualize the same information. You may use gadgets on a dashboard to slice the information in different ways. For example, you could use Filter Results to highlight stale tickets in the backlog, or view a Pie Chart with the component breakdowns of work that has been recently completed.
A tenet of good reporting, both during and after a sprint, is to make sure your team’s work is estimated prior to starting the sprint. Any estimates added afterwards will be considered scope change and will affect your reporting. Dashboard gadgets that show unestimated stories committed to sprints that have not yet started can be a good way to keep this in check. As long as the team is estimating work, the Velocity Chart can be useful to see how consistent the team is with their estimation. It also helps get an idea of how much work the team should be committing to in upcoming sprints.
Executing a sprint
Once the sprint has begun, the focus will pivot on keeping track of progress. Both your board and dashboards can be utilized during your team’s regular standups. To start, setting up your Scrum board to have quick filters or swimlanes to represent assignees can help visualize what everyone is working on. You can also use native board reports, like Workload Reports, to see how stories are being divided among team members and understand the distribution of work.
Additionally, Sprint Reports and Sprint Burndowns can be monitored throughout the sprint to see how things are progressing – you don’t need to wait until a sprint is over to check these reports. Your Sprint Report will tell you if it looks like the team will be able to complete all of the work on time. This gives you, as Scrum Master, some insight into if there will be any issues completing the committed scope. The Sprint Report also shows you scope creep, to easily see stories that have been added since the sprint began.
The Sprint Health gadget can be placed on your dashboard and is another way to get an at-a-glance overview of the progress of the team.
Reviewing a sprint
One of the most important parts of the sprint process is reviewing your sprint after it’s been completed. Retrospectives are crucial to understanding how the team can continue to improve, and for you as the Scrum Master to get feedback on ways you can further support them.
Once you complete a sprint in Jira, your board will automatically generate and open a Sprint Report, with a link to create a Confluence page for your retrospective. Having these two tied together makes it very easy to incorporate this into the process and tie specific metrics to your retrospectives.
If you want to track progress across sprints, you also have Epic Burndowns and Release Burndowns available from your board reporting. These can forecast how many more sprints will be required to complete the scope of that epic or release.
For more advice on the best ways of visualizing data in Jira, have a read of When Data Visualization Really Isn’t Useful (and When It Is) and Make Better Jira Reports with Jira Visualization.