4 ms·

I like the idea but there are trade offs - Risk of too much discussion on exact ordering. I think to my uses of graphical programming languages vs text and ha

by epage 7y ago

I like the idea but there are trade offs - Risk of too much discussion on exact ordering. I think to my uses of graphical programming languages vs text and having infinite places to put wires made me waste more time on perfecting it than the coarseness of text. - Sometimes there is not clear priority between multiple tasks - Sometimes you want to think locally. I might be looking at a ticket and I'd like to know the general bucket it is in without having to look at it in context of the entire table. I might also want to triage it and put it in a bucket without trying worrying about the exact order. I think a potential is to combine the two. You define discrete priorities and have dividing lines in the UX. The UX can let you drag between buckets or even order within a bucket.

VBprogrammer 7y ago
I've considered whether a hot or not type system could be used to rate the priority of bugs / tickets. It would present a summary of two tickets and make implications based on which one the user said was more important to order the whole backlog. I'm sure there is a fundamental flaw somewhere but I like the concept. My main issue with allowing people to define the ordering is that, in my experience, enevitably you have some stuff at the top, some stuff in the middle and a big mostly unordered heap in the middle.
mumblemumble 7y ago
This is one of those spots where I think that Scrum gets things right. Having the ticket priority ultimately belong to a single person (the product owner) sets up a pretty decent incentive structure. It makes it easy for that person to figure out on their own exactly how precise they need to be, and where the precision is needed, in order to get their job done. When I see over-polishing happening in the wild, it tends to be in response to "too many cooks in the kitchen" type situations. Well, that or procrastination.

by epage 7y ago

VBprogrammer 7y ago

I've considered whether a hot or not type system could be used to rate the priority of bugs / tickets. It would present a summary of two tickets and make implications based on which one the user said was more important to order the whole backlog. I'm sure there is a fundamental flaw somewhere but I like the concept. My main issue with allowing people to define the ordering is that, in my experience, enevitably you have some stuff at the top, some stuff in the middle and a big mostly unordered heap in the middle.

mumblemumble 7y ago

This is one of those spots where I think that Scrum gets things right. Having the ticket priority ultimately belong to a single person (the product owner) sets up a pretty decent incentive structure. It makes it easy for that person to figure out on their own exactly how precise they need to be, and where the precision is needed, in order to get their job done. When I see over-polishing happening in the wild, it tends to be in response to "too many cooks in the kitchen" type situations. Well, that or procrastination.