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;
- Break down the user story into smaller functionalities, thereby spreading the number of days among the sub functionalities.
- 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.
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.