Following the premise that “there is no silver bullet for software estimation” let’s see if we can make some sense on how to start this discussion. Let’s first define what agile estimation is, isn’t an attempt to lay down some actions steps one might take when faced with an agile project. If there really is no silver bullet then at least let’s look for a good reliable starting point.
Before we get started, I would like to say that I am not starting from scratch here as I have had the privilege of learning crystal agile modeling techniques over the past eight years by working with many great senior agile consultants including Ken Schwaber, Dean Leffingwell and Mike Cohn. I would also like to give a special thanks to Jeff Sutherland and all of the agile coaches at Scrum Inc whose agile training course focuses on agile estimation techniques that we will discuss in this article.
I’ve been asked by several people recently if agile metrics such as velocity or story point estimating are agile estimating techniques, agile modeling techniques or agile planning techniques? To answer this question does require an understanding of what is meant by agile estimating, agile modeling and agile planning which we will try to address next. First though let’s start with a definitional discussion about what is meant by the word estimate .
Estimating Versus Estimation
In my experience there seems to be two different views on how one might interpret the word “estimate” one of which is that of “to form an estimate about, or to judge tentatively or form an opinion about (something that cannot be known with certainty)” and the other being “the act, process, or result of estimating something”.
The agile community uses the word estimate in both senses. To explain this better I will give two examples taken from agile literature. The first example I use will be using the word in its sense of “to form an opinion about (something that cannot be known with certainty)” when describing how agile planning techniques are used during sprint planning to create a forecast for what can be delivered by the end of a sprint. The second example I will use is the word in its sense of ” to make an approximate calculation or judgment of (something that is difficult to determine exactly)” when describing how agile estimating techniques are used in agile estimation for sizing user stories.
The word estimate in its agile context can be a source of confusion because agile teams use the same word to mean two different things in agile estimation and agile planning. If you ask a team practicing Scrum if they have done any estimating during their sprint planning meeting, they will tell you that all they have been doing is forecasting what can be delivered by the end of the sprint based on the information available at the start of the meeting. In other words, agile teams use one meaning of the word estimate when talking about agile estimating and agile estimation. (Note: Agile estimation is also known as agile estimating and story point estimation.)
When agile teams are estimating agile work, they are trying to come up with the best possible approximation of that work based on available information at the moment they need to make that estimate. They use their past experience, product vision documents (and/or business requirements), functional specifications, documentation, prototypes, etc., to come up with an estimate. They may even do a series of very quick back-of-the-envelope calculations before settling on an answer. The key word being quick . This is why agile teams are often seen drawing on white boards or using large sticky notes on walls while collaboratively brainstorming estimates for various stories.
Simply put, agile teams don’t estimate work using a crystal ball. They use their agile brains to come up with the best possible approximation of that work based on available information at the moment they need to make that estimate. In doing so agile teams create estimates as working agreements , which means those estimates may change as new information is discovered or as assumptions are invalidated during further investigation.
In other words, agile estimation is all about . It’s really been quite simple and straightforward from the beginning. The challenge for organizations adopting agile development has always been how to adapt agile estimation techniques to fit within their existing project management tools and processes, something I covered in my 2007 article Agile Development Is More Than Iterations .
With the recent popularity of agile software development, agile estimation has become a hot topic among agile coaches and consultants. I’ve recently had the opportunity to work with agile teams in several organizations that are moving toward more agile practices (such as test-driven development [TDD] and continuous integration) but have struggled with agile estimation. In these situations, it’s clear that many agile teams see agile estimation as something complex and mysterious rather than being just another example of working collaboratively to estimate a project.
This article provides an overview of agile estimation techniques so you can apply them on your own projects. Keep in mind that one size never fits all, so recognize how much or how little you want to adopt from each technique described here based on your own situation and preferences.
