<story><title>An epic treatise on scheduling, bug tracking, and triage</title><url>http://apenwarr.ca/log/?m=201712</url></story><parent_chain><item><author>apenwarr</author><text>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.</text></item></parent_chain><comment><author>Joeri</author><text>I thought this was very insightful and spot on for the most part, but I had one remark.&lt;p&gt;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.&lt;p&gt;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?</text></comment>
<story><title>An epic treatise on scheduling, bug tracking, and triage</title><url>http://apenwarr.ca/log/?m=201712</url></story><parent_chain><item><author>apenwarr</author><text>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.</text></item></parent_chain><comment><author>voxl</author><text>I disagree strongly with your take on story points:&lt;p&gt;First, if story points are an indirect measure of time, then the &amp;quot;psychological game&amp;quot; you&amp;#x27;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&amp;#x27;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.&lt;p&gt;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&amp;#x27;t we just estimate with abstract sizes? (Small, Medium, Large, etc) Surprisingly I&amp;#x27;m often met with resistance.&lt;p&gt;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&amp;#x27;s for prioritization then you&amp;#x27;re just invalidating the premise and we&amp;#x27;re back to an indirect measure of time.&lt;p&gt;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&amp;#x27;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&amp;#x27;t done before.</text></comment>