There is a certain connotation with the word estimate. People think of cost and time. Think about the last time a mechanic fixed your car or you hired a painter to put a fresh coat of paint on the third floor windows. You are thinking about time and cost aren't you? When we start thinking about a software project we are still estimating the cost and time, but of the project not the stories. We are doing ourselves a disservice when we say we estimate our stories.
We have been relatively sizing stories on projects for years. We are not estimating our stories. When we look at a group of stories it is pretty easy to compare them relatively to each other and have a good understanding of which ones are similar. The hard part is to predict how fast we will finish each story. It is the velocity at which we complete stories, combined with the total number of points, which allows us to estimate the project's cost and length.
So why does it matter if we size our stories or estimate them?
As soon as we talk about estimating stories the client (and team) naturally start to think about the time it will take to complete a story and how much that story costs. This leads to people wanting to change the number of points associated to a story because "it is taking longer than the estimate". Just because a story has taken longer than anticipated, does that mean its relative size is different to all the other stories? Maybe... but most often it is that our velocity is not what we initially thought it would be. Talking about the size of the story helps to focus on the velocity being the value that is different from expectations rather than the number of points on the story.
With this mind set, we can move away from constantly updating the the number of points on every story and instead focus on improving our velocity by finding ways to be more effective and reducing waste.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
