Beauty Contest gadget
Hey there! Got something interesting to share – it’s one complicated version of Jira Pie Chart gadget. It can help you wrap your head around your work-flow or tidy up that backlog that’s gotten a bit out of hand. Idea is simple, but implementation – a bit hard. Good news: I can give you “the template” 🙂
Spoiler: You will need Jira Rich Filters!
So, the idea itself was inspired by the “Beauty Contest” concept, which I first heard about in upstream Kanban classes. Sounds fancy, huh? But it’s really quite simple – it’s all about picking out the best items (whatever that means for you) and letting them move on to the next stage.
To keep your nerves, I devide following explanations into the blocks, so you can skeep straight to the part you need
| 1. What is “Beauty Contest” about? 2. What is the idea behind gadget? 3. How to create the gadget? 4. Query generator |
What is “Beauty Contest” about?
Imagine this: you’ve got your business idea generators going strong, churning out all sorts of ideas. But as these ideas move along the company-wide Kanban board, heading closer and closer to actual development work, things start to get a bit more focused and, let’s face it, a bit more complicated. And because of those pesky WIP limits, only the best of the best can make it through to the next stage.
But here’s the thing – there are always going to be some items that just don’t quite make the cut, no matter how hard they try. So why do we keep them hanging around?
Alright, let’s dial it down and shift our focus to development. Where do we make similar choices here? You guessed it – when we’re pulling items from our backlog into the To Do column! So, in a way, we’re also conducting a “Beauty Contest” here. Sure, we use some sort of prioritization techniques, or Cost of Delay analysis, but the fact remains. What I’m getting at is that there are clearly some items that consistently end up as losers, and I’ve seen this pattern repeat across various teams when it comes to backlog management. Backlogs just keep growing.
What is the idea behind gadget?
That’s why I wanted to create a gadget that would blatantly highlight these losers, making it hard to ignore their presence.
The key factor for filtering items depends on your unique situation. In my case, it was the age of the item. However, it could be a variety of things, such as class of service, type of item, client segment, and so on. So, what I came up with were two diagrams that illustrate specific segments (in my case, based on age) of items in backlogs in two different scenarios: 1) static (the age of items in the existing backlog); 2) dynamic (the age of items at the moment they are getting pulled from the backlog to To Do).
As you can observe in the backlog, there are numerous items that are 0.5-1 year or older (Zombie and Dead). However, the oldest item taken in over the last 4 cycles (where each cycle lasted 1 month) is never more than 6 months old. Essentially, once an item reaches the age of 0.5 years, it’s out. We simply won’t take it. It’s lost the contest.
This fact is hard to ignore, even for a Product Owner who has poured their heart into the items.
Once you’ve identified your patterns, there are two possibilities: either you adjust your planning to ensure that the losers are treated fairly (so, the Pies instantly display all the same colors on both), or you simply organize your backlog accordingly (“kill em all!”).
How to create the gadget?
Unfortunately, creation of sliced pie requires a bit more complexed query, than you can implement with standart gadget. So, we will need to bother your Jira admin to get Rich Filter creation rights 🙂 You should see appropriate section (“Manage Rich Filters”) under your Issues menu in Jira, if your company already has such a plugin installed.
When we have an access to use of Rich Filters, we just have to follow some simple and not very simple steps:
1. Set up a standard filter as the foundation query for your upcoming gadget. Determine the project or any other list of items you wish to visualize. In the image, which displays the already created rich filter general settings, you can view mine base-query in the “Filter query” field.
2. Navigate to the Smart filters section of your rich filter. Here, some work awaits us 🙂 We need to create two smart filters – one for each gadget (static and dynamic). Creating the static one is straightforward – you simply need to briefly define the categories of sorted items for your backlog. You can refer to my example labeled “Backlog health” filter.
3. The second one will be more challenging, especially concerning issue aging. Here, we must define the state of each item at the moment it was chosen for the next development cycle. If it pertains to issue type or, for instance, the issue reporter’s role/unit, it’s not as difficult. This information remains static and does not change after progressing. However, aging changes over time, and we’re interested in the item’s age precisely at the moment when we decided to proceed with it. Quite challenging indeed.
So, I tackled this by creating paired sub-queries, each defining the difference between the time when the item’s status was changed to the first status on the team Kanban board (moving from backlog to delivery cycle) and the time when the item was created:status changed to "to do" after startOfMonth(-1) before startOfMonth() AND created > startOfMonth(-44d)
Admittedly, I had an advantage in this case – my planning sessions occurred at the beginning of each month, making it easier to define. However, if your planning occurs dynamically (every 2 weeks or on demand), it’s no big deal. Just continue comparing period by period. Your periods will likely be shorter. For on-demand pull-ins, I personally used 2-week periods, so it was something like this (an example for the period before the previous one, with items aged 2-4 weeks by that time):status changed to "to do" after startOfWeek(-4) before startOfWeek(-2) AND created <= startOfWeek(-8) AND created > startOfWeek(-6)
By the way, yes, it’s not a very precise measure – an item’s age can vary slightly if it’s taken in during an already running cycle, as the filter includes all items created 14 days before the start of the month. And yes, the cycle start will be “exactly correct” only during the weeks of actual planning, if you use sprints (which is why I prefer monthly data still). But it’s acceptable for this context – we’re more concerned with general dimensions than detailed excerpts.
So, each color of the smart filter will have a long query, which consists of small logical parts devided by “OR”. Every logical part will describe the “age of color” for every of last planning periods. For example my “New” category is:
status changed to “to do” after startOfMonth(-1) before startOfMonth() AND created > startOfMonth(-44d) OR status changed to “to do” after startOfMonth(-2) before startOfMonth(-1) AND created > startOfMonth(-75d) OR status changed to “to do” after startOfMonth(-3) before startOfMonth(-2) AND created > startOfMonth(-104d) OR status changed to “to do” after startOfMonth(-4) before startOfMonth(-3) AND created > startOfMonth(-135d)
Click to see all the queries
New
status changed to “to do” after startOfMonth(-1) before startOfMonth() AND created > startOfMonth(-44d) OR status changed to “to do” after startOfMonth(-2) before startOfMonth(-1) AND created > startOfMonth(-75d) OR status changed to “to do” after startOfMonth(-3) before startOfMonth(-2) AND created > startOfMonth(-104d) OR status changed to “to do” after startOfMonth(-4) before startOfMonth(-3) AND created > startOfMonth(-135d)
Regular
status changed to “to do” after startOfMonth(-1) before startOfMonth() AND created <= startOfMonth(-44d) AND created > startOfMonth(-2) OR status changed to “to do” after startOfMonth(-2) before startOfMonth(-1) AND created <= startOfMonth(-75d) AND created > startOfMonth(-3) OR status changed to “to do” after startOfMonth(-3) before startOfMonth(-2) AND created <= startOfMonth(-104d) AND created > startOfMonth(-4) OR status changed to “to do” after startOfMonth(-4) before startOfMonth(-3) AND created <= startOfMonth(-135d) AND created > startOfMonth(-5)
Oldie
status changed to “to do” after startOfMonth(-1) before startOfMonth() AND created <= startOfMonth(-2) AND created > startOfMonth(-4) OR status changed to “to do” after startOfMonth(-2) before startOfMonth(-1) AND created <= startOfMonth(-3) AND created > startOfMonth(-5) OR status changed to “to do” after startOfMonth(-3) before startOfMonth(-2) AND created <= startOfMonth(-4) AND created > startOfMonth(-6) OR status changed to “to do” after startOfMonth(-4) before startOfMonth(-3) AND created <= startOfMonth(-5) AND created > startOfMonth(-7)
Survivor
status changed to “to do” after startOfMonth(-1) before startOfMonth() AND created <= startOfMonth(-4) AND created > startOfMonth(-7) OR status changed to “to do” after startOfMonth(-2) before startOfMonth(-1) AND created <= startOfMonth(-5) AND created > startOfMonth(-8) OR status changed to “to do” after startOfMonth(-3) before startOfMonth(-2) AND created <= startOfMonth(-6) AND created > startOfMonth(-9) OR status changed to “to do” after startOfMonth(-4) before startOfMonth(-3) AND created <= startOfMonth(-7) AND created > startOfMonth(-10)
Zombie
status changed to “to do” after startOfMonth(-1) before startOfMonth() AND created <= startOfMonth(-7) AND created > startOfMonth(-13) OR status changed to “to do” after startOfMonth(-2) before startOfMonth(-1) AND created <= startOfMonth(-8) AND created > startOfMonth(-14) OR status changed to “to do” after startOfMonth(-3) before startOfMonth(-2) AND created <= startOfMonth(-9) AND created > startOfMonth(-15) OR status changed to “to do” after startOfMonth(-4) before startOfMonth(-3) AND created <= startOfMonth(-10) AND created > startOfMonth(-16)
Pure miracle
status changed to “to do” after startOfMonth(-1) before startOfMonth() AND created <= startOfMonth(-13) OR status changed to “to do” after startOfMonth(-2) before startOfMonth(-1) AND created <= startOfMonth(-14) OR status changed to “to do” after startOfMonth(-3) before startOfMonth(-2) AND created <= startOfMonth(-15) OR status changed to “to do” after startOfMonth(-4) before startOfMonth(-3) AND created <= startOfMonth(-16)
Good news – I will create some simple generator for your own queries. Working on that 🙂