|The Thinking Factor|
Traditional ways of estimation following FP, COCOMO or other methods was all focused on providing estimates which were "Absolute" in nature. However, agile philosophy encourages a "Relative" nature of estimates aligning with the very definition of Estimation.
Wikipedia: "Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain."
You can estimate a piece of work to be done in "Absolute Terms" as 10 days or a 15 days or 25 days, while you can estimate the same work item in "Relative Terms" as "Small" or "Medium" or a "High" complexity work when you are not sure on the exact effort required to do the job. This relative estimation is where we would like to get to if you are moving from traditional methods to agile estimation.
|Agile Estimation Characterstics|
- Work items are broken down and smaller immutable elements estimated rather than the larger items
- Estimation is done by either people who will work or have done the work before
- Estimates are relative and presented as a range than absolute
- Estimates are not accurate and hence updated throughout the project
- Common sense prevails hence approach should reflect your environment than hardcore methods and formulas
- Encourages to get Over professional estimator mindset
|Few Factors Influencing Against Agile Estimation|
- Desire For Greater Accuracy and Detailed Information
- Big Design Up Front (BDUF)
- Forces to Commit on Monthly/Quarterly or Yearly Plans
- Need to Define Budgets Upfornt for the entire release
|Agile Estimation Techniques|
While there are other techniques as well apart from below mentioned, i found following useful implementing in our projects based on various factors.
A method that we use when the work to be done is new to everyone and hence calls for an individual vote of complexity estimate. Group of team members sit and discuss the story, assign a complexity number of 1 to 8 or any min or max numbers agreed to define complexity. The estimate that gets and maximum votes is taken as the relative estimate for the story. This also really helps when a team of new members join to go with the wind and quickly understand the mechanism of estimation witin the team. A discussion by people who have voted a number the most will assist the process and iron out any discrepencies.
Powers of Two
A technique often used to calculate complexity of a piece of work in powers of two i.e 2, 4, 6 8. Easy work assigned the least of the powers and assigned a value of 2 and largest or high complex stories assigned a value of 8. It really gives a common ground in terms of multiple teams estimating. I find it specially useful when a team of developers/testers/analysts sit together to iron out the detail task level estimates for a feature. Likewise a good way for product owners/scrum masters to have an idea on task level comlexity.
More or less similar to the Voting estimate but just that the largest estimate is considered to be the estimate to go with, assuming the person who has estimated it high has covered all the risks associated with the story. While the discussion around the estimate "assists" in the voting technique, largest estimate system "demands" a view into differences in estimation between the lowest and the highest estimate. Based on the differences or discussion, the person estimating the lowest has to either increase his estimate or the one estimating high has to reduce his estimate accordingly.
Baseline Story Estimate
It took a while for us to get to this technique where a similar story which was done previously is taken as a baseline and current estimates built relative to that baselined story. You could also have a baseline story per complexity and estimate realtive to each of that respective baseline when you estimate for simple to complex (2, 4, 6, 8....). Adivsable to go for this technique when you have already worked on couple of sprints and have some good metrics from previous sprints, stories completed to be able to choose baselines. I personally feel this tends to get me closer to actuals based on the fact that the baseline story has been already developed and all risks to implementation considered before estimation.
Not Enough Information On The Story
- We push back as much as we can to product owners and as and when we have information on the story, we shall include it in the next available iteration.
- We occassionally, have taken it as a story to gather information within the new sprint and scheduled it for release in the subsequent sprint with more gathered information. Caution, if this becomes repetitive you may end up having many stories coming into current sprint for just information gathering which does not provide value. So personally i would discourage it but would not mind using it occassionally.
Estimates Are Stale in Just Weeks
Its common practice that many of stories are estimated upfront and agreed with respective stakeholders by a team and estimates become stale within few weeks. It is always recommended that any story being taken up in the sprint is estimated from scratch or atleast verified. Assume a story estimated today and scheduled for delviery say in next one month. The story would have changed to a great extent with atleast couple of sprints going live and functinalilty or code base changed.
Large Story, Large Estimate
This is never true. A piece of work could appear to be doing 100's of tasks but in effect could be finished with a very less complexity. On the other hand there could be a function as simple as login and could end up being extremely complex to implement. Whie i dont like to say this but we do increase the complexity of estimate should we feel that effort required for a story is high. We also do vice-versa so effect is neutralized :).
Estimation, Waste of Time For Whole Team
I guess very common challenge is to justify time being spent on team estimation, where whole team will sit down for estimation and probably one full day for whole team is gone. While there is no confirmed answer for this, i would like to say "Common Sense Prevails". Take a call on if you want entire team to sit or want relevant team members doing the work estimate if your team is large in size. Typcially if a team is 5 to 6 members then less issues, i guess whole team can sit and estimate but if its more, then you probably want either to break down the team and have theme based estimation calling relevant members or have key members responsible for the work to estimate.