I’ve done two blog posts about #NoEstimates, you can find them here and here. They have caught on substantial interest from you and been given some positive and some negative feedback. #NoEstimates seems to be a controversial topic! Hopefully I can increase the interest even more with this blog post.

Back in school I learnt about the magic triangle of Speed’s law, as I think it’s called in English (that’s what some googling tells me at least). In Swedish it’s called ”SVT-triangeln”.

d = distance

v = velocity (speed)

t = time

Basically it says that if you have two variables given, you can calculate the third. Like:

d = v * t

v = d / t

t = d / v

**An example:** I want to travel by car to another city that is 100 km away, and I’m holding an average speed of 50 km/hour. How long will the trip take?

t = 100 / 50 = 2 hours

This is simple mathematics that all of us understand, what does this have to do with project management?

### The Iron Triangle

Let me introduce you to another triangle that you may also be very familiar of, namely *The Iron Triangle*:

This triangle tells you about the variables to control a project. Basically it works like this, you can have two variables fixed, but the third *needs* to be flexible. If you do a fixed price & fixed scope project, the time plan *must* be variable. If all three are fixed and your project runs into trouble, the quality is hurt (and you will be out of business in the long run).

Now I have a confession to make. I have done estimates on **scope**, for example saying that something is 20 days of work. Then I have made something worse, I have committed to delivery **times** using those estimates… Are you totally stupid? you might say. How can you promise to deliver something in a month (20 working days) knowing that the amount of work is the same (neglecting things like for example external dependencies that the work may have)? Hold your horses a bit, I have been using ”the factor”. What is ”the factor”? The factor is ”some magic thing” that comes from the stomach area of software developers 🙂 A more correct name is *gut feeling*.

To be serious, ”the factor” is something you use to multiply your estimate with to get the delivery time. You can make an estimate of the way from A to B (shown to the left in the picture above). But our experience says that the actual road will be more like the one on the right. We know that we will face obstacles in our way, but we don’t know how many or severe they will be. Imagine there will come a mountain in our way (to visualize an obstacle in our software development). We then have two alternatives:

- ”Go over the mountain” – That will significantly reduce our velocity (and it will take longer to reach our goal)
- ”Go round the mountain” – That will increase our distance to travel (and it will take longer to reach our goal)

So we need ”the factor” to calculate the actual distance we think we need to go. You can call it a ”risk margin”, ”our collaborated knowledge of estimation boiled down to a number”, or the favorite of many π. Examples of values: 30%, 2x or 3.14159…

But what if we could know ”the factor”? Then we could combine the two triangles together!

### ”The Magic Iron Triangle”

s = scope

c = capacity (”speed”)

t = time

Then we can use the same thing, if you have two variables given you can calculate the third. Like:

s = c * t

c = s / t

t = s / c

Now comes the million dollar question, how do you know your **capacity** (or ”speed”)? Without it you can’t use the formulas above. You can of course ”cheat” and replace capacity with ”the factor”, but that is really only the second best option. The only answer to the question that I know of it that you have to measure the **capacity**. Like the speedometer of your car.

Do you measure the **capacity** of your teams? If not, why not? If you perform estimates on scope to give delivery times, what is ”the factor” you are using? Wouldn’t it be better to use capacity, something that you can actually know (by measuring), and even better, do something about (increase it by continuous improvements to your process).

What about the **scope**, do you continuously work with that? Dividing the work into smaller pieces and deliver the things with highest value first to the customer, you may reach a point when delivering the full scope (all functions) is not needed. This will save you from doing unwanted functionality.

### Conclusion

My advices for you is to start measuring the capacity, get yourself a **speedometer** now! Then you should also start to work actively with scope management. Maybe the view from half up the mountain is perfectly fine for your customer, and you don’t need to go all the way to the top?

All the best,

Tomas from TheAgileist

Nice post. The Estimated line needs to address the probabilistic nature of the “path.” It is never a straight line, except in the best naive sense

LikeLike

Nice post, isn’t this similar to measuring velocity (Scrum) and Flow rate (Kanban)?

LikeLike