I once had a Developer on my team, a wicked smart and funny guy, whom I was coaching on agile. He was brand new to agile, but certainly no stranger to wit. After introducing him to the concept of user stories, story points, and planning poker, he one day coined a phrase, “It’s agile, where the stories are made up and the points don’t matter”.

Proponents of the #NoEstimates movement, agilists who believe that story points are unnecessary, would probably agree with the second half of that statement. (On the other hand, those who dislike agile and/or product people, might agree with the first half of that statement, but that’s another blog for another day.)

At an annual Agile Open conference, I sat in on a heated conversation around estimates. Some argued for pointing in story points and then hours, while others argued for not pointing stories at all. I’m not sure how the first side felt after the conversation, but I know the second side walked away frustrated and turned the conversation into an inside running gag for the rest of the conference.

At this conference, my role was to sit back, assist the facilitators where needed or asked, and just observe. And in this session I did, while munching on some metaphorical popcorn. But what both sides missed is that all forms of estimation or no-estimation are valid, but, it is a spectrum of growth. New teams need the structure of story points, and even hour estimation, to ensure they have a grasp of the body of work in front of them. As teams improve, they can drop the hour estimation as their confidence in their pointing improves.

But a team should strive to continue their growth in estimation, story writing, and story splitting. Because on the end of the spectrum of growth is where the #NoEstimates lives. Here, a team is confident in 1) their ability to split work into it’s smallest possible chunk of value, 2) their ability to create these chunks about the same size as each other, 3) their ability to ensure each chunk fits within a sprint, 4) their ability to gain shared understanding of the story and 5) their own ability to execute and deliver the work the team commits to.

Story Points provide 2 benefits. First, they allow the team to determine how much work they can complete within a sprint. By knowing the size of their work, they can determine what stories will fit in the sprint, and what won’t. Story Points aren’t for “taking credit of the work we did” or “comparing 2 teams”, it’s simply to provide a way of knowing if the team has not enough work, too much, or just enough for their sprint. As a team matures, they can trust their intuition as well as the story count of how many stories they typically complete in a sprint as their measurements for what to commit to for the next sprint.

Most agilists intuitively understands this first point, but some miss the second benefit; it helps the team see if they have a shared understanding of the story. If you and I are on a team and estimate a story to be the same number, then there is a good chance that we both understand what it takes to complete the story. But, if you point the story as a “1”, and I point it as an “8”, then there is something that one of us doesn’t know or understand. Perhaps you know that this is a simple configuration change. Or, I know that the code doesn’t support this change and requires heavy refactoring of a critical area of code. By pointing, we encourage the team to raise and discuss areas of misunderstanding and diffences of opinion.

For a team to be ready to try #NoEstimates, they must be a well oiled machine, capable of splitting stories down effectively, intuitively knowing how much work they can take on (or not, if they are a Kanban team and don’t plan), and capable of getting to a shared understanding of a story without pointing. All of this requires a highly-functional team that has long since passed the “Storming” phase of growth. By understanding what story estimation provides besides an estimate, a team can move beyond estimates and focus more on the value the team delivers.