Home > Agile stuff > How you could deal with early estimations

How you could deal with early estimations

Recently people have been asking me how to deal with so-called ‘expert estimations’ in Agile development. In most organisations where IT is seen as a supplier or cost centre, the business wants to know the costs and the duration of a project before it decides to fund it. This is of course perfectly normal!

The poor IT department is asked to do an ‘expert estimation’ based on the available vision, requirements and any other available information. The estimation is expected to be quite accurate with e.g. a max -10% to +10% deviation. So the IT department adds the necessary buffers and slack to the estimation. As a result the project plan is probably longer then necessary which results in longer projects and less productivity thanks to Parkinson’s Law. The project will also unnecessary claim personnel and other scarce resources for longer periods complicating their use by other projects. Task switching and hand-offs now become a necessity as people must work on multiple projects. It often also results in a project to not start at all thanks to the overestimation!

 So, how could we do this in Agile?

 Well…, what some people do not seem to realize is that in Agile we also provide estimates upfront. In Scrum e.g. we have the estimation meetings where the product backlog is estimated. We estimate just enough to be able to make the ‘right’ decision. We acknowledge that in the beginning of a project, when we know least about it, the estimates could be very inaccurate. We keep on estimating throughout the project increasing the accuracy of our estimations as we learn more about the project. We measure our progress based on actual working features and value added. This enables the business to get valuable estimation and planning info as early as possible to make the ‘right’ decision, which could be to stop the project! We use a project baseline that is based on actual data and progress. If we have 1000 points of estimated work, we work with 2 week iterations and we must be complete in 20 weeks then we must burn 100 points every iteration. This becomes our baseline and is used to measure our schedule and budget variance. We track features completed vs. features remaining, work in progress, feature cycle time and client value added. In Agile we do a lot more planning and we do it throughout the project.

We use the initial estimation to make the funding decision! We then have our estimated schedule, budget and functionality. After the decision to fund the project is made, we use the mentioned metrics and techniques to steer the project and track against the initial schedule and cost estimation. We re-estimate and re-plan based on real progress and provide the business with the most accurate information as quickly as possible.

Categories: Agile stuff Tags: , ,
  1. May 13, 2009 at 7:45 am

    It’s very helpful to use the burndownchart to visualize this.

    Some next steps would be:
    – Money for Nothing
    – Change for Free

    See also: http://jeffsutherland.com/scrum/2008/10/agile-contracts-money-for-nothing-and.html

    Another interesting thing is (with more Agile/Scrum experience in projects) to calculate your ROI based on your estimation points (and customer business value). There is an certain level when your ROI becomes to low to futher implement any user stories from the backlog. A good point to terminate your project.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: