Shape Up [1] (from basecamp) rejects the notion of backlogs essentially for this reason. We've leaned into adopting it without using basecamp software specifically and it's pretty refreshing.
What do you do when the queue overflows? Block work on backlog capacity? Drop the new item on the floor?
The problem is that people add things to the backlog during their ordinary work, so as you scale up the number of workers, the pressure on the queue increases.
That said, my experience in doing bug triage is that some large percentage of tickets are never going to be done. Those should just be dropped on the floor.
Yeah you drop the old ones. And then the insight is that nobody ever has time to process the backlog anyway so just drop the new ones instead and delete the backlog. If the work is important, it will come back up as a new request during cycle planning.
Comments
This explains why every JIRA backlog I've seen always grows until it becomes unwieldy.
I wonder if anyone here has experience with a fixed-size backlog for work tickets.
Shape Up [1] (from basecamp) rejects the notion of backlogs essentially for this reason. We've leaned into adopting it without using basecamp software specifically and it's pretty refreshing.
[1]: https://basecamp.com/shapeup
What do you do when the queue overflows? Block work on backlog capacity? Drop the new item on the floor?
The problem is that people add things to the backlog during their ordinary work, so as you scale up the number of workers, the pressure on the queue increases.
That said, my experience in doing bug triage is that some large percentage of tickets are never going to be done. Those should just be dropped on the floor.
Yeah you drop the old ones. And then the insight is that nobody ever has time to process the backlog anyway so just drop the new ones instead and delete the backlog. If the work is important, it will come back up as a new request during cycle planning.