Archive for the Estimates Category

Agile Estimating – Part D

Posted in Agile, Business Value, Estimates with tags , on May 20, 2007 by vikramadhiman

I posted the Part C of this series on the SCRUM development yahoo group. There was in interesting discussion on the same in the group. The general crux seemed to be:

1. Team do not generally over estimate. If anything they underestimate. There may be some minor variations depending on recent experience of teams with some clients or features [using Atlas AJAX framework with dot.Net 2.0 takes more time] or team composition [our lead QA just resigned and new QA would take time to understand features and functionality].

2. Generally, all successful teams have a common minimum time that they would take to do a particular work. The fact that others bid lesser than this, does not mean they are able to do it in less time.

3. Sometimes, the teams might have past experience or know of a smart way to do things, that makes them able to bid lower than competition

4. Organizations can bid lower on a large project which would have many change requests and variations during the project, making up for any low bid. There may be projects where total final cost to the customer.

5. Some truly lean organizations can have low overheads and better programming frameworks like RoR which help them develop software at better quality and faster.

However, the fundamental question I am trying to answer is how do you reconcile competitiveness [quality at a price I presume] and profitability. Some of the suggestions regarding the same are as follows:

1. One is to offer a contract where the client pays per iteration. After each iteration they choose whether to keep going or stop so rather than locking them into a 6 month or whatever project they can stop if they are not happy after 2-4 weeks. That way the sunk cost is lower and their deadline is ages away so they can give the job to someone else with little problem. Usually 1 or 2 iterations is enough to convince them to keep going though. [from Dave] But none of the projects like Youtube, Google or any other successful project had full functionality in the first go. So one should underbid, but not on price but on functionality. We should do what agile does best: deliver an utterly minimal system that still meets the PO goals in the shortest amount of time. Stress the fact that they could be seeing results in as little as 3 weeks into the deal.

2. Emphasize the quality aspect of Agile teams, any past knowledge by which you can demonstrate how going Agile helped a project in the longer run would at least bring customer to the negotiating table.

The problem (or requirement) with [1] is that you need to orient your proposal more towards how it will help the customer to get some basic features out first. You will truly need to get into customers requirements and uncover the risks that a fixed price project would pose. Preferably you can convey that a minimal risk does exist, but you manage to tweak the requirements so that you’re really the only party that can sensibly deliver anything suitable at all. That way you don’t have to compete on equal terms on the bid.

The problem (or requirement) with [2] is that you need to manage knowledge internally very well. Not only should you demonstrate how your past knowledge in a field would help you suggest/ build a better product but also demonstrate how it has helped you do so in the recent past. The difference is important to realize.

Having said the above, it is also probably important to realize that not all customers are good customers and there are some you could do without. Whether or not a customer fits this bill is something that only a particular organizations context determine. On most customers, you need to work on making them understand why you recommend going Agile and T&M basis.

It is also important to have the right people articulating this message. A sales staff that can tell customers to go to hell in a way that they look forward to it is just ideal.


Agile Estimating – Part C

Posted in Agile, Business Value, Estimates with tags , on May 15, 2007 by vikramadhiman

A client recently remarked to us – “You have made us very expensive. I lost a deal when the client came back and told me that you are twice as expensive as your competition”. You obviously wonder, how are others able to do things in half time? Why are we not able to do it? And because we are not able to do it, we can’t estimate lower as well? Then how are others able to estimate lower and complete it in less time as well?

Is it a factor of more efficient developers or cheaper resources or both? Efficiency would probably be a factor of the quality of resources and whether or not can they help us [team/ organization] become successful. However, if we consider that developers themselves would be efficient/ profitable without any organization commitment and involvement in the same, we would be missing an important parameter in the analysis. How do we make a fresher a productive/ efficient resource? Do organizations make/ break people into bad or good performers by their culture?

Agile focuses on team empowerment and responsibility. The idea behind the same is that people who are near to the core of the problem would be best able to do a particular work best. Organizations should focus on an empowered, charged, learned, learning and motivated workforce. The above are also the part and parcel of the culture of an organization. An organization that does not take competitive edge as its mantra can not succeed in the long run. Its the quality that counts and decides metrics for productivity and efficiency. Quality comes from quality people – the best talent is attracted by the best talent and it performs in the right environment.

When we talk of estimates, we must also talk of organization culture and competitiveness. The best method to do the same seems to be continual learning/ empowering of the teams to define a culture that makes it competitive. Its not client’s business sense that Agile teams needs to embrace but organization business value needs to be factored into their performance as well.

Agile Estimating – Part B

Posted in Agile, Business Value, Estimates with tags , on May 7, 2007 by vikramadhiman

We have been trying a new technique over the last few weeks with regards to our estimates. Rather than get an expert comment on how long they think a project will take [in number of hours] we have been asking them to estimate specific activities in the project:

a. Business analysis – the scope of effort in a project is described and documented. This includes prototyping, wireframing, use cases, stories, backlogs and occasionally technical specification documents
b. Development – how many developers for how many months
c. QA – How many testers for how many months
d. Graphics designers – how many design elements/ design scope and how many designers for how many months
e. Project Manager – scope of the project/ timelines and per month time to spent by the PM

This has made our estimates go up by at least 80%. Of course most of our clients do not see the bright side of right estimation at present. We are trying to find the right kind of clients. Of course, we have yet to ask the question – is the right estimate how much time we think it will take us or how much time it should take us.

Agile Estimating – Part A

Posted in Agile, Business Value, Estimates with tags , on April 28, 2007 by vikramadhiman

<a href=”; mce_href=””&gt; <a href=”; mce_href=”; >

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 and the game itself is available in a web based version at

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 …