3 ms·

I guess no one would click if the title was, "Why I don't like backlogs"? N=1 but I appreciate having an unbounded backlog, knowing that the various things I co

I guess no one would click if the title was, "Why I don't like backlogs"? N=1 but I appreciate having an unbounded backlog, knowing that the various things I come across are written down _somewhere_. It's the nature of the business that they always grow and some work never quite makes it to the front of the queue, so what? > That’s what backlogs are: a bunch of unimportant tasks that we’ll eventually get to, but not today. Not in my experience. At least I disagree with "unimportant." > The truth is, we always know what task is most important, and we work on it until it’s done. Again, not in my experience. There's been plenty of times I've reached into the backlog rather than go idle. Fundamentally, in my experience there are lots of little feature improvements and bugs you come across that are worth documenting. I believe the issue tracker is the right place. If you don't document these things they'll soon be forgetten -- what a waste!

a_e_k 4y ago
I also like to dig through the backlog when doing a major refactor or a large feature. I'll look for related things that might help inform the design. It's surprising how often you find cases where we couldn't do A, because it depended on B which we didn't have back then and it would have been too much work to do B just to get A, so A just gets backlogged. But now that B is finally getting funded, if we do B right, we can let A come along for the ride almost for free. Then a whole bunch of related things like that can get cleared from the backlog all in one fell swoop.
- nmstoker 4y ago
  That kind of finding is particularly satisfying. The other time it's good to dip into the backlog is when the problem has become more serious due to shifts in usage patterns meaning the impact now justifies the work when it may have been borderline before.
happymellon 4y ago
Also, sometimes it is hard to either get something off my mind or to get someone else to move on from "really important to them" item. The backlog is a great place to write it down so my brain doesn't keep bringing it up.
oweiler 4y ago
That's exactly how we use the backlog: Whenever we come across things which could be improved, we create a ticket for it. That could be UX improvement, ideas to speed up the CI pipeline, or general code improvements which take more than an hour max. Each sprint one person (we cycle though) can use 20% of his time to do these tasks (we call them greenkeeping). Works very well so far.
throwbadubadu 4y ago
What a strange article, indeed. I do dislike what most bigger companies make out of agile, but usually sane people keep agile big co bs at a reasonable level. But backlogs? They are useful, they have the most important tasks, important also to remember corner case issues and prioritize tasks, given the right circumstances they also shrink. And we mostly take stuff from the backlog... His truth about "we always know what task is most important"... eerm, often, but must admit sometimes not, and sometimes good to align with the team and prioritize?!? And the "what do to else" is also cute: don't do backlogs unless you do it right (or what I believe is may favourite "right").. sorry full disagree and full lol. Would more question my workplace given something the author describes, instead of telling the internet how to do backlogs (:
stuntkite 4y ago
I find that backlog items get reframed into other stuff too. I like having a history of them is an itemized list of things that lead to decisions. Is the only point to have a list of your absolute decisions and context that lead to the things included current product? Like some sort of psychotic performative minimalism? A lot of times a decision is to not do something at that time. In my experience, the most important things involved in building a software product is what you decide not to do. The backlog is a knowledge base of how those decisions are made. They can be archived as needed. Decision points can be made referencing them. A year or three later when the same problem crops up, sometimes under a different name, you've got information about it. Maybe it's time. So now you have that knowledge sitting there to help new decisions.

a_e_k 4y ago

I also like to dig through the backlog when doing a major refactor or a large feature. I'll look for related things that might help inform the design. It's surprising how often you find cases where we couldn't do A, because it depended on B which we didn't have back then and it would have been too much work to do B just to get A, so A just gets backlogged. But now that B is finally getting funded, if we do B right, we can let A come along for the ride almost for free. Then a whole bunch of related things like that can get cleared from the backlog all in one fell swoop.

nmstoker 4y ago
That kind of finding is particularly satisfying. The other time it's good to dip into the backlog is when the problem has become more serious due to shifts in usage patterns meaning the impact now justifies the work when it may have been borderline before.

happymellon 4y ago

Also, sometimes it is hard to either get something off my mind or to get someone else to move on from "really important to them" item. The backlog is a great place to write it down so my brain doesn't keep bringing it up.

oweiler 4y ago

That's exactly how we use the backlog: Whenever we come across things which could be improved, we create a ticket for it. That could be UX improvement, ideas to speed up the CI pipeline, or general code improvements which take more than an hour max. Each sprint one person (we cycle though) can use 20% of his time to do these tasks (we call them greenkeeping). Works very well so far.

throwbadubadu 4y ago

What a strange article, indeed. I do dislike what most bigger companies make out of agile, but usually sane people keep agile big co bs at a reasonable level. But backlogs? They are useful, they have the most important tasks, important also to remember corner case issues and prioritize tasks, given the right circumstances they also shrink. And we mostly take stuff from the backlog... His truth about "we always know what task is most important"... eerm, often, but must admit sometimes not, and sometimes good to align with the team and prioritize?!? And the "what do to else" is also cute: don't do backlogs unless you do it right (or what I believe is may favourite "right").. sorry full disagree and full lol. Would more question my workplace given something the author describes, instead of telling the internet how to do backlogs (:

stuntkite 4y ago

I find that backlog items get reframed into other stuff too. I like having a history of them is an itemized list of things that lead to decisions. Is the only point to have a list of your absolute decisions and context that lead to the things included current product? Like some sort of psychotic performative minimalism? A lot of times a decision is to not do something at that time. In my experience, the most important things involved in building a software product is what you decide not to do. The backlog is a knowledge base of how those decisions are made. They can be archived as needed. Decision points can be made referencing them. A year or three later when the same problem crops up, sometimes under a different name, you've got information about it. Maybe it's time. So now you have that knowledge sitting there to help new decisions.