Interesting article, I have a few comments/questions
Story points - there is a lot in theory I like about these and you hit on those points. But in practice where my teams have struggled is still in the definition of a point. People understand the relative sizing concept but they still want a definition of what one point means and that invariably winds up being some kind of a time unit, which means all points get thought of in time units. What techniques have you used to solve this problem?
Defects - some good points were made but you never really discussed how these are managed as work. Stories and defects are getting worked on at the same time, but how exactly? Are defects just lumped in with stories and the PM prioritizes them? I do not think so, but you are not clear in this area. If a PM prioritizes a story but the team spends all of its time resolving defects then how is value being delivered as expected? You seem to have left this out completely, or I missed it.
Finally, also on defects, while your points on not estimating them makes some sense, someone has to decide what to work on, and generally you need some idea how long things will take to make that decision. Even in your wording, you acknowledge some defects take a long time to fix, where as others are super-quick and in the end they all average out. Still, someone in the organization still cares about dates and delivery. It made a lot of sense to me where you indicated that the story point estimate can be valuable to the PM in terms of prioritizing. When they see a story with a high estimate that might cause them to lower its priority compared to other stories they can get delivered quicker. But seemingly defect fixing would have to factor into this somewhere too, and then wouldn't the same concept apply? If defects are not estimated, how can the time it will take to resolve the defect inform the decision making process?
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.
I actually reject the idea of story points as a unit-less number, mostly because people can't help but think about them in terms of time anyway (whether they want to or not) [1].
Rather, I like to use a discrete list of story point values as scalar value that represents a probability distribution for how long the task might take. As the story point gets bigger, not only does the mean time get bigger, but the variance grows as well.
For example, a 1 is 2-4 hours, but a 13 is 2-3 weeks, and a 40 is 1-2 months. The idea is that not only do more complex tasks take more time, but the precision of our estimates goes down.
This makes engineers happy because they get to be more honest about estimates, and it makes managers happy because they only have to deal with one number.
[1] Unit-less measures might be easier in an environment that is more concerned with true productivity than with deadlines, but that is not most environments.
In terms of mapping story points to time ranges, here's the full list:
1 point -> 2-4 hours
2 points -> 4-8 hours (1 day or less)
3 points -> 1-2 days
5 points -> 3-5 days (up to one week)
8 points -> 5-9 days (up to one two-week sprint[0])
13 points -> 2-3 weeks (1-1.5 sprints)
20 points -> 3-4 weeks (up to two sprints)
40 points -> 1-2 months
Anything beyond 40 needs to be aggressively analyzed broken down into steps, even if those steps are not deliverable features per se.
[0]For a two-week sprint, you have to account for at least one day each sprint for demos, retrospective, and planning. Thus, you have at most 9 days for implementation and testing.
The whole "point" of story points is that they are meaningless until after something has been actually accomplished. After working for a few weeks, it's pretty easy to say something along the lines of "the team got 52 points finished and deployed last week" - this is useful to know, and over time you'll develop an intuition that may be useful for forecasting what's likely to get done over the next few weeks or months on this particular project with this particular team. That's it, that's the most you can do. Most of the other stuff people try to do is so noisy that it makes for nice spreadsheets of the "plan" but bears very little resemblance to reality.
I get that, but when you have that first estimation meeting with the team they inevitably ask what a point is. They get the relative sizing idea but you still need to size the first stories.
Story points - there is a lot in theory I like about these and you hit on those points. But in practice where my teams have struggled is still in the definition of a point. People understand the relative sizing concept but they still want a definition of what one point means and that invariably winds up being some kind of a time unit, which means all points get thought of in time units. What techniques have you used to solve this problem?
Defects - some good points were made but you never really discussed how these are managed as work. Stories and defects are getting worked on at the same time, but how exactly? Are defects just lumped in with stories and the PM prioritizes them? I do not think so, but you are not clear in this area. If a PM prioritizes a story but the team spends all of its time resolving defects then how is value being delivered as expected? You seem to have left this out completely, or I missed it.
Finally, also on defects, while your points on not estimating them makes some sense, someone has to decide what to work on, and generally you need some idea how long things will take to make that decision. Even in your wording, you acknowledge some defects take a long time to fix, where as others are super-quick and in the end they all average out. Still, someone in the organization still cares about dates and delivery. It made a lot of sense to me where you indicated that the story point estimate can be valuable to the PM in terms of prioritizing. When they see a story with a high estimate that might cause them to lower its priority compared to other stories they can get delivered quicker. But seemingly defect fixing would have to factor into this somewhere too, and then wouldn't the same concept apply? If defects are not estimated, how can the time it will take to resolve the defect inform the decision making process?