Monday, January 17, 2011

Estimating for size vs Estimating for duration

“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.

Saturday, January 1, 2011

Nine steps to Better software design

Off late, I don't like to think about designing when I am coding. I know I know designing is important. I am not denying the importance but like to do it differently. I keep SOLID principle in my head when ever I code. These principles are applicable to any domain. And along with these principle I like to follow few rules defined by Jeff Bay in thoughtwork's book.

The Rules
------------
Here are the rules:

1. Use only one level of indentation per method. (My version is two level ;). It's too hard to stick with one.)
2. Don’t use the else keyword.
3. Wrap all primitives and strings.
4. Use only one dot per line.
5. Don’t abbreviate.
6. Keep all entities small.
7. Don’t use any classes with more than two instance variables.
8. Use first-class collections.
9. Don’t use any getters/setters/properties (hummmm take your own call.).

They are easy to follow and does magic with the code...