A Day in the Life of JIRA
Planning Day Pains
The planning day arrived. As I sat down with the team to plan the sprint, I found myself facing the same challenges as in the last sprint, and in the sprint before that, and in the sprint before that, and in the sprint before that. It had been two months of agility; planning features, testing features, and delivering features. There’s got to be a better way to ease the planning misery, I thought.. After all, if one can automate the tests, how hard can automating the sprint planning can be? As it turns out, planning is harder than automation. At least on the planning day.
Planning involves more or less the same set of motions, not necessarily in the same order.
Find the stragglers from the last sprint and move them forward to the current sprint.
Get the list of developer JIRAs and assign them to the right owners.
Create QA JIRAs for the developer JIRAs and link them to the developer JIRAs.
Assign the QA JIRAs to testers.
Cost the QA JIRAs (or at least swag them to get a sense of how underworked we areSmile.
Nag only those developers who forgot to create the QA JIRAs for their developer JIRAs.
QA planning house keeping
Ensure the QA JIRAs are linked to the correct developer JIRA.
Ensure the QA JIRAs have the same fixVersion as developer JIRA.
Ensure the QA JIRAs have a Label, Risk Level, Planned Work Type, Wiki Link, etc.
Planning is beginning to sound like test cases. So far all I had learned was to write the JQL query in JIRA to get the above information. Some of my queries looked like the following:
Stragglers from the last sprint
filter in ("Last Sprint") AND project in (Demo_Project) AND status in (Open, Reopened) ORDER BY "GreenHopper Ranking" ASC
Unassigned QA JIRAs
filter = "Current Sprint (All)" AND assignee = EMPTY AND component = QA ORDER BY createdDate DESC, "GreenHopper Ranking" ASC
I got to give Darin credit for teaching me how to write the JQL queries and letting me borrow them as well. As we all know, query re-use is divine:). As I poured over my laptop, I copied over the JQL queries he had saved up in a text file and ran them one by one in JIRA. The file was his planning life blood. It saved about half an hour compared with typing them out on an ad-hoc basic. The file was now my planning life blood. Anyway, the text file saved the day and the sprint was planned out.
“I got to do this again after triage, every day“, I thought. All that work injected daily needs to be addressed everyday or soon as possible. This was a continuous planning challenge that I needed to solve sooner than later.
Filter the Noise
“Perhaps there is a way to save the queries in JIRA,” I mused.
A quick online search and perusal of few pages of JIRA manual shed light on things called filters.
Filters are saved searches.
So, saving queries as filters obviates the need to have a text file around. All the queries are saved and available right where they make the most sense and use – JIRA itself. On the eve of the fifth sprint I sat down to create the filters for each and every one of the planning queries. Here’s how to do it, in case you don’t know already:
What the official documentation doesn’t state is that a new filter is created as a private filter, by default. So, when I created the filter as the JIRA admin and wanted myself to use it, I had to edit filter details and share the filter with Everyone (or myself).
Fifth sprint went much smoothly. I no longer had to manage the text file. I didn’t have to copy paste queries. I didn’t have to backup the text file on the corporate personal drive any more. Many of the queries could be improved upon or optimized and I did that over the course of next few months.
However, it was still painful to do the rest of the planning business manually.
Everybody loves Gadgets
And I am no exception. JIRA has tons of built-in Gadgets and I tinkered with each and every one of them to find out which ones were really useful and which ones merely looked great without adding much value.
Gadgets let you customize the information that appears on dashboards in JIRA applications (or on your wallboards, if you use dashboards for that purpose).
Following gadgets are what I ended up using. Many are self explanatory, for others I have listed the filters I used.
Sprint Burn down
The filter for the sprint burn down simply lists all the QA items in the sprint.
filter in ("Current Sprint (QA Assigned)", "Current Sprint (QA Unassigned)") ORDER BY createdDate DESC, "GreenHopper Ranking" ASC
Days Remaining in Sprint
This gadget doesn’t require a filter. All I need to specify is the project and version (sprint)
Workload Pie: Current Sprint (Test All)
Some testers may own automation work, so this particular workload pie shows ALL types of work assigned to all the testers. This chart helps to load balance the sprint QA work.
filter = "Current Sprint (QA)" OR filter = "Current Sprint (All)" AND assignee == currentUser() ORDER BY "GreenHopper Ranking" ASC
Workload Pie: Current Sprint (QA)
This is purely manual QA work load, sans any automation work in the current sprint.
filter in ("Current Sprint (QA Assigned)", "Current Sprint (QA Unassigned)") ORDER BY createdDate DESC, "GreenHopper
Ranking" ASC
Workload Pie: Current Release (QA)
This chart helps prioritize the release QA work over the sprint QA work (which may be released in future sprints). If an injected work in the release needs an owner, this chart indicates who may be able to share the work load.
Filter Results: Current Sprint (QA)
A list of all QA items in the current sprint.
filter in ("Current Sprint (QA Assigned)", "Current Sprint (QA Unassigned)") ORDER BY createdDate DESC, "GreenHopper Ranking" ASC
Filter Results: Current Sprint (Ready for QA)
This is the bread and butter of QA Dashboard. On a daily basis, it tells me all developer JIRAs are ready for testing (or testing is in progress on them).
filter = "Current Sprint (QA)" AND issue in linkedIssuesHasStatus(Resolved, "is tested by") AND (status = Open OR status = Reopened OR status = "In Progress") ORDER BY updatedDate DESC
Filter Results: items Over Due
This filter shows any of the items on which I am falling behind. These work items usually result in a conversation with the manager and potential mitigation.
status in ("In Progress", Open, Reopened) AND assignee = currentUser() AND duedate < now() ORDER BY key ASC
Filer Results: Items Due By End of Week
I typically set a due date on all the hotfixes that I test. All of them show up here as a ready reminder.
status in ("In Progress", Open, Reopened) AND assignee = currentUser() AND duedate <= endOfWeek() items due by EOW
Filter Results: Current Sprint (QA Uncosted)
All QA work items that have not been assigned hours show up on this gadget. Before I load balance, it helps to, at least, swag the hours.
filter = "Current Sprint (QA)" AND issue not in (hasSubtasks()) AND remainingEstimate = EMPTY AND status != Closed ORDER BY createdDate DESC, "GreenHopper Ranking" ASC
Filter Results: Current Sprint (QA Unassigned)
QA items that are unassigned in the current sprint. These are typically injected QA JIRAs that need triage on a daily basis.
filter = "Current Sprint (All)" AND assignee = EMPTY AND component = QA ORDER BY createdDate DESC, "GreenHopper Ranking" ASC
Filter Results: Current Release (Needs a sprint)
Sometimes I have reopened developer JIRAs (bugs) without updating the fixVersion. The issue here is that these JIRAs in the past sprint don’t show up on any dashboard and tend to go unnoticed.
Developers may also not pay attention to the JIRA emails since there are a tons of them generated on a daily basis and may go unnoticed.
filter in ("CURRENT RELEASE (All)") AND fixVersion not in ("Sprint 1", "Sprint 2", "sprint 3", "sprint 4", "Sprint 5")
Filter Results: Current Release (Needs a QA item)
This is the basis of my nag mail for developers to create the QA JIRAs for their work items.
filter = "CURRENT RELEASE (All)" AND (component not in (QA) OR component is EMPTY) AND (resolution not in ("Cannot Reproduce", Duplicate, "Investigation Complete", Not-A-Bug, "Won't Fix") OR resolution = Unresolved) AND status not in (Closed, verified) AND (labels not in (qa-not-needed) OR labels is EMPTY) AND issue not in hasLinks("is tested by") ORDER BY "GreenHopper Ranking" DESC
Filter Results: Falling Through Cracks
Daily triage looks at all JIRAs without an owner and fixVersion. if a tester mistakenly assigns a new JIRA/bug to the developer without assigning a fixVersion, those JIRAs tend to get ignored by daily triage.
This issue may also occur if the stakeholders directly assign the JIRA with an empty fixVersion (they may not be familiar with the triage process).
status in (Open, Reopened) AND fixVersion = EMPTY AND NOT assignee = EMPTY AND project in (Demo_Project) AND createdDate >= -2w
Filter Results: Current Sprint (QA House Keeping)
I like to keep the QA JIRAs updated with various fields that typically go unnoticed or are not important for our day to day work. It doesn’t hurt to keep the work area clean.
filter = "Current Sprint (QA)" AND (type not in (Task, Story, Sub-task) OR labels is EMPTY OR "Technical Risk" = TBD OR "Planned Work Type" = Unknown)
Filter Results: Current Sprint (Not Verified)
This list proves useful as we get closer to the release day. items which are not verified (but the QA may be complete) show up here. Items for which we may have missed QA also show up here.
filter in ("Current Sprint (All)") AND status = Resolved AND resolution = Fixed AND (labels is EMPTY OR labels not in (qa-not-needed)) AND (component is EMPTY OR component not in (QA)) ORDER BY "GreenHopper Ranking" DESC
Filter Results: Current Release (Stragglers)
All the work items show up as stragglers on the planning day.
However, the list becomes useful as we get closer to the release day. Especially more on the day before the release day.
These are also the items that are topic of conversation for pushing out work to next sprint or to get help.
filter in ("CURRENT RELEASE (All)") AND status in ("In Progress", Open, Reopened) AND (labels is EMPTY OR labels not in (qa-not-needed)) AND component not in (QA)
Last Sprint (Stragglers)
Incomplete items from last sprint that need to be moved forward. If you remember, this is one of the first steps in the planning process.
filter in ("Last Sprint") AND project in (Demo_Project) AND status in (Open, Reopened) ORDER BY "GreenHopper Ranking" ASC
Some of the screenshots show empty results. That is because the sprint is planned out and the filter results come up empty. This is how I would like these filters to show up most of the time. However, the planning day is when these filters really shine.
Birth of the QA Dashboard
Your dashboard is the main display you see when you log in to your project.
I placed all my favorite gadgets on a brand new dashboard, creatively called QA DashboardSmile. This is how the QA dashboard looks like.
Planning is another name for Ctrl+F5
To plan the sprint, or the injected work items, or to get a feel for the QA status, I simply hit Ctrl+F5 on the QA Dashboard. I could do a simple refresh (F5), however, the hard refresh (Ctrl+F5) forces the JIRA queries to be re-executed, in case the results are cached.
It look a lot of time (years), to get to the QA dashboard. The dashboard is not static, but alive in the sense that I still continue to tweak queries/gadgets to suit new challenges or business or process demands. I expect this trend to continue and the QA dashboard to evolve.
Note that every project is different and every team has its own dynamics. So, your filters, gadgets and dashboards may be different from mine. The differences don’t make any one approach better or worse than the others. However, all of the approaches should ideally be making our QA lives easier.
How are you planning today?