Why backlogs are harmful, why they never shrink, and what to do instead §
Highlights §
- Backlogs never shrink. (View Highlight)
- Important tasks never go into the backlog. We create them, we work on them, and we ship them. (View Highlight)
- The truth is, we always know what task is most important, and we work on it until it’s done. Everything else is fluff. (View Highlight)
- Backlogs exist because they’re a great way to avoid difficult conversations and shift blame away from product to engineering. (View Highlight)
- it’s much easier to say “you’ll add it to the backlog,” than to spend an hour explaining why the suggestion is irrelevant. (View Highlight)
- product manager’s job is not to create as many tickets as possible but to delete as many as they can and avoid unnecessary work at all costs. (View Highlight)
- a product manager creating more tasks than its engineers can deliver is also producing waste. (View Highlight)
- The only way to make a backlog even more harmful is to require engineers to “refine” the tasks there. That way, you’ll be wasting time from product managers and engineers, (View Highlight)
- Do not maintain a backlog unless it’s the backlog for your next few weeks of work. (View Highlight)
- If you’d need more than two or three weeks to get rid of everything on your backlog, you’re planning too far ahead, at the wrong level of abstraction. (View Highlight)
- Everything further away than two or three works of work should go into a high-level roadmap. You should revisit that roadmap regularly, and product managers should share it with engineers and explain why each item is important (View Highlight)
- If a bug’s been in the backlog for more than three months, it’s already a feature. (View Highlight)