interesting read, it resonates deeply as we’re struggeling with long backlogs.
But for some reasons.
lets say, you’re a developer and manufacturer of measurement devices of highest precision.
Your dev department has created tech dept without end over years and years.
Now at the same time customers had many requests and wishes what to optimize or change.
only within the last 5years parts of the company (software devs) started using kind of agile methods and tools like jira to establish a means for handling tickets and organizing them on boards.
So, how do you handle these things that definately are worth to work on, but the teams still can only handle it over years ?
Currently I established extra columns / states to represent the ideas holding and preparing for backlog issues,
You will have other technical debt. You will have removed technical debt that makes some other ticket obsolete. You will have removed functionality that there are improvement tickets for. You will have improved something in another way than described 5 years ago.
Anything in your PBL is a snapshot of your current understanding. If your understanding of what matters to your customers and the business remains the same for a few years, you can keep those tickets.
But in my experience, that never happens.
It makes sense to store a snapshot somewhere of the biggest struggles of your customers, but that could literally be a single google doc and then if you run out of work, you could take a look at it to see if there are things you could be picking up.
The challenge isn't, keeping everything what we could work on, as that's a moving target. You will never reach those 5 year tickets.
It's much more important to have focus and remove noise, as that will ensure we are doing what's most valuable. There are always infinite things we could end up doing but never end up doing.
The struggles that matter will come back. And if they don't, are they really a struggle?
I fully agree but have one question. One of the things i sometimes struggle with is how to capture “ideas” vs creating an actual feature backlog. Any tips ?
Two thumbs up on this post. The Burn the Backlog movement is real. I like the milk analogy a lot, so many facets to that beyond just product dev, but I digress. One of the insights I drew from my XP 2024 Experience Report was Product Backlogs are generally internally focused and we can debate the value of that another time. Extra Features are waste. Backlogs = invisible inventory (milk at least you can see it, taste it and smell it), and it leads to queues (we know what that means).
interesting read, it resonates deeply as we’re struggeling with long backlogs.
But for some reasons.
lets say, you’re a developer and manufacturer of measurement devices of highest precision.
Your dev department has created tech dept without end over years and years.
Now at the same time customers had many requests and wishes what to optimize or change.
only within the last 5years parts of the company (software devs) started using kind of agile methods and tools like jira to establish a means for handling tickets and organizing them on boards.
So, how do you handle these things that definately are worth to work on, but the teams still can only handle it over years ?
Currently I established extra columns / states to represent the ideas holding and preparing for backlog issues,
but isnt this just a prolonged prod backlog ?
Every step you take, shapes the next steps.
You will have other technical debt. You will have removed technical debt that makes some other ticket obsolete. You will have removed functionality that there are improvement tickets for. You will have improved something in another way than described 5 years ago.
Anything in your PBL is a snapshot of your current understanding. If your understanding of what matters to your customers and the business remains the same for a few years, you can keep those tickets.
But in my experience, that never happens.
It makes sense to store a snapshot somewhere of the biggest struggles of your customers, but that could literally be a single google doc and then if you run out of work, you could take a look at it to see if there are things you could be picking up.
The challenge isn't, keeping everything what we could work on, as that's a moving target. You will never reach those 5 year tickets.
It's much more important to have focus and remove noise, as that will ensure we are doing what's most valuable. There are always infinite things we could end up doing but never end up doing.
The struggles that matter will come back. And if they don't, are they really a struggle?
I fully agree but have one question. One of the things i sometimes struggle with is how to capture “ideas” vs creating an actual feature backlog. Any tips ?
The weight of unexecuted ideas weighs much heavier than the ideas you miss by not storing them.
Good ideas come back, naturally.
The moment you write all your ideas down, your good ideas will drown in the noise of bad ideas.
If you do keep a list, keep it in a personal google doc and it should be short.
Ideas are easy to come by, there is no shortage of good ideas.
Two thumbs up on this post. The Burn the Backlog movement is real. I like the milk analogy a lot, so many facets to that beyond just product dev, but I digress. One of the insights I drew from my XP 2024 Experience Report was Product Backlogs are generally internally focused and we can debate the value of that another time. Extra Features are waste. Backlogs = invisible inventory (milk at least you can see it, taste it and smell it), and it leads to queues (we know what that means).
I learned this lesson with baggage that I had been carrying more multiple years. It was incredibly freeing to delete it and start fresh.