Over the years (and much to the delight of my customers) I’ve used story points to accurately predict when a project was going to hit its relevant milestones.
However, I’ve recently been noticing that my estimates deviated very little from user story to user story—and for good reason. The story cards tended to all be roughly the same level of complexity. Sure there were differences, but my boards were often comprised of stories predominantly of the same size.
Those user stories that were radically different from the others in size were the ones that I was most interested in considering. They were often overly vague or encapsulated too much functionality. When I carefully edited these stories and spawned new ones when appropriate, I noticed that I continued to create consistently-sized stories.
So if they’re all the same size, why estimate at all? It’s simpler to commit to a consistent number of stories from sprint to sprint as opposed to a consistent number of points. After all, clients seem to instinctively understand user stories but often have difficulty with story points. By removing story points from the conversation, you get to tell the client, “we’ll get 5 stories done this sprint” instead of “we’ll get 14 points done this sprint”. It’s an easier conversation to have.
Though it sounds attractive to immediately stop estimating your backlog, it does not mean you are absolved from the hard work of carefully reviewing all of the stories in the backlog. You’ll still need to meet with the team and cover each of the stories in depth. That doesn’t change.
What will change is the discussion surrounding the user story. Instead of discussing how much effort will it take to complete a particular story, the question becomes, “Will this story take considerably more effort than the others to complete?”
In the end, you’re left with a board that with a simple glance can tell anyone how the sprint is progressing—no need to add up cards up in your head.