If doctors make the worst patients then I am convinced that developers make the worst estimators; only in the software industry would business process delegate such an important responsibility without first educating its staff.

How do I know this?
… because I’m absolutely terrible at it!

In the previous post in this series I stated we have a responsibility for imposing our experience on business process to ensure we “are given time to build our cathedrals” – good estimating is an essential first step.

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 +/- 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 %2B2% 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