Capturing The Geek

Art of Esimtation

Thursday 18 August 2011 at 2:00 pm. Used tags: development, estimation, expectation, management, managing, mani, team

Facing up

I see poor estimation as contributory to many team evils, including:

• Fire-fighting
• Over promising, under delivering
• Low staff morale
• Poor code quality
• High technical debt*

* Don’t jump on this statement - I only said contributory

I have observed many estimating techniques, each with it’s own merits; one common factor has been a varying array of categorisation. Commonly seen as a self-imposed defensive mechanism against later reprisal the categorisation is actually evidence of something we must first accept…

“We must service the needs of the business, including the sales process”

Reaching agreement with your product team on which estimates are provided is essential; it must be based on a clear and written understanding as to avoid later abuse and condemnation.

Categorisation

I believe simplicity is best as it provides a good foundation for you to work with your product team on an on-going basis; an example might be:

Guestimate
Ballpark figure used for internal consideration in gauging business value and basis on which to proceed with scoping requirements; not to be used for providing quotations or setting expectations.

Estimate
Provided by a senior member of the team given sufficient detail in user-story and acceptance criteria format; it is expected this will is 70% +/- of the eventual costing.

Costing
Based on a fully scoped requirement and with any supporting documentation (such as 'use cases'), design and implementation to be considered and a task breakdown provided (i.e. Scrum - first iteration only).

There is one important thing going on here, not only are we protecting ourselves against deliveries made against a fag-packet specification, but we are ensuring we spend as little time estimating as possible whilst striving for high quality. As a side benefit a thorough task breakdown not only shows a considered approach to the business, but also to team members who undertake the work confident they won’t be paying the price for your shoddy estimating - remember staff morale!

Points, not prizes

I was originally sceptical of points-based estimating seeing it as another complicating factor in our rapidly emerging recipe; however it does allow you to abstract the concept of time and tweak retrospectively.

Experience shows that when asking a developer to consider ‘effort’ over ‘time’ you receive a much more reliable estimate, if they throw a “that’s a 100-pointer for sure!” it’s an often based on a simple gut-feeling free of invasive operating complexities of the working day and immediate translation into timelines.

Basing your product backlog on an abstraction of time also allows you to tweak it’s time-based equivalent throughout your retrospectives; for example if it transpired estimates were averaging +2% you could simply optimise and re-calculate. Why do we need time-based equivalent? Remember we are servicing the needs of the sales process, and our product team don’t speak in points, only in prizes!

Dynamics

We must next consider the skill dynamics of our team; let’s not forget we wanted to give team members time to build their cathedrals. If we are to follow the agile principal of cross-functionality whilst (a) servicing the backlog priority of the “To Do” WIP column (Kanban), or (b) fully utilising iteration resource (Scrum), then we must appreciate the impact of task assignment on our estimate.

Most frustration experienced by Product Managers is not because something is taking longer than expected but that there was no warning or foresight to allow them to manage it. Understanding your teams’ skill levels and the impact of task assignments can provide that foresight.

Complexity

Factoring the skill level of our assigned developer against our points-based estimate will certainly provide foresight, but it often won’t account for inherent complexity. As an example I may consider myself quite a hotshot with StructureMap but the anticipated usage will be complex.

These occurrences are often summed up by the post-development cry of:

“Sorry, it just turned out to be much more complex than first thought”

Without considering minute implementation detail points-based estimates often neglect to capture this, even if it was thought that “this one may be a bit tricky!” Obviously we don’t want estimation to involve spiking, anything requiring this would need it’s own backlog item, but we do want to capture that feeling. The simplest way to do this is assigning ‘simple’, ‘normal’ or ‘complex’ to each task.

Rounding up

So if you are still with me you will know we are happily providing the business with:

• Guestimates to help service business valuation and sales process
• Estimates based on high-quality user stories and acceptance criteria
• Costings based on task breakdown with skills and complexity based data

Furthermore upon task assignment we know how long until that particular developer is likely to complete it, and given this foresight liaise with the product team to manage delivery expectations, thus enabling us to freely adopt cross-functionality and knowledge-sharing - remembering staff morale!

Danger Will Robinson!

I can feel you reaching for the scrollbar to compose a rant-based comment; after all I am just over-complicating the issue aren’t I? Bear with me.

Knowing your teams’ skill levels can be a massive positive; remember as team leader / manager you are responsible for their personal growth and skills-based training, not to mention that ‘cathedral’ time you promised them. Imagine if you could run a report that based on your product backlog showed the key-skill areas required for upcoming work; imagine the conversion with your CTO:

“Here is the report clearly showing that with an increased training budget I can reduce the cycle-time of the product backlog by 30%, also resolving our low-resource issue”

… or …

“Here is a report clearly showing that if you can give me a budget for recruiting another head into my team with the following skills I can reduce the cycle-time of the backlog by 20%, and aid cross-team training”

One catch! You’re going to need the data to produce these reports.

Recipe

Using a simple skills-matrix of your team (scoring 0 – 5) and assigning skills and complexity to your tasks along with your point’s effort you have the foundation of your data. Let’s map it out:

( ( (Effort * [PointsToMinValue]) * [SkillsBasedAvgFactor] ) * [ComplexityFactor] )

I can sense your shaking head from here, perhaps understandably because how is this monster ever going to be manageable? I don’t know about you but any time spent creating reports and staring at estimating plans (when I could be coding the next big thing) makes me want to stick pins in my eyes, so we need to automate.

Automate, and automate some more

Your ability to do this entirely depends on your adopted process management software, if you have any at all. Joining my current employer I found Team Foundation Server firmly embedded into their workflow, and despite my love for all-things DVCS it did offer one advantage - a crappy process template engine.

The result of this and some late nights is a collection of custom templates, event listeners, and a one-line class with our recipe formula in it – it really isn’t that difficult - and the wins are fantastic!

Summing up

I suspect most controversy over this post will revolve around the complexity of the final solution, however we must ensure our solution does not limit the scalability of your team and impose a greater management burden on you.

Next time: Bottleneck Ninja
Coming soon: The Holy Grail of Management

six comments

Leave a comment

My comment became so big I put it into a blog post here http://designcoderelease.blogspot.com/20..

Nathan (URL) - 19-08-’11 09:11

@Nathan: Thanks for your blog-reply chap, the more heads contributing to this tricky area the better!

Some points;

Firstly, glad you have better estimators than me in your team!

I’m certainly not equating our time-based equivalent to cycle-time, although in the context of our Kanban maintenance cycle optimising this is obviously one of my primary goals. My estimate, points or otherwise, is solely for the time taken for accomplish that task – just without the ‘estimator’ trying to factor in operational considerations.

Your point about time sheets is very prominent, it’s something I found when I joined the company, but they were poorly maintained. Using the traditional ‘original’, ‘remaining’, and ‘completed’ alongside time tracking utilities (such as TFS Working On) we effectively generate this – and it fits well with the attention span of the average developer

“study here and multiple studies listed on slides 19 & 20 here “

I’m going to take some more time to absorb the studies you linked to, certainly interesting food for thought on first scan. I too agree guestimates can be dangerous but I believe in some business environments they are a necessary evil – just one that needs to be managed.

Making your whole team point work is IMHO infeasible in a Kanban life-cycle, I would agree however making sure the team is happy and agree with the process and format of requirement is essential. Also remember that our skills matrix and formula recipe is aimed at ensuring ‘that’ developer gets the time required in accordance with his/her skill level.

Thanks again for taking the time to reply, I can see this making an excellent conversation piece over our next coffee (perhaps even a podcast!?); certainly I accept your point that if you can get your business to talk in points and not prizes time – then that’s a bigger #winner.

Ian (URL) - 19-08-’11 10:06

I don’t see why software projects can’t be run a bit more like engineering or construction projects. Software is a different medium, but the logistical, analytical and communication problems are more or less comparable… so I think there’s a lot to be learned from other industries. People have been building complex physical and mechanical things a lot longer than building software after all.

I’d be interested to hear about the challenges you’ve had to work around and the solutions you’ve put in place, but that’s probably going to be a lengthy blogpost or coffee conversation!

Johan - 19-08-’11 11:52

@Johan:

I think there is much to what you say, I wonder if anyone else has ever done any comparative research into it?

Ian (URL) - 22-08-’11 13:46

@Johan & Ian here’s a link to an excellent post which details why software development is not and very unlikely to ever by the same as construction or civil engineering http://nrg.im/moPVxR

Nathan (URL) - 22-08-’11 15:52

Ian you’d be surprised how fast you can do relative estimating with a whole team when you get used to it. At prevous place we used to manage around 26-30 stories in an hour, that level of estimation just couldn’t be achieved with more detailed estimation, plus it had the bonus of the whole team being happy with it and management not running round to different developers to get “there take” on it.

Nathan (URL) - 22-08-’11 16:00

Name

Email (optional field)

URL (optional field)

Comment

'cause I hate spambots, you gotta do this I'm afraid
What is the opposite of good? (don't say Microsoft!)

Remember personal info?
Yes, give me a cookie and remember me.

Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.