Software Project Estimation

Great article by David Anderson on project estimation – he is an agile guy so he tends to a be a little harsh on the traditional PLC estimating techniques – he talks about alternative methods to estimating based on Agile and FDD (Feature-Driven Development). My experience with project estimation is that most of the teams (myself included) don’t know how to do it really well and so we guess and then work ourselves to death because we always estimate optimistically (or get surprised by the extreme amount of process that gets in the way and slows us down). David speaks to the waste of effort from a customer perspective and a developer perspective in estimating effort because the end result is numbers that don’t mean a whole lot. On the other hand he says working the requirements and breaking them down into pieces that gives us a work detail as well as helps us in understanding more completely what the customer is asking for. So focus on analyzing the requirements and outputing information surrounding them rather than focusing on some number that your are supposed to give.
There is one thing from what David says that I don’t understand in relation to Agile (specifically XP) development efforts – don’t you buy definition when you go through planning games – identify how many tickets (or whatever you call them) are available and how much each use case (feature) defined by the users will cost in tickets? To me that seems to be the same form of estimating that David is denouncing.
I drill down into David’s previous post on agile estimating as well as the comments (which you should also read because it has some good stuff in it as well) – he expounds a little more that his estimating should be more lightweight and should deal in terms of number of bugs that someone can do in a specific window (what he calls velocity I think) with an accounting for variation in velocity. I suppose that maybe this speaks back to the goal of the FDD model and XP to break things down in pieces and interate quickly over the smaller pieces of work thus supporting a lighter weight estimating cycle. I am certainly not an expert on any of this – but I am learning more and more all the time which hopefully helps me long term – one of the challenges is changing the culture (or adjusting to use a less negative term!) to be more software oriented and leveraging the software development knowledge and best practices within the teams that I work on.

Why Estimates are Muda

 

Advertisements
This entry was posted in Technology. Bookmark the permalink.

One Response to Software Project Estimation

  1. Unknown says:

    Bryan,Accounting for the variance in velocity or productivity (depending on the estimation camp your in . . .) is the a significant part of the discussion of estimation.  I interviewed Phil Armour on estimation on my podcast and he suggests that a lot of the variance is that a function of not being able to know how much we must learn.  How much knowledge capture that is required to create the functionality being requested.  An interesting philosophical view of software really represents and by shifting the paradigm provides a new way to think of estimation.  The podcast is the Software Process and Measurement Cast (www.spamcast.net).  I would be interested in your take!

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s