20 Aug 2012

Effective estimation in Agile

8/20/2012

Agile methodology comes with lots of flexibility around requirements which is primarily around bringing development more close to business and giving business comfort on the application.

Some unique features that make Agile so popular among business stakeholders today are :-
  • Requirements are flexible, which means low level details can be done in later phases (unfortunately its development phase)  
  • Frequent release to the customer to see and comment on the delivery

Now with such unique features it may sound a WOW for the customer, but is it the same for the development team or is it so easy to manage. Abiding to such flexible environment of delivery in a T&M (Time and Material) model is amazing as if requirement increases, the time lines also increases, however with the model that is ruling the industry currently i.e FP(Fixed Price and Fixed timeline) model, things are not the same.

The biggest question that any developer has is How do we estimate in Agile ?

Before actually getting with you to answer this question, lets first try and see what all needs to be done better and more effective to estimate better
  • Detail requirement as far as possible in terms of use cases
  • Try to document and baseline acceptance criteria for different granular functionality
  • Document and call out all assumptions in the project, in agile you cant afford backing on "This is understood"
If you have done these effectively, you have avoided 50% of the scope creep items, the rest can be mitigated  getting an answer to "How do we estimate in Agile ?"

The most effective and recommended way of estimation in Agile is Wild Card Delphi. This model of estimation does not uses any defined data points such as functional point, rather this model is based on experienced people (usually the team) get together and suggest and agree to a effort for each functionality.

Now using this model even, how do we put estimates ?
We estimate any functionality(to be made as granular as possible) two times
a) ABP estimate - Aggressive But Possible estimate. The effort estimated here for a task is with the thought process that all the assumptions that the team has proves correct later and there is no scope creep, and ideally the task would get accomplished in this effort
b) HP estimate - Highly Probable estimate. The effort estimated here is taking into account a worst scenario,  where depending on the complexity of work, how much effort it would take in a case where things don't go as expected. However as per guidelines to do a good estimation, your HP estimate should not be more than twice of your ABP.

Now for any task the estimate that needs to be planned needs to be an average of ABP & HP, we call it as Buffered Estimate, which is your actual effort for the task

Buffered Estimate = (ABP + HP) / 2

The sum of all the buffered estimates for different functionality is your actual project estimate.

Rest has to be an generic planning exercise, taking into account other add ins. 

Written by

We are Creative Blogger Theme Wavers which provides user friendly, effective and easy to use themes. Each support has free and providing HD support screen casting.

0 comments:

Post a Comment

 

© 2013 NimbleGeek. All rights resevered. Designed by Templateism

Back To Top