No estimates? How can a software development team have no estimates? How can an Agile software development team not apply story points to a story? It goes against everything…or does it?

We first need to explore why we estimate. On the surface, a software development team “estimates” so that it can predict when work will be complete. In an Agile/Scrum world, we estimate in story points so we can establish a velocity. From the established velocity and a prioritized backlog, we can predict when a set amount of work will be complete.

So, there it is…we need to estimate to predict when we will complete a feature. But wait, is there a chance that this process can cause a distraction to the team?

Estimates, whether in points or hours or both (equating points to hours), set an expectation. With that expectation, a team will focus on hitting the time window rather than the quality of the product. The intent of story points and velocity is an internal tool for the team to gauge the complexity of work that can be completed over a set period time. It is not intended to be used to formulate a deadline.


Are there other, maybe more efficient, ways to predict the completion of work? Cycle time measures the time it takes to complete a story from the time work begins. Couldn’t that be used as a way to predict the completion of work?


Throughput measures the number of stories completed for a given period of time. What if we just look at the number of cards we move across the board in a week and use that as our predictor? The graph below shows one of our team’s tracking of velocity and throughput, and indicates story points completed is virtually equivalent to cards completed.


OK, so if I use cycle time or throughput, I don’t have to estimate stories? That sounds great!

We don’t need estimates!

All of those lengthy story sizing sessions can be thrown away because we don’t need to bother “wasting time” discussing the complexity and effort required to complete a story! We don’t need estimates! Cycle time and throughput saves us!

But maybe we need to go beyond the surface as to why we really go through the estimation exercise. Can estimating the size of story be used for more than just predicting when a set amount of work will be complete?

Many times, I’ve heard story sizing sessions are too long. And pointing sessions are painful. But why are they lengthy?

An estimating session is used for the team to come to consensus on the complexity, risk, and effort of story. The team will relatively compare a story to another to determine the size. It all sounds simple, yet seemingly often this ends up turning into velocity killing sessions

So, what are some reasons that cause these sessions to be lengthy?

A story that is not estimable:

What does that mean? The story lacks the detail necessary for a team to fully understand what it takes to complete it. Maybe it’s poorly written, or it lacks clear acceptance criteria. To be “ready for work”, the team needs to understand how to get it across the board. To be sure a story is estimable, you need an estimating exercise.

A team struggles to come to consensus on the size of story:

Why would that happen? Again, the story is too ambiguous and needs refinement.


The team flashes their story size and the numbers are all over the map. The team goes through the discussion as to why the sizes are so different. The story is refined and, after some time, the team comes to a consensus. What other avenue besides an estimation session could help an entire team come to a consensus on what it takes to complete a story?

Of course, over time, a team matures and can get consistent in their story writing in that stories have just enough detail for a collective understanding and are all relatively the same size. However, that is a journey that will vary from team to team -- and, it takes time.

The story is too large:

The team sizes a story that is an XL. They feel it is too big so they break the story down even further and then estimate the size of the resulting stories. While a mature team can easily identify when a story can be additionally broken down, a less-seasoned team will use the estimate as a trigger to further break down the story.

So, where does that leave us? There are alternate methods (i.e., cycle time and throughput) that can act as predictors when work can be complete. If we can collect those metrics, we don’t need estimates. But how much value do we lose if we don’t go through the estimating sessions? Mature teams will come to a quick consensus the majority of the time. But if the sizing exercise clarifies the understanding of even one story, doesn’t it justify the value? In LEAN and Agile, we strive to eliminate waste. An estimating session in which the team comes to a collective understanding of a story is not waste. Working a story that isn’t clear and leads to a misinterpreted result is waste.

So, if in the end you want no estimates attached to a story, go for it. However, keep the value of the discussions that occur in an estimation session in mind. And be sure those “consensus” discussions are happening in some form, even if it is during a story sizing session in which the estimates aren’t ultimately attached to the stories.