Ticket Prioritization Discussion
-
Sure to be controversial, but not in a garage way (I hope)!
So an official but unofficial part of my job is handling ticket prioritization (using Kanban) on our accepted backlog. Our official guidelines on this are <valley girl>Lol, like...figure something out?</valley girl> for anything that isn't a yellow/red alert (ie not something actively degrading service for customers that has to be fixed via hotfix.
I decided to do a weighted sum of impact + Effort + Age + Type, with higher sums = higher priority
So here are the weights I came up with to try to systematize this (with last call always being my judgement):
Impact: How important is this?
20 points: A major workflow issue. A major thing either doesn't work as expected (or has high risk of going bad) or how it's expected to work is badly wrong. High risk of data corruption and causing angry support calls. These are rare, thankfully.10 points: A priority customer request. Generally new features requested by either multiple customers or one of the customers we have good working relationships and feedback from. These are our feature priorities.
5 points: Minor workflow issue. This is where most "it's a defect, but mostly a corner case" or "we want to tweak that behavior" things go.
2 points: Internal stability. This is paying down tech debt (that can't go in one of the above) and refactoring without customer-facing impact. Debating whether this should go higher. Gets a category change when it impacts something higher that we want to do.
1 point: UI polish. Fixing error messages, tweaking UI (colors, spacings, etc) when things still work.
Effort: How long will this take (estimated, using exponential scale)? Less is more.
4 points: 2h or less
3 points: 4h
2 points: 1 day
1 point: 2 days
0 points: 1 weekAge: How long has the ticket been sitting there waiting to be worked on (in either open or accepted)?
2 points: > 1 month
1 point: > 1 week
0 points: < 1 weekStatus: Defect vs feature. Defects get 1 point as a tiebreaker.
So far this has been working mostly ok. I think. But I'm curious as to what other people think. Is this semi-sane as a first-pass ranking set? Are there things you'd prioritize higher? I'm very new to this whole software dev thing, so feedback from people who have been around longer or who have experience in such roles would be welcome.
-
I would probably rank UI bites a bit higher - 2 or maybe even 3 points (adjusting the rest accordingly). Pros tend to believe that a program should be functional first and look pretty later (if ever). First off, they often aren't functional anyway, so they better not get all uppity about that. But what I want to say is - maybe I'm wrong about it - one thing that I've noticed is that the program should also appear to work. It's not just progress bars, spinners (shit idea, tbh), it's all UI elements reacting and changing state properly to reflect the internal state as accurately as possible. It's a very difficult job to do so while remaining user-friendly.
You don't get much points for all that work (and it's a lot of work that has gotten more and more corners cut in the past decade or so), but it can sometimes make a difference between "your shit no worky asshole" ticket and a bit more civilized attitude. Not always, sometimes.Disclaimer: I have no data and it's probably personal bias.
-
@Benjamin-Hall said in Ticket Prioritization Discussion:
So far this has been working mostly ok. I think. But I'm curious as to what other people think. Is this semi-sane as a first-pass ranking set?
A trick I use for ranking things is to have the scores be rates of increase of importance, so old low-priority tasks don't get dropped to the bottom of the stack indefinitely. (Stop-the-world bugs get a large initial non-zero offset.)
-
@dkf said in Ticket Prioritization Discussion:
@Benjamin-Hall said in Ticket Prioritization Discussion:
So far this has been working mostly ok. I think. But I'm curious as to what other people think. Is this semi-sane as a first-pass ranking set?
A trick I use for ranking things is to have the scores be rates of increase of importance, so old low-priority tasks don't get dropped to the bottom of the stack indefinitely. (Stop-the-world bugs get a large initial non-zero offset.)
With the caveat that I haven't had much experience with being the prioritizer, the "old low-priority tasks get dropped to the bottom of the stack indefinitely" issue was kind of my gut impression of seeing the relative scoring of Internal stability & UI polish - it kind of looks to me like those will never get done unless you're out of work, since especially tech debt will typically be larger effort and as such will probably never rise above 5 points total.
Maybe there would be some way to quantify "this would have helped with fixing X bug faster" or "this is in an area where we have fixed N bugs in T months" and use that to give extra priority to tech debt in hot spots?
Personally, I've always been a little more in favor of having a separate backlog for tech debt cleanup and allocating time 80/20 (ish) between "real" work and the cleanup backlog, but I can understand how that's frustrating and/or confusing from the product owner's perspective and probably not a good actual solution to the "we're always running around pissing on fires" problem.
-
@Benjamin-Hall
I would actually remove effort from the calculation. Do the important things first, regardless of how long it takes.
-
@Jaime said in Ticket Prioritization Discussion:
@Benjamin-Hall
I would actually remove effort from the calculation. Do the important things first, regardless of how long it takes.Why? The scale of importance to effort is already such that importance always wins out. It is only when importance is the same for multiple tickets does effort come into play.
If anything, I would drop the age requirement because IMO it is already accounted for by importance. If it was important it wouldn't be months old to begin with.
-
Relative ranking of importance is going to be (somewhat) arbitrary anyway. Is UI polish more or less important than internal stability? Are those the right categories in the right place? I doubt there's a single right answer, so as long as you can defend your choices, it'll probably be fine. Minor tweaking can be done as time goes by.
The major choice seems to be with age (and possibly effort). Do you ever want age to override importance? Right now that will never really happen. So, as others have said, accumulating age might help. (FWIW- if something has been sitting around for 10 months, taking a good look at the item might be in order, to see if it's still relevant.)
-
@Benjamin-Hall IMO, age is completely irrelevant to a ticket's priority. In fact, the older a ticket gets (without people commenting "yo what's the status?" or "when is this getting completed?") the lower priority I consider it. If everyone's getting by just fine with a missing feature or a trivial bug, why would I pay it any more attention a year from now than I do today?
I disagree with those saying "effort" shouldn't play a role at all. I think it's important to schedule tickets in such a way you get the most bang for the buck. If one week I do 5 important tickets versus 1, that is a significant difference. That being said, the one thing you just need to avoid is let important yet time consuming tickets stay in limbo just because they're hard, though. It's all a balancing act. So I think there might need to be some tweaking of the algorithm, so that important yet time consuming issues don't get perpetually pushed off, which is a common trap to get into.
-
@The_Quiet_One said in Ticket Prioritization Discussion:
IMO, age is completely irrelevant to a ticket's priority. In fact, the older a ticket gets (without people commenting "yo what's the status?" or "when is this getting completed?") the lower priority I consider it. If everyone's getting by just fine with a missing feature or a trivial bug, why would I pay it any more attention a year from now than I do today?
The fact that we aren't bugging you is a symptom that the fix process is too slow, not a sign that the fix isn't needed. When fixes to a core framework take months or years to happen, application teams don't want to (or can't) wait. Instead they come up with a workaround, and then copy/paste it into all 200-some applications using the framework.
-
@Unperverted-Vixen That would be true in a system where you'd have just the same people working on it at all times. We have an ever-revolving userbase who hasn't learned to live with those workarounds. For sure, if there is a bug that has a tedious workaround or is otherwise very annoying, we hear about it, and we fix it.
But we have bugs that are a few years old that are something like "If I [do something very specific that has only happened to that one person and nobody else] the page momentarily flashes white." and we assess due to some complicated technicalities that it would take a man-month to correct, we aren't going to waste time on that issue if there are far more productive tickets to accomplish.
-
@The_Quiet_One said in Ticket Prioritization Discussion:
That would be true in a system where you'd have just the same people working on it at all times. We have an ever-revolving userbase who hasn't learned to live with those workarounds. For sure, if there is a bug that has a tedious workaround or is otherwise very annoying, we hear about it, and we fix it.
That's fair. We're definitely the former.
-
As far as our situation:
- We've got 2 developers, 1 QA, and one designer (half-time, she's also designing for a different team).
- Our ticket flow is usually fast enough and the number of "high-importance" (ie 10 or 20 point Impact items) is low enough that we average mostly tickets of total value 6-12.
- There are some things that have stagnated, but I think our "oldest in column" is roughly a month. Maybe a bit more, but not much more. We've cleared out most of the real old dead-wood and are pretty good about going through and triaging the accepted column, closing the defects that got fixed elsewhere as a knock-on effect of something else or features that we're just not going to do any more.
- We make a concerted effort to keep the total number of defects in not-merged (open, accepted, in progress, testing combined) under about 15 at any one time.
- Our userbase so far is quite small and we don't have well-developed feedback loops. So it's mostly team-internal as far as people bugging us about non-urgent stuff (ie "this is broken right now for XYZ customer"). Urgent stuff gets handled out-of-band and isn't prioritized here (effectively having priority 1000, and is exempt from limits on tickets in progress).
Basically, age and effort are secondary sorting mechanisms. I guess I could do it explicitly that way, sorting by (in order)
- Impact
- Effort OR age (whichever I decide eventually)
- Age or Effort (ie the other one)
- Status
Which would lend itself to merely assigning them incrementing integers. I'm going to push our engineering manager (who has the permissions on the Jira setup itself) to give me some more fields so I don't have to keep it in a spreadsheet and manually re-order when things are ingested.[1]
[1] semi-related rant--Jira is the worst PoS at this. It shows like...4 things at a time (even on a big screen) and places things in order quite (seemingly) at random. Which means re-ordering stuff is an involved manual process that mostly has to be done in reverse--find the lowest priority thing, send it to the top. Then the next lowest, etc. Except when that fails and it doesn't really send it to the top.
-
@Benjamin-Hall said in Ticket Prioritization Discussion:
Jira is the worst PoS at this. It shows like...4 things at a time (even on a big screen) and places things in order quite (seemingly) at random. Which means re-ordering stuff is an involved manual process that mostly has to be done in reverse--find the lowest priority thing, send it to the top. Then the next lowest, etc. Except when that fails and it doesn't really send it to the top.
Back when I used Jira for issue tracking, I didn't have that problem. I'm guessing that there's something misconfigured somewhere so that sorting criteria aren't getting properly passed down to the database or at least the data model layer. (OTOH, I've been very happily not using Jira for around 5 years and never administered it anyway.)
-
@dkf
He's using a board. Kanban boards allow arbitrary ordering, and issues just stick where you put them. However, it can be confusing when issues are comin in at the same time.If you simply go to list a view or the backlog (in an Agile board), you'll see twenty or so in a screen.
-
@Jaime I vaguely remember that we tried that briefly, and then disabled it again for some reason. (Several reasons, some of which were related to the fact that the project was being transferred to different ownership. I was happy to get out of there.)
-
@Benjamin-Hall said in Ticket Prioritization Discussion:
There are some things that have stagnated, but I think our "oldest in column" is roughly a month
Only a month? What kind of nirvana are you working in? Some of our issues are almost old enough to vote! (and I'd wish I was exaggerating
)
-
@robo2 said in Ticket Prioritization Discussion:
@Benjamin-Hall said in Ticket Prioritization Discussion:
There are some things that have stagnated, but I think our "oldest in column" is roughly a month
Only a month? What kind of nirvana are you working in? Some of our issues are almost old enough to vote! (and I'd wish I was exaggerating
)The entire project is only about a year old, so...
Looking at it in more detail, turns out I underestimated by a factor of 3. The oldest thing in Accepted has been there 3 months (91 days). But it currently has a negative total priority score, since it's gotten bypassed by future developments (a requested feature that turns out to not have been needed). We should probably remove that one.
There are several in the 70-85 day range...which are mostly internal stability issues. And that's what I was afraid of.
Options:
- I can bump internal stability up to the same as minor workflow (same value, just different impact label so I can keep them separate).
- Increase the value/range of the age column (maybe something like [days / 10], since they're really only a couple points behind the other non-high-priority features).
- Both #1 and #2.
- Something else...
-
@The_Quiet_One said in Ticket Prioritization Discussion:
I disagree with those saying "effort" shouldn't play a role at all. I think it's important to schedule tickets in such a way you get the most bang for the buck. If one week I do 5 important tickets versus 1, that is a significant difference.
It probably depends on your development / deployment cycle. If you're doing an X week sprint, then you might very well do those other 5 things because they'd all fit. But that's just using judgment and looking at the near term plan as a whole. It shouldn't really affect how important a particular ticket is on its own.
-
@Benjamin-Hall I think one of the most important aspects is getting management to buy into the idea that fixing bugs (of a certain priority) is more important than churning out new features.
The few projects that I've been in that did it right all had in common that feature work was delayed until all >= major issues were fixed. The minor issues were fixed when you were in that part of the code. And tech debt was on a separate list, and worked on during feature development (never let a manager decide on tech debt...).
Once your issue list gets over a certain threshold you might as well delete all old and/or minor issues. No reason to fool yourself anymore, you've proven that you will not fix them anyway.
-
@boomzilla said in Ticket Prioritization Discussion:
@The_Quiet_One said in Ticket Prioritization Discussion:
I disagree with those saying "effort" shouldn't play a role at all. I think it's important to schedule tickets in such a way you get the most bang for the buck. If one week I do 5 important tickets versus 1, that is a significant difference.
It probably depends on your development / deployment cycle. If you're doing an X week sprint, then you might very well do those other 5 things because they'd all fit. But that's just using judgment and looking at the near term plan as a whole. It shouldn't really affect how important a particular ticket is on its own.
A part of why I included it was to encourage us to have more consistent ticket sizes. Because our process has jammed hard in the past when we've gotten lazy about breaking features up into the smallest meaningful deliverable, so we've had these behemoths mixed in with smaller (usually defects). The behemoths absorb all the QA time, which means that the overall throughput/velocity drops like a rock. Basically, it's a disincentive to have the real big tickets (since all our "normal" ticket estimates are basically the same value and it's only the 2d and 1w tickets that are penalized).
Was it a good way of doing that? Probably not. But that was the intent.
-
@robo2 said in Ticket Prioritization Discussion:
I think one of the most important aspects is getting management to buy into the idea that fixing bugs (of a certain priority) is more important than churning out new features.
That's something that, thankfully, we have agreement on. Basically, that 20-point category is only defects, so any major issues happen first. And then if there's a choice between two equivalent-point things, the defect goes first. And if the defect count is edging up to the 15+ range, we prioritize those higher until it's down in comfortable territory and only the minor "well, the wording on this error message isn't perfect" or "that font should be a (slightly) different size" defects remain.
-
@Benjamin-Hall I'll stop posting in this thread, I'm getting jealous...
-
@robo2 said in Ticket Prioritization Discussion:
@Benjamin-Hall I'll stop posting in this thread, I'm getting jealous...
Yeah. For all the
I see, I have to continually remind myself that I'm lucky, that I've gotten a job where management is (relatively) sane and understanding and competent and where policies really are in place to try to do the right thing. Being really small (5-6 active devs, not counting the deployment guy or QA, about 40 total people in the company) helps with that.
