Wednesday, May 25, 2011

Software Estimation - An Organic Approach

In previous posts I have described the extreme ends of the software estimating spectrum.  Neither end is desirable.  First, let me say that I don't like estimating, at least not the estimating that puts stress on developers to meet unrealistic time-lines.  I like the idea of continually delivering value to customers [Product Owners] based on business priority.  Trying to predict software delivery is risky business.  To mitigate that risk we as professionals adopt Agile beliefs and methodologies.  That is just not always possible.

If I have to estimate for waterfall SDLC, then I believe that good estimating is the result of weighing several factors, not the least of which is experience.  This is why junior developers generally do not make good estimators; they simply lack the requisite experience upon which to base their decisions.  However, if you must estimate, juniors should be included in estimation processes so that they can learn the skill.

If we reflect on the purpose of estimation, we realize that we are simply forecasting a future outcome, based on information available to us now.  The information at our disposal is a an amalgam of data, experience, technology knowledge, code familiarity, application familiarity, business process knowledge, etc.  The list goes on.  The secret sauce to estimating is how we apply these data, information, and knowledge to execute tasks to a prescribed standard.  Knowing what is relevant and what is not also helps in constructing a clear and accurate estimate that will stand up to scrutiny.  Finally, good estimators can articulate why they made certain decisions that led to the estimate.

Truly accurate software estimates start with truly accurate analysis.  That is to say that before a developer begins an estimate, he or she should understand (as much as possible) the functional and non-functional requirements of the work to be accomplished.  The degree to which the analysis is done [correctly] will directly contribute to estimate accuracy.  During the estimation process, developers match requirements to code artifacts and apply proper weighting based on complexity, etc.  Without a good understanding of the requirements, this step is not possible; moreover, estimators may apply a ambiguity factor to the overall estimate when requirements themselves are ambiguous.   This comes dangerously close to sand-bagging or artistry if not properly monitored by senior developers/estimators.

One of the important factors of accurately assessing and estimating work is understanding that one should reach out to his or her team for their input and support.  No one person on a software team knows everything about the task, or the software components (real or imagined) that are involved.  I like to start with the abstract approach of estimating stories and assigning story points that typical Scrum projects use.  I like to get my developers together and have them assign story points to each of our JIRA tickets that have been prioritized by the business.  Even if we are not full-blown Scrum and we do not have a defined "Product Owner" role, we still start with a list of business priorities. 

Once we know the list of prioritized JIRAs each developer picks a number from the Fibonacci sequence, starting at 1 and ending at 144 and assigns it to the JIRA, based on his or her knowledge of the task, code, application, experience, etc.  For this purpose there is no need to go any higher than 144, and using the Fibonacci sequence helps to eliminate the ambiguity of more linear scales, like 1-10 or 1-100.  This approach of assigning more abstract values to the initial estimate and using the input of multiple developers facilitates discussions among team members, about the estimates for each JIRA.  More often than not, the true nature of the work needed is discovered through the discussions and the correct Fibonacci number is finally assigned to the JIRA.  Of course we would take this even further if we were a Scrum shop, but that is not the case right now.

The key to getting the correct Fibonacci number is to ask the team to qualify there answers with what level of developer would be needed. This should fall out of the discussion when certain members of the team have different estimates.  I try to convince my team that we are estimating for intermediate to advanced developers.  This eliminates the need later to take into consideration the level of the developer assigned to the task.

In my next post I will show how the JIRA/Fibonacci number is used further in a PERT analysis for more Waterfall-like estimates.

No comments:

Post a Comment