Thanks, Andrew. I agree that different approaches are available, but whichever approach we choose must be followed consistently and as intended in order to get the desired results. This is the basis of science, engineering, and technology. It’s the reason we invest in documenting protocols, insist on control groups, etc. If we’re going to throw consistency and causality out the window, then perhaps animal sacrifices could bring down the number of software defects. ;)

Story points were intended to be relative. They were invented to play to our human strength for relative estimation, i.e. this is harder than that. When story points work well, it’s because they’re being used as intended. When they don’t, they aren’t.

I enjoyed your article but found it to be more than a little inconsistent. You hate story points … but you don’t really. They’re relative … unless they’re invalidly equated with absolute units of time.

I understand that some of this was probably frustration (I tend to write things out when I’m frustrated too) and some was probably intended to be tongue-in-cheek.

But there’s really no mystery here. My own experience from many companies and many, many teams is that story points, which are intended as relative measures of the effort required to deliver a story, are extremely useful and accurate, when based on sufficiently detailed stories and when estimated with the team.

I’d suggest that if something doesn’t work, then let’s understand WHY before we begin changing things.