Yorgos Saslis great article! Thanks for sharing. I think you made lots of useful points.

I agree with what you’re saying about the planning argument. But I think there is also another aspect to consider. We are often asked to estimate often before we even know what the solution (eg. requirements and features) is. Hence, encouraging us to jump to solutions when we might not yet even know the benefit which we would like to deliver (https://goo.gl/CXBXoY).

For the cost-based decisions, from my experience, I think we’ve been asking the wrong question here. Whilst estimations might be a helpful piece of information in the cost-based decisions, stimations of effort shouldn’t be the key focus of how we decide how much to spend. The name itself lends is a clear hint that we need to be doing an economic analysis based on how much we’re willing to invest, the expected/predicted revenue and the expected ROI (see more here: https://goo.gl/xY6cCh). Also tied back to my previous point in the paragraph above, we often don’t know what the solution and requirements will yet look like which makes estimations even more difficult and likely to be an activity for the sake of doing so.

Would you mind elaborating further on the tracking of velocity? How might the sorting backlog items into the “4 categories/buckets” (aka Time Unit Buckets) help us with reducing error margins, getting approval to spend time/money on the backlog items and which backlog items will be most beneficial to the business in terms of revenue, retention and stability/quality/scalability of the software? Whilst Time Unit Buckets (aka Ordinal scales) are useful for observations, what does it tell us other than one card/task is more effort than some other cards/tasks?

Also, out of curiosity, have you been involved with such estimations? If so, how long is an estimation session and how frequently were they held in your experience?

Looking forward to your thoughts.