3 ms·

That is so familiar that I seriously wondered if we had crossed paths at a previous job. The only difference being our priority was the other way around P4 bein

That is so familiar that I seriously wondered if we had crossed paths at a previous job. The only difference being our priority was the other way around P4 being the highest. Basically all tickets would naturally migrate to P4. Eventually when someone started working on 'the wrong thing' another level was added. In my current job we use Jira and the backlog has things at the bottom which have been just added, things at the top which we thought were priorities at some point and a whole bunch of crap in the middle which is unordered. I keep thinking about some kind of system where people would rate the priority of one ticket against each other rather than against an arbitrary scale.

jschwartzi 6y ago
That’s the whole point of that backlog. The order should reflect the priority of everything relative to everything else. You drag stuff up above other stuff that is lower priority and part of everyone’s job is to groom that list so it reflects reality.
- VBprogrammer 6y ago
  While that may be true in theory in practice it is difficult. A big improvement would be if new things needed to be inserted into the backlog at an appropriate place but I don't know if it's possible to do that in Jira.
  - mumblemumble 6y ago
    This, I think, is exactly why everyone I know who is happy with their backlog management does it in an Excel spreadsheet or Google Sheets. I'm fine with ticketing systems for handling immediate work in progress. Which, incidentally, is what they're meant to be used for. Every time I've ever seen people try to juggle business priorities and long-term goals in a ticketing system, though, the end result has always struck me as being something of a failed experiment to develop a product that works well as both an ice cream topping and an engine lubricant.
travisjungroth 6y ago
That ticket comparison idea is awesome. You could have it for one person, or do it democratically. I bet there'd be circular comparisons (A>B>C>A) a surprising amount of the time. Not a huge deal, you could just show the pairings back again in a different order until they resolve.
- brantonb 6y ago
  I wrote a toy app when learning iOS that took the items in a todo list and showed you two at a time. You’d swipe the less important one off the screen. It built a hierarchy and you’d end up with the “most important” item to focus on. It remembered previous choices (or you could start over) to make finding the next item quickly, with just a few more choices. It connected with the Reminders app and the Wunderlist API. I wonder if I could revive it with more services…
ludston 6y ago
We've been doing that for a few years now. Basically we have two queues: The queue for escalated defects, and an ordered queue of about 10 prioritized enhancements that we've ordered based on what we think is most important comparatively. There is also a backlog of ideas/garbage work. It works fine, except that the product is complex and old enough (and the team has too few developers so) that the bug queue rarely gets to zero.

jschwartzi 6y ago

That’s the whole point of that backlog. The order should reflect the priority of everything relative to everything else. You drag stuff up above other stuff that is lower priority and part of everyone’s job is to groom that list so it reflects reality.

VBprogrammer 6y ago
While that may be true in theory in practice it is difficult. A big improvement would be if new things needed to be inserted into the backlog at an appropriate place but I don't know if it's possible to do that in Jira.
- mumblemumble 6y ago
  This, I think, is exactly why everyone I know who is happy with their backlog management does it in an Excel spreadsheet or Google Sheets. I'm fine with ticketing systems for handling immediate work in progress. Which, incidentally, is what they're meant to be used for. Every time I've ever seen people try to juggle business priorities and long-term goals in a ticketing system, though, the end result has always struck me as being something of a failed experiment to develop a product that works well as both an ice cream topping and an engine lubricant.

travisjungroth 6y ago

That ticket comparison idea is awesome. You could have it for one person, or do it democratically. I bet there'd be circular comparisons (A>B>C>A) a surprising amount of the time. Not a huge deal, you could just show the pairings back again in a different order until they resolve.

brantonb 6y ago
I wrote a toy app when learning iOS that took the items in a todo list and showed you two at a time. You’d swipe the less important one off the screen. It built a hierarchy and you’d end up with the “most important” item to focus on. It remembered previous choices (or you could start over) to make finding the next item quickly, with just a few more choices. It connected with the Reminders app and the Wunderlist API. I wonder if I could revive it with more services…

ludston 6y ago

We've been doing that for a few years now. Basically we have two queues: The queue for escalated defects, and an ordered queue of about 10 prioritized enhancements that we've ordered based on what we think is most important comparatively. There is also a backlog of ideas/garbage work. It works fine, except that the product is complex and old enough (and the team has too few developers so) that the bug queue rarely gets to zero.