“Accurate estimates is an oxymoron”
Today at our planning meeting we had an interesting discussion regarding sizing our features. We were questioning how to do right sizing and what is the basis and all good, logical and so called fun questions. Here is my take on it :).
Agile teams estimate SIZE of a feature (Story) rather than estimating the DURATION it will take to complete. Our team likes to estimate size with t-shirt sizes. Story points or T-shirt sizing are a unit of measure for expressing the overall size of a feature. When we estimate with t-shirt sizing or store points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values?
Lets take an example of restaurant before we dive too deep. Suppose a new restaurant opens nearby, and you decide to try it. For the first course, you can have either a bowl of soup. You can have the entree as either a full or half portion. You have probably been to many restaurants like this and can quite easily order about the right amount of food without asking how many ounces are in the cups of soup and exactly how big the entree portions are. At most, you may ask the server something like "How big is the salad?". The server will likely respond by holding his hands apart to illustrate the size. In cases such as these, you are ordering by relative rather than measured size. You are saying, "Give me the large portion" or "I would like the small serving". You are not ordering by exact size, such as I would like 14 ounces of sode, 6 ounces of rice and 3 ounces of veges.
It's possible to estimate an agile project's features in the same way. When I am at an unfamiliar restaurant and order a large soda, I don't really know how many ounces I will get. About all I do know is that large soda is larger than a small or medium soda and that it's smaller than an extra-large one. Similar analogy can be taken for spice levels.
Fortunately, this is all the knowledge I need :). All I need to know is whether a particular feature is larger or smaller than other feature. A feature that is assigned a 2 should be twice as much as a feature that is assigned a 1. THERE IS NO SET FORMULA FOR DEFINING THE SIZE OF A FEATURE. Rather, a sizing estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, risk inherent in it and so on.
We can get started by selecting a feature that we expect to be one of the smallest features we will or have work with and say the feature is estimated at 1 point. The best way to see how this works is to try it.
“Confidence comes not from always being right but from not fearing to be wrong.”
A key tenet of agile estimating and planning is that we estimate size but derive duration. (Estimates / Velocity = duration). Velocity is like weather. Based on past we try to predict but it may differ. (I will try to cover techniques of velocity estimation in next blog post.)
The beauty of this is that estimating in story points/ t-shirt sizing completely separates the estimation of effort from the estimation of duration. Of course, effort and schedule are related, but separating them allows each to be estimated independently. In fact, we are no longer even estimating the duration of a project; we are computing it or deriving it.
The distinction is subtle but important.
