[HN Gopher] Why backlogs are useless, why they never shrink, and...
___________________________________________________________________
Why backlogs are useless, why they never shrink, and what to do
instead
Author : feross
Score : 24 points
Date : 2023-02-10 17:03 UTC (5 hours ago)
(HTM) web link (lucasfcosta.com)
(TXT) w3m dump (lucasfcosta.com)
| aka878 wrote:
| "Everything further away than two or three works of work should
| go into a high-level roadmap." - this is supposed to be a
| solution, moving text from one place to another. People worry too
| much about minuscule organizational matters.
| ben7799 wrote:
| My experience with the backlog is somewhat different than the
| authors.
|
| Mostly my experience is QA opens bugs and engineering opens
| tickets for tech debt, refactoring, performance improvements,
| reliability improvements, etc..
|
| The PM opens new feature tickets, prioritizes those, and pushes
| the bugs & tech debt tickets to the backlog until their back is
| absolutely against the wall.
|
| Every so often a VP or someone will come in and call PM to the
| carpet and engineering gets to do a "quality release" where bugs
| are fixed and tech debt is cleaned up. But then things will
| regress again to PM just making sure new features are ticked off
| at the expense of other tasks that languish in the backlog.
| kyriakos wrote:
| You described my situation exactly as it is. Is this a common
| case for product centric companies? Is it less prevalent in
| tech companies?
| Casteil wrote:
| I'd say it's common for all companies that create software.
| in9 wrote:
| Well refactoring should never be a ticket it self. It should be
| done in order to facilitate, even enable, the construction of a
| new feature. Perfomance should be a feature request, IMO. If
| the user can't use a feature, or se a result, due to
| performance, the should be requested by the PM it self, no?
| Reliability as well, should fall under the same logic.
| Jtsummers wrote:
| * * *
| quantified wrote:
| Backlogs should be a bounded queue, not unbounded. You need
| something that's longer than 5 people's collective short term
| memory. But as soon as it has items that are "too old" * "too
| minor", there's a great chance they start becoming obsoleted,
| recognized as worthless, etc.
| 9dev wrote:
| The neat thing about those items is that you'll never get to
| them anyway. We sort our backlog by priority constantly, and
| all of the junk, old issues, or irrelevant bugs simply get
| shifted to the bottom over time, with more important stuff
| sorting itself up. Nevertheless, if I come across something
| I've documented before, I don't need to file the same issue
| over and over again; if multiple customers request the same
| stupid thing over time, you'll have a track record and maybe
| notice there's a need for something; and finally, a long
| backlog gives lots of opportunities to onboard new people with
| long-standing, but minor issues.
| JohnFen wrote:
| Tough to do, though, because there can be genuinely important
| stuff in the backlog that shouldn't be forgotten, but for
| various reasons won't be tackled anytime in even the medium
| term future.
| flappyeagle wrote:
| I mean, most ticket systems let you filter by date created or
| updated... seems like you can ignore stuff that's older than x
| months.
| quantified wrote:
| Not always. You get into an X month crunch because your
| salespeople sold far far ahead, some old things are still
| relevant. But date's a good proxy.
|
| The older it is, the more likely a newer ticket was created
| for it as well to be sure
| rcme wrote:
| Who cares about how long the backlog is? A queue that grows
| indefinitely is the type of problem bothers the analytic brain of
| a programmer. But as the author says, the queue does service a
| purpose:
|
| > Backlogs exist because they're a great way to avoid difficult
| conversations and shift blame away from product to engineering.
|
| > Whenever anyone asks a product manager for a shiny new feature,
| for example, it's much easier to say "you'll add it to the
| backlog," than to spend an hour explaining why the suggestion is
| irrelevant.
|
| I think this tone is a little condescending, but the broader
| point is true: PMs, QAs, and others in the process want to feel
| like their voices are heard. The backlog gives them a place to
| express their voice. And of course, not all of the tickets
| immediately enter the backlog. It's a place to gently lay down
| bad or low priority ideas without insulting the person who filed
| the ticket.
| dtx1 wrote:
| > It's a place to gently lay down bad or low priority ideas
| without insulting the person who filed the ticket.
|
| I mean yes, you can use the Backlog for that, as a sort of
| idiot pacifier but that's basically the worst way to deal with
| that. Preferably you would find ways to educate those people on
| why their Ideas are bad or low priority so they can learn to
| give you better input.
| rcme wrote:
| > I mean yes, you can use the Backlog for that, as a sort of
| idiot pacifier
|
| Again, that's really condescending. PMs will have ideas. Some
| will be good, some will be bad. QAs will file bugs. Some will
| be good. Some will be bad. The backlog reflects the bad
| ideas. There's nothing wrong with that. If you feel like your
| QAs and PMs are idiots, i.e. you're the smartest person in
| the room, then perhaps you're standing in the wrong room?
| Dylan16807 wrote:
| If you don't give feedback to bad ideas, you're treating
| them as if they're unable to improve. Maybe "idiot" isn't
| the exact word, but it's close.
|
| The other poster isn't being condescending, they're calling
| _you_ condescending.
| dtx1 wrote:
| While I appreciate my posts being defended by other
| people, my intention was not to call anyone
| condescending. I merely wanted to suggest that any agile
| organisation should strive to learn from each other and
| find better ways to deal with bad/low priority ideas than
| make people feel warm and fuzzy inside while ignoring
| their input.
|
| Though the use of the wording "idiot pacifier" was
| perhaps a bit too strong and distracted from the intended
| meaning.
| rcme wrote:
| But who is the arbiter of good ideas? This is kind of a
| precision / recall problem. Do you want every idea
| offered to be good, or do you want to get every good idea
| out of your team, even if that means tolerating some bad
| ideas? That's not to say we shouldn't strive to have
| better ideas overall, but the ideation process itself is
| valuable, even if it's unlikely to produce solely good
| ideas.
| dtx1 wrote:
| That's obviously all context dependent and in any
| ideation/brainstorming process it's valuable to have a
| free flow of ideas but there's a necessary filtering
| process afterwards. David Allen writes in Detail about
| this in Getting Things Done, specifically in the chapters
| of the natural planning process.
|
| Now with regards to the backlog, if a team can develop
| common criteria for high value/high priority tasks and
| learn to reject low value/low priority tasks than they
| can more effectively manage their backlog and time.
| Dylan16807 wrote:
| "Tolerating" and "keeping around forever next to the good
| ideas" are different things. You can say no without
| stifling future input.
| NoZebra120vClip wrote:
| I'm not an SWE and I don't work with them, but I have a backlog
| of a different type. I'm not sure it strictly qualifies as
| "backlog" for what the article's referring to. My backlog
| involves tasks that are blocked waiting on a coworker to take
| action.
|
| Therefore I can generate a personal backlog at a certain rate,
| and the requests are tossed into a queue that's common to the
| rest of my team, and waits for a senior member to investigate and
| sign off and direct us for the next step.
|
| My backlog grows as a certain percentage of the tasks I take on
| in a given week, and so it's proportional to the volume of
| incoming tasks in general. The backlog is cleared at a rate based
| on how much bandwidth the seniors have to process them, and
| there's only about 2 who are responsible for this aspect
| currently.
|
| So my backlog tends to grow and shrink, and it really shocked
| some other coworkers when they found out how deep it was!
|
| Sometimes the only way to shrink my backlog significantly is for
| me to stop working altogether until the seniors have a chance to
| catch up. I am, by far, the most prolific generator of requests
| compared to my coworkers, and I'm not sure whether that is a
| function of the percentage of tasks I take on, or if I have a
| much higher rate of flagging stuff than all of the rest put
| together.
|
| Anyway, there's no way for me to avoid generating this backlog.
| It's just a fact of life. So we deal with it. It's overall a good
| thing that we catch these things and filter them properly, even
| if it delays resolution by a few days apiece.
| aschearer wrote:
| 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 wrote:
| 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.
| __derek__ wrote:
| Problem: bathtub analogy
|
| Possible solution: theory of constraints
| mdmglr wrote:
| Foolish to generalize backlog's as a useless technique because
| the author has had bad working experience from them.
|
| As the author found, if you tune your backlog processes they can
| be quite helpful. The only part of agile I use today is the
| backlog. If you keep engineering details to a minimum (or limited
| until it reaches the top), items brief and to the point, and have
| it groomed regularly so it is always bounded to a size it works
| well.
|
| I find that on multi year projects you can "archive" the bottom
| 20-50% of tasks and no one will care. So it cleans itself up
| quite nicely.
| JohnFen wrote:
| True. Backlogs are one of several things that people think of
| as "agile", but have been around since forever. Although prior
| to agile, we called them "todo lists", but they were dealt with
| pretty much identically.
| [deleted]
| klyrs wrote:
| One utility I've found for backlogs is to document work that
| isn't getting done. When managers fight over who gets new
| headcount, such preparation helps. Then, when a new employee
| arrives sit down with the list and work out a priority -- tasks
| that are relatively easy and expose them to the codebase are best
| done first, documentation/test coverage projects are great too
| because they often require collaboration with the original author
| which helps break the ice.
| bob1029 wrote:
| GitHub gave us an eternal backlog by default. Anything we didn't
| want to ship got closed with some special label affixed to it.
|
| There's no reason it should ever shrink in this kind of setup.
| The careful open/close visibility separation throughout seems to
| keep things at ease. We are almost at 20k closed issues, so I
| feel like any cracks would have formed by now.
|
| The process for searching the "backlog" is about as simple as you
| might think. All you have to do is constrain for 2 things. Moving
| something from backlog to triage is literally 1 click.
|
| Depending on how organized your software factory is, this stuff
| can become pretty magical.
___________________________________________________________________
(page generated 2023-02-10 23:01 UTC)