You're right, those two points are inadequately covered in the article. Thanks for reading so carefully :) Story point size: the usual thing to do is to have

You're right, those two points are inadequately covered in the article. Thanks for reading so carefully :) Story point size: the usual thing to do is to have "baseline tasks" (which the whole / almost the whole team did in the past) that you choose way back at the beginning, and then continue to use them as reference whenever estimating in the future. To do this, a couple of people who know the "approximate size" of a point estimate some, say, 2-point and 5-point past tasks, but don't tell anyone else how big a point was. And after that, they try to forget how big a point was during the baselining process. But you never, ever let people ask about time; you just say "was it bigger or smaller than the baseline 5-point task"? Defects: in the model as it's being discussed, we assume (perhaps too optimistically) that we generally fix bugs before adding new features. This is why, in the second simulation slide [1], each subsequent feature takes longer than the last. Eventually, you cannot sustain this method if you still want to launch new features and your team size hasn't grown and you haven't contained the number of new bugs somehow; I can't tell you what to do when that happens. It's hard. If you have mostly small bugs (which is common; just fix them) and a few large bugs (also common), then if the bugs are important, they can probably be described by writing a story. At that point you can elevate them to the estimation and PM prioritization process. Beware, however, that in general, if a bug is introduced by adding a new feature, you should almost always fix it before launching that feature. Otherwise you have basically lied about how long it took to implement that feature, and as that gets worse over time, it progressively upsets your estimates. [1] http://apenwarr.ca/log/?m=201712#slide16 http://apenwarr.ca/log/?m=201712#slide16