Creating a dashboard from scratch can be a daunting task. With the wealth of different gadgets available, it can be difficult to narrow down what information is useful, what needs the most attention, and which gadgets do nothing for you except display a beautiful, useless chart. After a few years of playing around with what works and what doesn’t, I’ve come up with a list of the best gadgets and filters you can use to stay on top of your sprints.
Frankly, I’m not a huge fan of Jira as a project management tool and I think the syntax of JQL is awkward, inconsistent and frustrating to work with. That said, a lot of companies make use of Jira not just as a ticket tracking tool but for management and reporting purposes as well, so chances are if you’re a working professional in the software space eventually you’re going to have to make peace with it (or at least feign a sort of begrudging respect).
Below are some filters and gadgets I use for every sprint dashboard plus how to read them, what your queries should look like, and why they’re important.
Sprint Health Gadget
This handy gadget gives you a progress bar and tracks metrics such as time elapsed, scope change and work completed. You’ll also get a count of issues that are blocked (the highest option on the Priority field) or flagged.
The colours displayed in the progress bar map to the status categories of the issues in the current sprint. In this example we have three status categories: To Do, In Progress and Done. The bigger the blue area (In Progress), the more tickets are in flight. If the grey section (To Do) of the bar is larger, that means there’s a lot of work that hasn’t been picked up by anybody yet. Since green means done, the more green you see on the bar the better.
Burn Down Chart
The classic. You can access a more detailed burn down chart in the Reports section of your Jira project, but having it on the dashboard as well is a nice visual and makes it more friendly for upper management should you choose to share it with that kind of audience.
The burn down chart is simply a picture of what has happened so far in your sprint. There are two key pieces of information you can get from the chart:
- If the burn down chart looks like a flat line a week into your sprint, it could indicate the following:
- Your dev team isn’t good at scoring tickets yet. This is common with newer teams and tends to even out over time, but if it doesn’t then it’s a sign you should be pushing back more during backlog grooming.
- Your team is working on a lot of large tickets all at once. This isn’t necessarily a bad thing, but do keep in mind a large code change generally requires a large QA effort as well. The QA team should be informed well in advance that a large chunk of testing is on its way over so they have adequate time to prepare for it.
- Your Product Owner is prioritising tickets in such a way that cross-dependencies are causing delays. This can be tough to get on top of, especially if it’s a brand new product under development or if your Product Owner isn’t very technical.
- You are not managing your blockers adequately. If this is because you don’t have a lot of visibility into blocked tickets, this dashboard will help a lot. 🙂
- If the burndown chart is going up instead of down, that is usually a sign of poor planning on Product’s part. There are a couple of ways you can alleviate this:
- Ask your Product Owner if the new ticket is really necessary, or if it can wait x days until the next sprint. Remind them of the opportunity cost of pulling in that new ticket.
- For each new ticket added to the sprint, try to remove one of a similar story point value so the overall amount of work to get done in the current sprint doesn’t change too much.
Two-Dimensional Array: Tickets by Assignee
This can be a bit hard to read at first, but once you get the hang of it you and your team members will see a marked improvement in quality of life.
Like its namesake, this widget will show you a two-dimensional array: on one axis is the ticket assignee, and on the other axis is the ticket’s status. Exactly what statuses show up and how you read this will depend on your workflow but the overall principle is the same – you want to be looking for people that have multiple tickets in an In Progress (or similar) status and find out what’s going on there. Solving problems programatically requires a lot of concentration, so you don’t want any of the developers on your team to have more than one ticket in progress at any given time (maybe two if the issues are closely related).
I guarantee that if you can keep this widget looking tidy, you will see faster movement on all of your tickets.
JQL:
Sprint in openSprints() AND <filter for your team goes here>
No Update in 3 Days
Does what it says on the tin! Tickets appearing under this filter are being worked on but have not been touched in three calendar days. The purpose of this filter is to help you identify tickets that may be stuck or require a hand-off, so you can jump on it before your Product Owner does.
Please note that this filter does not take into account business days vs. weekends – that’s a feature Atlassian hasn’t implemented yet, but you can check in here to see how they’re doing.
JQL:
Sprint IN openSprints() AND statusCategory = "In Progress" AND updated >= -3d AND <filter for your team goes here>
In QA
Tickets will show up under this filter if they’re in a QA status in your desired project. What you will probably see happen here is very few tickets in the first couple days of the sprint, then more results as your developers finish writing code and send their work over to QA for validation.
What you want to look out for here is the volume of tickets in QA – if there are two days left in the sprint and you’re seeing a buttload of tickets here, that’s a pretty good indicator your sprint will see a lot of churn/rollover. Ideally you want the issue count returned by this filter to be as steady as possible so the testing portion of the ticket’s life cycle can be thorough and there’s less of a need to compromise on code quality.
JQL:
sprint in openSprints() AND status = QA AND <filter for your team goes here>
Sprint Backlog
This filter will show you which tickets in the current sprint are waiting to be picked up by somebody. As the sprint progresses and more tickets move from In Progress to Done, you should see fewer and fewer items show up under this filter.
JQL:
Sprint in openSprints() AND statusCategory = "To Do" AND <filter for your team goes here>
Recently Completed Tickets
Tickets displayed here have moved from an In Progress state to a Done state within the last two days. If you’re halfway through your sprint and you haven’t seen anything show up here the whole time, it likely indicates your team is in trouble.
Since there are plenty of other filters in this list that will show you much earlier on if the team is having issues completing tickets, this filter’s primary purpose is to help you give your team a pat on the back for being awesome. Although finding and fixing issues is critical, finding ways to boost the morale of your team wherever possible makes a difference too.
JQL:
Sprint in openSprints() AND statusCategory = Done AND updated <= -1d AND <filter for your team goes here>
Blocked Tickets
Tickets returned by this filter require your immediate attention because it means someone is stuck and they have flagged their ticket.
JQL:
Sprint in openSprints() AND Flagged = Impediment AND <filter for your team goes here>
Urgent Tickets
This filter returns tickets in the current sprint that meet or surpass a certain threshold in the Priority field. If you see tickets here that aren’t in an In Progress status category while a bunch of other stuff is being actively worked on, you should have a conversation with your team’s Product Owner to double-check that the team’s priorities are correctly aligned and realistic expectations have been communicated between Product and Dev.
JQL:
Sprint in openSprints() AND Priority >= High AND statusCategory not in (Done) AND <filter for your team goes here>
New to Sprint
These tickets don’t necessarily require you to take action, but it is a good barometer for how your sprint is going – the fewer tickets that show here, the more your team is able to focus on the work they committed to during sprint planning. Additionally, you can use this piece of your dashboard to hold your Product Owner accountable and encourage him or her not to introduce too much scope creep to the sprint.
This filter will require the use of a third-party plugin to work but it’s cheap as far as licenses go and is well worth it.
JQL:
issueFunction in addedAfterSprintStart("<your board name goes here>")
Put it all together
Building a sprint dashboard helps you identify problems in your sprint early on so they don’t turn into huge bottlenecks later. Since I’m managing multiple development teams, I keep several of these open on a side monitor throughout my entire workday – it’s a great way to give both yourself and your leadership team a good snapshot of what your current sprint looks like.
If you’re interested in creating a more developer-focused dashboard to help your team members manage their own workload, you can check out How to Create the Perfect Developer Dashboard (with JQL).
Comments are closed.