Agile Estimating – Part A
<a href=”http://del.icio.us/post?url=&title=” mce_href=”http://del.icio.us/post?url=&title=”> <a href=”http://reddit.com/submit?url=&title=” mce_href=”http://reddit.com/submit?url=&title=” >
Agile estimating is supposed to be a democratic and simple process:
1. Write down some user stories
2. Get a group of people together
3 Explain [if required]
4. Play a delightful planning poker game
5. Estimate in story points
6. Apply a conversion factor [derived historically]
7. Compile the points
So, why is that despite a Business Analyst leading the Agile Project Management movement in our organization, we still have estimates that go wrong horribly? Here are some ramblings from the internal cogitation in the mind:
1. Fixed price estimates: Agility and fixed price estimates seem very different from each other. Agility is responding to change, while fixed price estimates seem to come with fixed specifications as well [well we do know that no specifications ever are going to be final]. One of the suggestions has been to do fixed price estimates with a fixed time period too. I am not sure if that cuts the ice with the customers either who seem to be saying “What can we do if you guys screw up our project and not complete it on time?”
2. Too low time spent on estimates/ proposals: Agility bug has bitten the pre-sales department too. A week is very long time in turning around a proposal especially for low budget projects. Hence, there is less time spent on drafting and importantly discussing the proposal specifications internally and with the client. The result is half baked specifications which go more into how [there would be a text box to allow the users to enter a category] rather than the why. The business process problem/ competitive analysis and importantly domain model – largely stable issues for small budget projects [thereby meaning most of the time small duration projects as well] are often not explored in sufficient detail. An attempt is made to use the historical data for estimating rather than actuals to come up with estimates.
3. Agile environment: An agile environment is very receptive to dynamics of business and requires a very fast response. Fixed price estimates and specifications on which they were based [the same then drives project schedules and milestones] inevitably lead to discussion and heart burn between the team and the client over what is quotable and what is not. This destroys the very basis of Agile – “Customer Collaboration”. After a while the customer distrusts all estimates and milestones, and gets into a bargaining mode.
4. Upfront estimates: Fixed price estimates are always upfront estimates. This means that you generalize everything to result in a utopia kind of environment – average if not perfect developer competence, consistent developer availability, no attrition, knowledge management, code reuse, regular client feedback, no QA issues or regression. This never takes place in a live project. Hence, the idea of a fixed price estimate [upfront estimate] that is ingrained in stone does not seem to work.
Having looked at this, what are the possible workarounds and “art of the possible” strategies for the same? Let’s explore tomorrow or next week …