Art of Estimation–my thoughts

I read this post by Ian Battersby about estimation and started leaving a comment but it kept expanding so I decided to put it into a post.

Estimation is a very contentious area and fraught with pitfalls both inside and outside of the team.

In my experience developers aren't bad at doing estimating as long as they are fully aware of the domain, the codebase and the actual business requirement not necessarily what they've been asked to estimate, which of course we always know all the time.

Ian seem to be linking estimation of time to do a job with time elapsed rather than time spent on the job due to some of the factors he listed such as fire-fighting, low staff morale, etc.  This is a normal trap to fall into and one that non-technical management frequently do as they equate actual hours with development hours and when given an estimate they don't hear estimate they hear commitment. This can be combatted in various ways the most accurate can be recording actual time spent during a day, I know as dev's we hate to fill in timesheets but in the past I have used it to help teams prove that the estimates being given were accurate for work but the elapsed time was different due to outside factors e.g. support.

This is where points based or relative estimating has been proven to be more accurate than other forms of estimation ( have a look at this study here and multiple studies listed on slides 19 & 20 here) if we all look to use this and educate the rest of the business about what it means we can provide better information to the sales process (more on that in a mo).  Yes there are challenges with calculation of calendar time but with good velocity being recorded or accurate cadence it can be done and then you don't have to guestimate (which IMHO is one of the most dangerous things to do with any business person as that’s the figure they always remember).

Ian also says:

"Factoring the skill level of our assigned developer against our points-based estimate will certainly provide foresight"

which is great except what happens when the developer in mind doesn't get to do that story? the team should point work so that they are happy as a whole as to its size regardless of who is to do it  which helps staff morale as it means that you are unlikely to get staff getting stressed trying to complete a task in a timescale they know they cannot do it in due to their skills/skill level.

Following agile principles for the costings we don't want to break down the story into tasks as we know that the requirements are highly likely to change and any assumptions made now could cause grief in the future.  It is far better to work in conjunction with sales and your points estimate to work out how long it the team thinks it will take to do the task and then adjust day rate etc appropriately if necessary to enable you to avoid death march projects.

I like Ian’s approach on having a skills matrix for the team and have done similar in the past utilising the Dreyfus model of skills acquisition to make this a lot easier.

I was shaking my head at the recipe, I understand the motivation behind it and why if it works you can provide evidence to management for hiring of more staff or training.  Unfortunately I don’t see as being that easy and stating to management that if you have an increased training budget you can reduce the cycle-time by 30% a very dangerous thing to do, ballsey but dangerous.  Do I have a better idea? To be honest I don’t, I generally like to sit down with the management look to where the Co. wants to go and what is needed to get there.

That about wraps up my thoughts on Ian’s post which I thought was a good one and Ian is defiantly somebody you should add to your blog list.