The Dreadful Estimates

Well the title of this post it self is self explanatory aint it ;) ... We all know how hard it is to estimate something in our own lives. Moms will always ask how long will it take to clean your room, wife will ask how long will it take for you to get home, if you ask your dad for something he will ask how much does it cost.. So as the pattern goes on you can see all of us live in a world revolving around estimates. The same comes into play when estimates need to be made when an IT project is taken into consideration. Ofcourse all of us know how much of a dreaded task estimations can be mostly due to the fact of uncertainity that is filled with making some or most of the estimates. Aim of this post is to help all you poor souls and to take you out of your misery of doing estimates and doing them right:D ..

First of all what needs to be done is basically jot down all the user requirements and break them up into user storys which refelect all the functionality which needs to be provided by the software we are doing to build. A user story can be just a short 3-4 line description of what the functionality is all about with a title preceding. For example a typically user story will look like the following;

Title - Log-in users to the system
Description - Provide authentication capabilities to users loggin in to the system via a login menu.

That of course is one simple user story but you get what im trying to imply here yea ;) ... Ok so moving on, the next thing to do is to get together with your team with all the user storys you have come up with after many initial discussions with the customers and to decide an appropriate estimate for each user story you have defined.

One fun way of doing this would be by putting the user story on the table, explaining to your team what is exactly required by the user story and ask each one to provide an estimate of how long it will take to finish that specif story. Then you look at the spread of values taking everything into consideration. You then ask each developer based on what assumptions each of them came up with the estimates. What you do then is clarify each assumption with the customer that your team has come up which even you cant provide an accurate answer. Note that this is a pretty important step because if you go ahead with many assumptions to the coding stage that runs a high risk factor of the resulting software not being what the customer really wanted. Hence it is always advisable to talk to the customer up front with any assumptions you have and to get it clarified at that point of time so as to minimise the risk factor.

But of course at times even the customer would not know the correct answer to an assumption in which case what you should be doing is noting it down so that you have a track of any risk factors associated with each user story.

Then after going through the cycle of estimation and assumption clarification you ask your team to make another estimate now that most of the assumptions are resolved. Then you take the spread of estimated values which in this case would not be as much dispersed as before and take an average value from those values and come to an agreement with your team members of that value. Ofcourse one thing to note is this time should include not only the coding time but also the design, testing, integration, documentation(if needed) and deployment time.

If for some reason the estimated number of days for a user story is more than or equal to 15 days that usually means still there is something wrong somewhere. So what do you do in this situations? Well you got two options;

1. Break down the user story into smaller functionalities, thereby spreading the number of days among the sub functionalities.
2. There still might be unanswered assumptions that might fact for this estimate hence it is time to go back to the customer again and to further clarify those assumptions which would eventually lead you to re estimate the number of days.

Hence any of the following two ways can be used. After that what you do is add up all the estimated values you have come up with for all the user storys which would then make it possible for you to give the customer an estimated for the whole project which you feel confident about because you and your team have nailed down almost all of the assumptions and are pretty confident with the estimate.

So you come up with the estimate for the whole project. What if the customer says that the number you came up with is too much???? Yikes, didnt think of that now did ya? Well that my friend is a topic of its own. So stay tuned for the next post to see what you can do to overcome/handle such situations.