Nice, this highlights a lot of issues I’ve seen with teams and crazy bug systems.
One difference I had from the article is that I actually find marking tickets with priority and types (like bug / enhancement etc) useful, but for a different audience.
When I’m working on planning / strategy, aka in Product Manager mode, I like to be able to review what is still remaining in different buckets and adjust priority and do scenario planning. Maybe it’s worth closing a whole bunch of low priority bugs before moving on. Often the priority changes over time and gets adjusted as we see what came in. Having a place to track that info on the ticket keeps me from moving to doing planning in a spreadsheet.
When I’m in developer mode, I agree - I don’t want to have to think about what the priority of a critical feature improvement is vs a low priority bug. I want to pick off the top of the stack and flow with confidence.
I often am working in both roles on team projects and use this technique even when working alone.
In my experience where things get weird is when the product planning metadata is required to be understood in real-time by all roles on the team. You can keep all that metadata around and still have a single prioritized backlog.
Maybe Jira could be improved by showing different metadata for different modes... but even writing that out sounds like a new configuration nightmare!
One difference I had from the article is that I actually find marking tickets with priority and types (like bug / enhancement etc) useful, but for a different audience.
When I’m working on planning / strategy, aka in Product Manager mode, I like to be able to review what is still remaining in different buckets and adjust priority and do scenario planning. Maybe it’s worth closing a whole bunch of low priority bugs before moving on. Often the priority changes over time and gets adjusted as we see what came in. Having a place to track that info on the ticket keeps me from moving to doing planning in a spreadsheet.
When I’m in developer mode, I agree - I don’t want to have to think about what the priority of a critical feature improvement is vs a low priority bug. I want to pick off the top of the stack and flow with confidence.
I often am working in both roles on team projects and use this technique even when working alone.
In my experience where things get weird is when the product planning metadata is required to be understood in real-time by all roles on the team. You can keep all that metadata around and still have a single prioritized backlog.
Maybe Jira could be improved by showing different metadata for different modes... but even writing that out sounds like a new configuration nightmare!