Last time, I set the stage for why Quocknipucks (OK, I mean story points), despite being the target of recent severe Agile backlash, actually do provide a sensible and workable solution to the two most difficult aspects of software team sprint and capacity planning. I elaborated on the ways that Quocknipucks story points solve these two problems, in that they:
- Enable us to gauge the team’s overall capacity to take on work, by basing it on something other than pure gut and/or table-pounding; and
- Enable us to fill that team capacity suitably, despite having items of different size, and, again, basing our choices on something other than pure gut.
But there’s lots more to cover. I have more observations about the role of story points, and I want to provide some caveats and recommendations for their use. And it’s also worthwhile to list the various objections that people routinely make to story points, and provide some common sense reasons for rejecting those objections.