Using JIRA Dashboards to Control Sprint Chaos
The Problem — There’s No Way We’ll Hit Our Sprint Goals!
It’s the 6th day of a two week sprint. The team kicks off standup and starts to go around the room with what they worked on the day before, what they plan to work on today, and what’s blocking them. The 4th person speaks up and says “I know it’s kind of late in the sprint, but I don’t think I’m going to finish everything I have assigned to me.” The team recoils, realizing that they, too, have been over-optimistic about how much they thought they could get done in the last few days of the sprint.
The display of vulnerability by one of the team members helps the others see that they’re also over-committed. This behavior by the 4th person should be rewarded — it’s not easy to admit this! Unfortunately, by this point, there’s not enough time left in the sprint to recover, and stakeholders have to be told there’s a delay in a critical project.
If you’re a Product Manager, Engineering Team Lead, or part of a scrum team at all — this situation probably sounds familiar to you. Throughout this article, I’ll describe some tactical ways to surface these type of issues earlier in a sprint — facilitating critical conversations necessary for the success of your squad.
Visualizing Your Team’s Work with JIRA Dashboards
Using JIRA to track sprint velocity is a critical skill for any team lead to hone. It’s a must-have in the set of tools available to us in order to avoid chaos. When a team has a known velocity, subject to oscillations over time (team re-orgs, new members, projects with significant unknowns), it can be a fantastic way to avoid changing priorities and context switching. When teams feel like the rug won’t get pulled out from under them once a sprint starts, it creates a psychologically safe space for them to get work done efficiently.
Now — the reality is that unexpected work comes up during a sprint. For the sake of this article, I’ll assume that your team has a consistent way of estimating work each sprint. If you don’t, take a look at this article for some great ways to get started.
Let’s say your team has committed to 50 story points of work. By measuring the following statistics during a sprint, you’ll help your team know how they’re doing and how to adjust during a given sprint to maximize success:
- Time Elapsed in the Sprint (e.g. 53% after 5.3 days)
- % of Total Work Not Started (e.g. 60% of total points)
- % of Total Work In Progress (e.g. 25% of total points)
- % of Total Work Complete (e.g. 15% of total points)
- % Scope Change in the Sprint (e.g. 8% of total points)
Show Your Team The JIRA Dashboard During Standup
By highlighting these critical data points during each daily standup, you’ll achieve a few critical things. Let me start by saying when things are behind schedule, this not an excuse to blame your team. It is an opportunity to have conversations to get back on the right track, adjust sprint scope, and at the least, have an explicit conversation about why things are off track in the first place.
By bringing up this dashboard on a daily basis to kick off your standups, your team will have 8–10 opportunities to recover during a sprint compared to the one day someone finally decides to speak up and admit there’s no way we hit the team’s goals for the sprint.
You can create your team’s dashboard using the following features in JIRA, referencing the chart above for some examples:
- Create a Team Dashboard using JIRA’s Dashboard Creation Tool.
- Add the “Sprint Health Gadget”.
- Add the “Sprint Burndown Gadget”, referencing your team’s saved Filter.
- Add a “Pie Chart”, referencing the Epics currently part of your team’s sprint.
- Add two “Issue Statistics” widgets referencing your team’s issue labels and issue types.
- Add a “Two Dimensional Filter Statistics” chart, referencing your team’s ticket assignees and issue counts.
It All Starts with a Conversation
The most important thing to realize is that this is not an indictment on the team for underperforming. It’s a conversation starter. Standups will often have comments like this:
- Scope change has creeped up to 12% for the sprint. Is this additional work critical to the success of the sprint or can we prioritize it in future sprints?
- Scope change is up to 10% in the first four days of the sprint because of XYZ unexpected work. What can we punt from the sprint as a result?
- We’re 8% ahead on work completed compared to time elapsed in the sprint. What can we pull in to get ahead of next sprint or who needs help? (this is the rare one!)
It is critical to frame the conversation as just that — a conversation and not a blame game. Once your team realizes this, the frequency and quality of communication around how things are going during standups will dramatically improve! Consistently missing sprint goals tends to have a negative effect on morale for your team. When you consistently overcommit and underdeliver, no matter how hard your team is working, they will feel like they’ve let stakeholders down. As a team lead, these strategies will help you set realistic expectations with stakeholders and protect your team’s spirit.
Have some examples of conversations your team has had as a result? Mention them in the comments below!
Compass is looking for experienced software engineers who are passionate about solving complex problems with code. We’ve taken a novel approach to building business software — focus on the end user — and it’s been working! Our users love us. Come help us build a product that makes contact management easy and rescue 10,000s of people from the jaws of clunky, outdated software.
