Overheard

Product Owner: That feature is about 10 ideal hours – we’ll have it for you in 6 weeks.

Customer: 10 hours?  How about tomorrow?

Product Owner:  Not 10 hours, 10 ideal hours, and our next planned delivery is in 6 weeks.  We could do it sooner, but that would be an out of cycle delivery and we would have to drop a few other features we promised

Customer: Where does the 10 hours come in?  It seems like this feature should cost about $2000, why is it really costing $50,000.

Product Owner:  It is not just 10 hours; it would be 10 hours if we had nothing else to do.

Customer: What else are you doing?

Product Owner:  Well, the 10 Ideal hours does not include department meetings, time to review other people’s code, sick leave, vacation, answering questions, …

Customer:  Seems like 6 weeks is a long time to do 10 hours of work.

My Toughest Critic

I was trying to explain ideal hours to my wife (a brilliant systems engineer) and she was looking at me like I was crazy.  “If it is only 10 hours of development, what task order are you going to charge for the rest of the time? (She works on government contracts).  “You know, department meetings, reviews – all the stuff you do that is billable, but doesn’t contribute to the final product.”  “Then it is not 10 hours, you are counting wrong.”  “No, ideal hours are more a measure of size than duration.”  “Then you are using the wrong units.” (She is also a physicist).

What is in an Estimate?

This brings us to a common estimation problem – what is in the estimate?  Sure, we want to distinguish between size and duration (another reason to avoid units like “hours”), but even when talking about size – what is in scope and what is not?  Do we count the “size” of the review?  What if this is a complex algorithm that requires extra levels of review?

Another set of Terms

I apologize for adding new / different terms to the mix, but this is what I have found to work with several customers:

Unit of Work (UoW) – 2 hour to 2 day product that is observable and testable

Feature – something useful to an end user

Capability – a group of features together that provides significant value to an end user

Of course there are problems with this – what about infrastructure and frameworks?  We define Infrastructure as one of the end users to make this fit.  Sometimes Features and Units of Work are indistinguishable, so we remove one level.  We adjust as needed to make it work.

Back to the estimate

We estimate UoW in Dev Points.  The UoW is complete when the code is complete, reviewed, has a set of successful automated unit tests with 80% line and 80% path coverage, has no Static Analysis Warnings or Errors (FxCop), is checked into the trunk, all automated system tests have been updated and run successfully, and all install scripts and procedures have been updated. 

On one of our current projects Dev Point are roughly equivalent to actual hours – 8 dev points takes about a day, 13 dev points about 1.5 to 2 days.  This was discovered, not mandated – several of us made estimates in Dev Points, we discussed them and chose something.  After about 3 months the calculations showed a dev point was roughly the same as an hour.  If something looks like 34 points we will try to break it up into pieces that can be completed in 2 hours to 2 days.

Feature estimates are just rollups of UoW.  A feature should be able to be completed within a two-week iteration.  This is one of the most difficult tasks – breaking Features and Capabilities into UoW, managing dependencies, size, and scope.

Capabilities are generally estimated with Story Points before any real decomposition into Features and UoWs is done.  This is done before a planning meeting to get a rough order of magnitude of a capability so proper trade-offs can be made when prioritizing capabilities.  A rough mapping between Story Points and Dev Points can be calculated over time.

Now I understand Ideal Hours, I think the ability to calculate velocity is important to improving our estimates.  I just think using units like “hours” to communicate size is confusing.  I don’t like to overload method names for the same reason – it is confusing.  I generally like to use Development Points – probably a soon to be overloaded term, but so far it is unused.  I like to use the Fibonacci series (1,1,2,3,5,8,13,21,34, …) as the domain of values for Dev Point Estimates, not just because I am a mathematician, but because it makes sense.  The difference between 1 and 2 is significant; the difference between 19 and 20 is not.  Choosing from a set of reasonable values makes it easier – “Is it 8 or 13?” is easier than “Is it 9 or 10?”  And the law of big numbers will eventually help smooth out the averages.  Remember, we are trying to figure out how much we can do in fixed time period.  “Our Velocity is 40 Dev Points per week per person.”

All we need to do is substitute “development points” for “ideal hours” and this problem is minimized.

Since the numbers are arbitrary, pick units that are arbitrarily easy to explain to stakeholders.  I call using things like Chickens, Pigs, and Ideal Hours “Poking Stakeholders in the Eye with the Agile Stick.”  It doesn’t help anyone.