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

Details of the software are available at http://www.mountaingoatsoftware.com/ and the game itself is available in a web based version at http://www.planningpoker.com/

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 …

Update from the Break Period

Its been a temporary break since writing the chronicles of the application and also implementing. We have been busy reading and discussing lots of activities internally. Further, I have been having some trouble on the personal front. Hence, the activities on the Agile Project Management front have been lying low. However, it has allowed us time to step back, observe, gather opinions, hopefully understand and come back with renewed vigor over the next few months.

One of the activities is an Agile Project Management System. We have been reviewing a lot of SCRUM and XP based Project Management Systems. While some have some features which work very good, there are many which appear to be a drag. We are still undecided on a make vs. buy decision. This is possibly the biggest challenge in making a technology decision for a process. We should not forget that technology does not solve the problems - it can be an enabler and a very effective enabler, however, it will not solve most of the deep rooted process and improvement issues. Hence, while we are discussing the project management system, we should not loose sight of project management.

I read somewhere that effective change takes about 02 years to percolate down. It is heartening when the teams talk sprints/ iterations and daily SCRUMs. There was a time when development used to start without a clear idea of what the client wants. The wireframing and prototyping phase [which precedes the sprint immediately] has allowed us to confront the fact that We now need to think about the next level. I think the teams now to understand the importance of updating a project backlog, estimating the stories upfront and deciding how many stories would they want. Once this is done, we should then start at defining the steps for a project. Hence, “Stories and Tasks” should be the next from our motto of activities.