The Backlog vs the Bucket.

Here’s an idea for thinking differently about Backlog.

Most of us have long understood that backlog content should be stacked by priority, with next To Do at the top.

(You pull a Scrum backlog off the top. Or in our Kanban case, we move them to the right of the column, nearer to Doing.)


Not quite as many understood that the quality of the items should vary from Clear/Fine at the top to Vague/Coarse at the bottom: invest in finely granulating the work and clearly articulating it only for the work coming soon. Making it all Clear/Fine is waste.


I was discussing today on another post about emptying out Backlogs when they get too much in them, and starting afresh: Backlog Bankruptcy.

I can see how it could come to that. The info packrat in me can’t bear to throw it away, so I’d throw it in a Bucket, so we can riffle through it from time to time (or at least believe that we will).


But before it gets that bad, I think the situation can be helped by combining both concepts. What if we tell ourselves that only the top of the stack is the Backlog, kept clear and fine, and the rest of the stack is the Bucket, vague as to priority and information.


Then the Backlog task looks smaller, and the information is still kept together in one place. The boundary between the two, the Backlog and the Bucket, is fluid and fuzzy, as it should be in the real world.

E.g. My inbox is effectively infinite. I’ve no idea how many emails are in there. Anything unread is The Backlog. Anything read, or unread and over a month old, is The Bucket. They are there if I need to search, all in one place.