6 ms·

I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer an

I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer any questions people have here.

po 9y ago
Super interesting points here. You mentioned that the real-world Kanban board forces you to empty slots to make room... I've never seen that in any of the software Kanban-style systems have you? I've played around (in spreadsheets and basic apps) with trying to create systems that scaled available slots to team size as a way to force correct granularity.
- apenwarr 9y ago
  No, I've never seen it enforced by tools. Physical (index cards) kanban boards have an implicit space limit though, and this is one of the too-seldom-acknowledged reasons why they work as well as they do. Unfortunately the software clones of physical kanban boards copied the unnecessary part (visual appearance of index cards) and not the necessary part (limited space at each phase).
  - WorldMaker 9y ago
    Rally lets you set card limits in each column, though in practice that always seemed too easy to change (just add a couple more to the limit; just "temporarily" turn off the limit) to be entirely beneficial.
- yalooze 9y ago
  Are you talking about work-in-progress (WIP) limits? I've seen tools enforce this so you can't pull another story into the current list. Other tools let you pull but highlight the fact that you're going over the WIP limits by making the whole column eg. red. Or do you mean something else?
- benji-york 9y ago
  I've used LeanKit's Kanban board to enforce per-lane WIP limits. It works quite well and is, in my opinion, one of the most important aspects of using Kanban boards for software development.
jasode 9y ago
>its massive length but wasn’t able to make it shorter It's always possible to make it shorter to help communicate a main idea. (However, it does takes extra effort to extract the essence of a long piece.[1]) Your essay is ~15,000 words and desperately needs a short "elevator pitch" of its main points. I'm a very verbose writer so when I think others' writing is verbose, it means everybody is going to drown in the text. Here's my summary of what I think you're trying to say: 1: There psychological problems with deadlines and large bug lists that cause counterproductive results 2: I discuss 2 psychological "tricks" in software development to counteract the unwanted behavior 2.a: Estimate software by abstract units such as "points" instead of concrete units such as "time/hours/weeks". The abstract units bypass the human biases that lead to bad estimates. Use the points to determine "relative" sizes of each "story". (E.g. Developers vote to converge on the "size" of each story point.) The last step is to multiply the points by a unit of time to derive a finish date. 2.b: Do not have a big global list of bugs to burn down. The size would be overwhelming and demoralizing to teams. Instead, triage bugs into smaller "hot lists" so they "see" a smaller manageable queue to work on. Also, measuring bug fix times will eventually let you derive an "average bug size" that's reasonably accurate The tldr would be something like "Here are 2 counterproductive management techniques with setting deadlines and assigning bug fix work -- and here are 2 ways to counteract it with management ideas that take advantage of human psychology." Somebody else can wordsmith it better than I can but that's what I think your essay is basically about. The 15000 words are mostly examples or background ideas leading up to your recommendations (SLO vs SLA, Tesla, what I like don't like about Agile, Kanban, etc). I recommend that you put your strongest main points at the very top to give your readers the mental scaffolding to hang the rest of your 15000 words on. [1] "I would have written a shorter letter, but I did not have the time." -- Blaise Pascal : https://en.wikiquote.org/wiki/Blaise_Pascal https://en.wikiquote.org/wiki/Blaise_Pascal
- systematical 9y ago
  TL;DR thanks. ++good writing advice
- apenwarr 9y ago
  I know what you mean, and in general I try to follow that advice. In the particular case of project management though, I'm frustrated by the huge amount of too-short and contradictory advice floating around on the Internet; adding one more unjustified summary to the pile doesn't help. So I think the extra details are important. And when you have that many details, the tangential expository fluff helps keep it interesting. I hope. This is also why I didn't summarize everything at the top: that would encourage people to just read the top and stop there. They can do that with project management advice anywhere on the Internet. There's a place for that, but there's plenty of it already. At least it's shorter than a book. :)
ndh2 9y ago
First, thank you very much for the write-up, I sure found it interesting as well as entertaining. When using bug trackers, I find the most frustrating aspect is the "non-linearity" of the workflow. By that I mean, how do I answer the question "What am I supposed to do next?". You can sort by project, or by priority, but what I typically end up with is a list of items that I already looked at a dozen times. And even though I don't want to look at them a second time, I haven't found a way for a bug tracker to do that for me. Ideally, I would want to look at each task at most two times: Once for triaging, and once for working on it. That's it. So the way I understand it, you're trying to address this, at least partially. A task starts out as untriaged, then you tag it as triaged, and that means you only had to look at it once for triaging. Which is great, because it's a linear workflow. Some tasks are obviously critical, and will end up in the next open release milestone. Some belong to a feature that is not released yet. But what about the stuff that ends up in the backlog? These smallish, nagging bugs that are not super-critical. That is the big, ugly pile that keeps growing and growing. How do you keep that big pile manageable? Ideally, that pile shouldn't become big in the first place, but how do you prevent that from happening?
- apenwarr 9y ago
  The way I like to do it is to keep multiple backlogs, broken down roughly by feature group (ie. groups of things that might eventually become a milestone or story of their own). Then when I decide to prioritize a given story, I can go to the relevant backlog and re-triage only the bugs in there, which should hopefully be a relatively manageable number. Another benefit of sub-categorizing this way is that it makes it easier to resolve bugs as duplicates. When a new bug is filed, it's hard to see that it's a duplicate when you're comparing it against 10000 other bugs, but it's easier when you're comparing it against only 100 other bugs in the same category. I doubt you'll ever be able to get it down to "at most twice." But it needs to be much easier than ever resotring to "looking through the whole list."
platform 9y ago
Agile is meant to be used for non-software delivery projects as well. In your view, with the parts you crossed out (including the physiological/motivational structures)-- would Agile still be widely applicable outside of the software-oriented projects? Couple of, say, hypothetical examples, perhaps for non-software projects -- developing & submitting scientific grant application -- organizing a non-trivial longitudinal survey -- looking for college for kids -- designing a motorcycle with unique frame/engine layout -- planning and shooting a movie
- apenwarr 9y ago
  In my opinion (and you should take it as an opinion :)), the "good parts" of Agile are the same for both software and non-software projects. Estimation, strict prioritization, and (automated) progress tracking are the keys to any successful project management.
bvrmn 9y ago
Wonderful article, read it like a blockbuster with a constants clicking in my brain. Every time I tried to impose some sort of sprints for myself and the team it always end in Friday superdense coding with a half task moving to the next sprint. Thank you for a great argumentation why precise estimation is a bullshit bingo, I tried to show to PM's that only a steepness of slope is important and managers can plan work without exact dev-hours, but without much success, your explanation is clear and easy to understand.
voxl 9y ago
I disagree strongly with your take on story points: First, if story points are an indirect measure of time, then the "psychological game" you're playing will be immediately revealed if your engineers are as smart as claimed. There is no reason for me to point something a 2 over a 3 unless you're measuring the time it takes to deliver software based off those measurements. On the opposite end of the spectrum, my confidence in whether a story is an 8 or a 13 becomes significantly weaker as the numbers get bigger. Using numbers, specifically, is a hint that whomever is handling process just wants to predict when the project will be done. Numbers trick you into thinking they can be added, margins of error are not additive. My go-to question in these situations is why don't we just estimate with abstract sizes? (Small, Medium, Large, etc) Surprisingly I'm often met with resistance. Second, if story points are not an indirect measure of time, then why are you pointing stories? What does the pointing gain your team other than fluff? If you say it's for prioritization then you're just invalidating the premise and we're back to an indirect measure of time. Finally, I have not seen, and you have not presented, evidence that engineers are good at estimating. In fact all that I have read seems to indicate the exact opposite, that engineers are very bad at estimating (in fact that they are largely too optimistic). One could argue that this can be trained, or that you'll get better at estimating as you gain more experience. Which I will concede that you will get faster and better at estimating and implementing the same exact feature, but that is not what we do. We implement new features, things we likely haven't done before.
- lostcolony 9y ago
  So what? Even though engineers realize that, as long as you're talking abstract points, and not holding me to a deadline, I have no reason to modify my estimate. And even if I -do- modify my estimate, as long as I continue with that new estimation mechanism for some period of time, velocity will change accordingly and the PO can -still- make accurate determinations of when something will be delivered. If I consistently under or over estimate things, I am predictable. The more constistent I am, the less time it takes to be uniform, and thus predictable. By not pinning it to time, the PO can determine the average velocity, the current estimations, and have a largely accurate idea of when things will be done. The only time this ever breaks is when I have a reason to change my estimation strategy, which only happens when you start applying incentives for me to change it. Every time my incentives change, my estimates will change; don't change my incentives. Don't give me a date or a deadline. We could do this with hours except hours actually translate directly to time. From them I can determine when you think I should be done and thus the implied goal; points I can't. Because of that, I have incentive to overestimate when it comes to hours, to give myself extra time 'just in case'. With points I don't; they don't imply an end time. Even if the PO's estimates are wrong, they can't get onto me, because I never had a due date. Because of that, my estimates tend to be consistent (even if inaccurate), and consistency = predictability. That's the goal, making it predictable when things will be finished (within a given tolerance; hours never give us that). Whether points are big, or small, the PO can determine "This team has an average velocity of 20 points, whatever size those points may be. That means I can expect around 20 points per sprint in terms of stories. I have 50 points I need to get done for this next release, that means I can expect it in three more sprints". All done without the engineers ever having a goal they are trying to make, no incentive to change their estimates, and literally the best predictability (not accuracy; you don't need accuracy) you can achieve, which, it turns out, is actually pretty damn good in practice. I think you're missing the fact that points only matter relative to each other. There is no absolute meaning. The author hints at that but I don't think is explicit about it, assuming you already know that. As such, a team tends to be consistent with them, even if not objectively accurate. And their mistakes average out into something predictable, even if not accurate. Because there is no incentive, conscious or unconscious, to massage it. Some people -do- decide to use t-shirt sizes for sizing, rather than points. It still works. This is generally equivalent to 3, 5, and 8 using points (fibonacci). Most people who use points say anything less than a 3 is wrong (make it a three), and anything larger than an 8 should be broken up because otherwise it's difficult to estimate (with -maybe- a 13). So use whichever you like. S, M, L, and maybe XL, if you want to map to four options, as you have with points. Though you need a way to aggregate them to determine a velocity; how many S = 1M, etc. That's why people tend to use points. Basically, the author said, flat out, it's a psychology game. AND IT IS. What a PO needs from a dev is consistency in how they estimate, not accuracy. From that you can measure the actual work completed over time, and get a measure of velocity, which can be used to accurately predict the delivery of future stories, within a pretty good tolerance. Ensure the psychology for that consistency is there. Points are part of it. No goals, milestones, deadlines, etc, are part of it.
mixmastamyk 9y ago
Nice work. It should be three blog posts/chapters however.
GFischer 9y ago
Very interesting article, thanks for writing it and sharing it, I forwarded it to my PM :) . I do think it could have been edited without losing your favourite bits though :)
gingerlime 9y ago
Amazing stuff. It was a real pleasure to read. Despite its length I couldn't get myself to skip ahead or skim. We're now in the process of switching to a structure similar to Basecamp's 6-week cycles[0]. And those cycles obviously do have a deadline. However, I would still say this kind of deadline is better than your typical one for a couple of reasons: 1. The team is self-managing. Typically the team was involved in the pitch process for the project, so they have vested interest in getting this done. I think this is key to avoiding the Student problem. It's no longer an assignment dropped from above, but something you are keen to push forward. 2. The cycle is 6 weeks rather than a sprint of 2... So this feels more like a slower-pace mini-marathon. And the team has autonomy to drop features or make adjustments. I admit that's a weaker argument for it than the one above. I wonder what's your take on this? [0] https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9cae https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9c...
Joeri 9y ago
I thought this was very insightful and spot on for the most part, but I had one remark. I object to the notion that it’s ok for bug ingress rate to be higher than bug egress. For me that’s symptomatic of underlying problems. Either (A) those bugs are on important features, and the team is favoring novelty over functionality by prioritizing new feature dev over feature maintenance, or (B) the broken features are unimportant and the team is failing to weed out irrelevant functionality from their codebase (it is important to remove features while you add them to not get in a zero-progress situation, unless you grow the team along with the codebase), or (C) the team has bad engineering practices causing a high ingress rate, or (D) many bugs are based on misunderstandings, which points to documentation or UX issues. No matter how you slice it, I see it as never acceptable to let a bug pile grow indefinitely. Do you see this as a sort of compromise, as in it indeed pointing to deeper problems but needing a workaround in the real world, or do you disagree that a growing bug pile is symptomatic of deeper problems?

I’m the author of the article. I apologize for its massive length but wasn’t able to make it shorter without losing my favourite bits :) I’m happy to answer any questions people have here.

po 9y ago

Super interesting points here. You mentioned that the real-world Kanban board forces you to empty slots to make room... I've never seen that in any of the software Kanban-style systems have you? I've played around (in spreadsheets and basic apps) with trying to create systems that scaled available slots to team size as a way to force correct granularity.

apenwarr 9y ago
No, I've never seen it enforced by tools. Physical (index cards) kanban boards have an implicit space limit though, and this is one of the too-seldom-acknowledged reasons why they work as well as they do. Unfortunately the software clones of physical kanban boards copied the unnecessary part (visual appearance of index cards) and not the necessary part (limited space at each phase).
- WorldMaker 9y ago
  Rally lets you set card limits in each column, though in practice that always seemed too easy to change (just add a couple more to the limit; just "temporarily" turn off the limit) to be entirely beneficial.
yalooze 9y ago
Are you talking about work-in-progress (WIP) limits? I've seen tools enforce this so you can't pull another story into the current list. Other tools let you pull but highlight the fact that you're going over the WIP limits by making the whole column eg. red. Or do you mean something else?
benji-york 9y ago
I've used LeanKit's Kanban board to enforce per-lane WIP limits. It works quite well and is, in my opinion, one of the most important aspects of using Kanban boards for software development.

jasode 9y ago

>its massive length but wasn’t able to make it shorter It's always possible to make it shorter to help communicate a main idea. (However, it does takes extra effort to extract the essence of a long piece.[1]) Your essay is ~15,000 words and desperately needs a short "elevator pitch" of its main points. I'm a very verbose writer so when I think others' writing is verbose, it means everybody is going to drown in the text. Here's my summary of what I think you're trying to say: 1: There psychological problems with deadlines and large bug lists that cause counterproductive results 2: I discuss 2 psychological "tricks" in software development to counteract the unwanted behavior 2.a: Estimate software by abstract units such as "points" instead of concrete units such as "time/hours/weeks". The abstract units bypass the human biases that lead to bad estimates. Use the points to determine "relative" sizes of each "story". (E.g. Developers vote to converge on the "size" of each story point.) The last step is to multiply the points by a unit of time to derive a finish date. 2.b: Do not have a big global list of bugs to burn down. The size would be overwhelming and demoralizing to teams. Instead, triage bugs into smaller "hot lists" so they "see" a smaller manageable queue to work on. Also, measuring bug fix times will eventually let you derive an "average bug size" that's reasonably accurate The tldr would be something like "Here are 2 counterproductive management techniques with setting deadlines and assigning bug fix work -- and here are 2 ways to counteract it with management ideas that take advantage of human psychology." Somebody else can wordsmith it better than I can but that's what I think your essay is basically about. The 15000 words are mostly examples or background ideas leading up to your recommendations (SLO vs SLA, Tesla, what I like don't like about Agile, Kanban, etc). I recommend that you put your strongest main points at the very top to give your readers the mental scaffolding to hang the rest of your 15000 words on. [1] "I would have written a shorter letter, but I did not have the time." -- Blaise Pascal : https://en.wikiquote.org/wiki/Blaise_Pascal https://en.wikiquote.org/wiki/Blaise_Pascal

systematical 9y ago
TL;DR thanks. ++good writing advice
apenwarr 9y ago
I know what you mean, and in general I try to follow that advice. In the particular case of project management though, I'm frustrated by the huge amount of too-short and contradictory advice floating around on the Internet; adding one more unjustified summary to the pile doesn't help. So I think the extra details are important. And when you have that many details, the tangential expository fluff helps keep it interesting. I hope. This is also why I didn't summarize everything at the top: that would encourage people to just read the top and stop there. They can do that with project management advice anywhere on the Internet. There's a place for that, but there's plenty of it already. At least it's shorter than a book. :)

ndh2 9y ago

First, thank you very much for the write-up, I sure found it interesting as well as entertaining. When using bug trackers, I find the most frustrating aspect is the "non-linearity" of the workflow. By that I mean, how do I answer the question "What am I supposed to do next?". You can sort by project, or by priority, but what I typically end up with is a list of items that I already looked at a dozen times. And even though I don't want to look at them a second time, I haven't found a way for a bug tracker to do that for me. Ideally, I would want to look at each task at most two times: Once for triaging, and once for working on it. That's it. So the way I understand it, you're trying to address this, at least partially. A task starts out as untriaged, then you tag it as triaged, and that means you only had to look at it once for triaging. Which is great, because it's a linear workflow. Some tasks are obviously critical, and will end up in the next open release milestone. Some belong to a feature that is not released yet. But what about the stuff that ends up in the backlog? These smallish, nagging bugs that are not super-critical. That is the big, ugly pile that keeps growing and growing. How do you keep that big pile manageable? Ideally, that pile shouldn't become big in the first place, but how do you prevent that from happening?

apenwarr 9y ago
The way I like to do it is to keep multiple backlogs, broken down roughly by feature group (ie. groups of things that might eventually become a milestone or story of their own). Then when I decide to prioritize a given story, I can go to the relevant backlog and re-triage only the bugs in there, which should hopefully be a relatively manageable number. Another benefit of sub-categorizing this way is that it makes it easier to resolve bugs as duplicates. When a new bug is filed, it's hard to see that it's a duplicate when you're comparing it against 10000 other bugs, but it's easier when you're comparing it against only 100 other bugs in the same category. I doubt you'll ever be able to get it down to "at most twice." But it needs to be much easier than ever resotring to "looking through the whole list."

platform 9y ago

Agile is meant to be used for non-software delivery projects as well. In your view, with the parts you crossed out (including the physiological/motivational structures)-- would Agile still be widely applicable outside of the software-oriented projects? Couple of, say, hypothetical examples, perhaps for non-software projects -- developing & submitting scientific grant application -- organizing a non-trivial longitudinal survey -- looking for college for kids -- designing a motorcycle with unique frame/engine layout -- planning and shooting a movie

apenwarr 9y ago
In my opinion (and you should take it as an opinion :)), the "good parts" of Agile are the same for both software and non-software projects. Estimation, strict prioritization, and (automated) progress tracking are the keys to any successful project management.

bvrmn 9y ago

Wonderful article, read it like a blockbuster with a constants clicking in my brain. Every time I tried to impose some sort of sprints for myself and the team it always end in Friday superdense coding with a half task moving to the next sprint. Thank you for a great argumentation why precise estimation is a bullshit bingo, I tried to show to PM's that only a steepness of slope is important and managers can plan work without exact dev-hours, but without much success, your explanation is clear and easy to understand.

voxl 9y ago

I disagree strongly with your take on story points: First, if story points are an indirect measure of time, then the "psychological game" you're playing will be immediately revealed if your engineers are as smart as claimed. There is no reason for me to point something a 2 over a 3 unless you're measuring the time it takes to deliver software based off those measurements. On the opposite end of the spectrum, my confidence in whether a story is an 8 or a 13 becomes significantly weaker as the numbers get bigger. Using numbers, specifically, is a hint that whomever is handling process just wants to predict when the project will be done. Numbers trick you into thinking they can be added, margins of error are not additive. My go-to question in these situations is why don't we just estimate with abstract sizes? (Small, Medium, Large, etc) Surprisingly I'm often met with resistance. Second, if story points are not an indirect measure of time, then why are you pointing stories? What does the pointing gain your team other than fluff? If you say it's for prioritization then you're just invalidating the premise and we're back to an indirect measure of time. Finally, I have not seen, and you have not presented, evidence that engineers are good at estimating. In fact all that I have read seems to indicate the exact opposite, that engineers are very bad at estimating (in fact that they are largely too optimistic). One could argue that this can be trained, or that you'll get better at estimating as you gain more experience. Which I will concede that you will get faster and better at estimating and implementing the same exact feature, but that is not what we do. We implement new features, things we likely haven't done before.

lostcolony 9y ago
So what? Even though engineers realize that, as long as you're talking abstract points, and not holding me to a deadline, I have no reason to modify my estimate. And even if I -do- modify my estimate, as long as I continue with that new estimation mechanism for some period of time, velocity will change accordingly and the PO can -still- make accurate determinations of when something will be delivered. If I consistently under or over estimate things, I am predictable. The more constistent I am, the less time it takes to be uniform, and thus predictable. By not pinning it to time, the PO can determine the average velocity, the current estimations, and have a largely accurate idea of when things will be done. The only time this ever breaks is when I have a reason to change my estimation strategy, which only happens when you start applying incentives for me to change it. Every time my incentives change, my estimates will change; don't change my incentives. Don't give me a date or a deadline. We could do this with hours except hours actually translate directly to time. From them I can determine when you think I should be done and thus the implied goal; points I can't. Because of that, I have incentive to overestimate when it comes to hours, to give myself extra time 'just in case'. With points I don't; they don't imply an end time. Even if the PO's estimates are wrong, they can't get onto me, because I never had a due date. Because of that, my estimates tend to be consistent (even if inaccurate), and consistency = predictability. That's the goal, making it predictable when things will be finished (within a given tolerance; hours never give us that). Whether points are big, or small, the PO can determine "This team has an average velocity of 20 points, whatever size those points may be. That means I can expect around 20 points per sprint in terms of stories. I have 50 points I need to get done for this next release, that means I can expect it in three more sprints". All done without the engineers ever having a goal they are trying to make, no incentive to change their estimates, and literally the best predictability (not accuracy; you don't need accuracy) you can achieve, which, it turns out, is actually pretty damn good in practice. I think you're missing the fact that points only matter relative to each other. There is no absolute meaning. The author hints at that but I don't think is explicit about it, assuming you already know that. As such, a team tends to be consistent with them, even if not objectively accurate. And their mistakes average out into something predictable, even if not accurate. Because there is no incentive, conscious or unconscious, to massage it. Some people -do- decide to use t-shirt sizes for sizing, rather than points. It still works. This is generally equivalent to 3, 5, and 8 using points (fibonacci). Most people who use points say anything less than a 3 is wrong (make it a three), and anything larger than an 8 should be broken up because otherwise it's difficult to estimate (with -maybe- a 13). So use whichever you like. S, M, L, and maybe XL, if you want to map to four options, as you have with points. Though you need a way to aggregate them to determine a velocity; how many S = 1M, etc. That's why people tend to use points. Basically, the author said, flat out, it's a psychology game. AND IT IS. What a PO needs from a dev is consistency in how they estimate, not accuracy. From that you can measure the actual work completed over time, and get a measure of velocity, which can be used to accurately predict the delivery of future stories, within a pretty good tolerance. Ensure the psychology for that consistency is there. Points are part of it. No goals, milestones, deadlines, etc, are part of it.

mixmastamyk 9y ago

Nice work. It should be three blog posts/chapters however.

GFischer 9y ago

Very interesting article, thanks for writing it and sharing it, I forwarded it to my PM :) . I do think it could have been edited without losing your favourite bits though :)

gingerlime 9y ago

Amazing stuff. It was a real pleasure to read. Despite its length I couldn't get myself to skip ahead or skim. We're now in the process of switching to a structure similar to Basecamp's 6-week cycles[0]. And those cycles obviously do have a deadline. However, I would still say this kind of deadline is better than your typical one for a couple of reasons: 1. The team is self-managing. Typically the team was involved in the pitch process for the project, so they have vested interest in getting this done. I think this is key to avoiding the Student problem. It's no longer an assignment dropped from above, but something you are keen to push forward. 2. The cycle is 6 weeks rather than a sprint of 2... So this feels more like a slower-pace mini-marathon. And the team has autonomy to drop features or make adjustments. I admit that's a weaker argument for it than the one above. I wonder what's your take on this? [0] https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9cae https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9c...

Joeri 9y ago

I thought this was very insightful and spot on for the most part, but I had one remark. I object to the notion that it’s ok for bug ingress rate to be higher than bug egress. For me that’s symptomatic of underlying problems. Either (A) those bugs are on important features, and the team is favoring novelty over functionality by prioritizing new feature dev over feature maintenance, or (B) the broken features are unimportant and the team is failing to weed out irrelevant functionality from their codebase (it is important to remove features while you add them to not get in a zero-progress situation, unless you grow the team along with the codebase), or (C) the team has bad engineering practices causing a high ingress rate, or (D) many bugs are based on misunderstandings, which points to documentation or UX issues. No matter how you slice it, I see it as never acceptable to let a bug pile grow indefinitely. Do you see this as a sort of compromise, as in it indeed pointing to deeper problems but needing a workaround in the real world, or do you disagree that a growing bug pile is symptomatic of deeper problems?