Agile Zone is brought to you in partnership with:

Rob is a professional IT specialist with over 14 years of commercial expertise working for small, medium and large enterprise customers and clients as well as local, state and federal governments within Australia and internationally. Of these fourteen years, six have been served in a professional consultancy capacity, three as a project manager and eleven years in professional software engineering and architecture. Rob is a DZone MVB and is not an employee of DZone and has posted 57 posts at DZone. You can read more from them at their website. View Full User Profile

Estimating on an Agile Project

05.10.2013
| 3153 views |
  • submit to reddit

If you’ve ever had any involvement with an Agile project (whether it was “pure” Agile or not), you’ll likely have encountered the beast which is effort forecasting and analysis.  This drives the initial estimate of the amount of work which your team thinks it can deliver within a given period.

Agile sprint
Example of a scrum style sprint[source]

It doesn’t really matter how big your project is, sizing up the amount of work which can be produced is a time honoured tradition, but how do you know if you’re even in the ballpark of getting your estimates right?

Over at ThoughtWorks Studios, Martin Fowler (and others) have spent significant time and effort in trying to document some conclusions about this very topic and a PDF white paper can be found on the ThoughtWords Studios website.

It’s hardly a light read – at 32 pages – but can you really afford to take estimation lightly?  In a world of commercial agreements, balancing customer or client expectations and attempting to meet tight delivery timelines, getting your estimations accurate is a key step in delivery.

However, in my mind going into this document, it really helps to have a decent view of what it is you are trying to build.  The more uncertainty going into any kind of sizing or storyboarding exercise, the rougher the estimation or analysis is going to be. 

There’s no silver bullet, one-size-fits-all methodology at play here, however this document is a really good read if you are looking to canvass different views and opinions about how to set expectations around Agile delivery.  Be prepared to have your designs challenged, and to field changes as they can (and do) present themselves!

If you aren’t quite ready to dip into the minefield which is Agile planning and forecasting, perhaps you’d find value in another e-book from ThoughtWorks – “How do you develop a shared understanding on an Agile project?”.  Remember, for an Agile project to succeed, everyone needs to play their part – the methodology isn’t just for programmers!

For those who haven’t already gone to visit the ThoughtWorks website, here’s a direct link to the PDF.

Further reading:

Published at DZone with permission of Rob Sanders, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)