#NoEstimates, just value!

I have written about #NoEstimates earlier. You can find those blog posts here. Now it was a while ago, and I felt it was about time to share my new learnings. I have earlier read and reviewed ”The Nature of Software Development” by Ron Jeffries, and it has influenced me a lot! In fact it inspired me so much I had to write an email to Ron. Guess what, he replied to me with a post on his blog! In the book it’s said that value is ”what you want”. But after reading his brilliant text about the young man who couldn’t decide which one of two girls to marry, I have personally revised it to value is ”what you need to do”. 

The Value Matrix

I created the value matrix to focus more on value than on cost. On the X-axis you have cost (low/high), and on the Y-axis you have value (low/high). Pretty simple.

Usually the focus is only on cost

In the organizations I have worked for during my career the focus have been primarily on cost, before value. When talking about work to do, the discussion usually goes:

• ”Oh, this is a five minutes thing.”
• ”This is a oneliner in the code. Consider it already done!”
• ”This is a trivial fix.”
• ”Oh no, this is too much work. No way we can do this.”

We focus on cost, but what about value? That is not considered in the discussions.

We shall focus on value first!

Leaving the cost out of the discussion for a while, we can focus on the one thing that is more important. Value to bring to our customers! Value then falls under two categories:

• ”Low hanging fruit” – High value to a low cost. These are the things that we just must do!
• High value but to a high cost – We should dare to do these things as well and not neglect them with ”This is too much work” (as in the example above). If we sense ”too much work” (an experienced developer would now this, without making an detailed effort estimate), we should instead try to make work ”smaller” by simplifying it. Maybe all (or a little less) value than originally thought can be delivered, but with a lot less work if we think for some more.

The tricky part is of course to quantify value, it is much harder than it is to quantify cost (”I estimate this function to take 2 days to do”). So, can this be done in reality?

#NoEstimates, just value!

We have one team that has been running for over a year, using these premises: no estimates just value. Meaning that they don’t perform any effort estimation at all (in any ”currency”, be it story points or days). They do release planning where they consider a short backlog of things to do that are categorized in three levels:

• Promised – Have been promised to customer(s).
• Needed – Is deemed needed to be fixed.
• Desired – Desired to be fixed, meaning it will be fixed if time allows it.

You can see this as different levels of value, things that are externally communicated and promised to customer(s) have higher value than things that internally have been deemed needed to be fixed etc.

At the release planning meeting they ”lift in” things to the release from the backlog and reconsider the value (that can have changed over time, depending on how long it has been ”sitting” on the backlog). Then they start to work, and they do it in the order of value (promised, then needed, then desired if time allows). If not all promised are fixed on the planned release date, the release is delayed, otherwise it ships.

Summary

We have been working like this for so long it feels normal, and not worth mentioning. But some days ago I read a blog post called ”Kanban tricks for solving problems fast” by Lawrence Weetman that inspired me to write this blog post. They too, puts value first, and don’t estimate any longer!

All the best,
 Tomas from TheAgileist