Honestly? No, not really.

To be clear, so there’s no misunderstanding, I understand what you’re saying, I’ve seen teams using those approaches. I’ve even used them myself and given same sort of explanations.

But I never felt comfortable with it, I always had a feeling they are just a very convoluted attempt at avoiding difficult discussions. And an attempt that (IMHO) fails rather badly, making the discussion only more difficult.

Let me try to explain…

From a ‘production’ perspective it’s about resources required to deliver

• Developing a piece of software is a process consuming resources (same as any other production process)
• Developers are not resources, they are suppliers of resources and essentially they supply their time, a limited and single-use resource (each minute someone spends working on story XYZ, is a minute which that someone cannot spend on something else)
• Developer knowledge, experience, etc are ‘quality attributes’ of the resource supplied, they influence the value of the resource (some devs you pay more because “they can do twice the work of the others”)
• The unit of measurement you use does not alter what is being measured/estimated (you can measure height of tables using inches, centimeters, feet, matches, footballs, … no matter what unit/scale/precision you use, what you measure is height of a table)
• In other words, no matter what unit you use, from a production perspective you estimate how much time will be spent to develop the story

From a ‘customer’ perspective it’s about expectations on what is delivered

• For a customer the story and resulting piece of software is only a means to satify a need they have
• To satisfy this need the software must of course enable to do what the story describes, that’s why the story exists in the first place: to specify what functionality is expected
• But there’s another condition too: to be able to satisfy the need the software must be available for use
• Hence customers also have expectations on time needed to develop, not in terms of resources spent but in terms of how long they will have to wait until they can start using the software
• In others words to answer this customer expectation you need to estimate how long it will take to develop the story

One issue that (I think) I see is that often these two views on time are often confused… Resource time spent on work is not the same as time work is in process.

Another issue is that estimations are by definition never exact, there is always uncertainty involved (and the higher the complexity is, the more uncertainty there is on the estimate)… But on the whole people do not like uncertainty, many (most?) do not even know how to deal with it rationally.

I can understand some attempt to avoid the 2 types of time confusion by use of a ‘neutral’ metric such as story points for resource time. But I have my doubts, certainly when people start to talk fibonacci etc… I have found using a simple ‘Easy’ / ‘Medium’ / ‘Complex’ scale (with simple but clear criteria to classify stories) often works just as well (and is easier to interpret)

And like it or not, you still need to deal with the time in process expectations… Story points (or other neutral metrics) is not the way to do that part (unless you want to sustain or even increase the confusion). Imagine going to a garage to get your car service, you ask when it will be ready and the mechanic replies it will take 3 tires…