This is my take about the article from Phillip Starke about roadmaps, and particularly about avoiding exact dates when giving estimates.
I couldn’t agree more with Phillip about exact dates:
In recognizing that we cannot predict the future, I encourage you to avoid exact dates wherever possible.
You cannot predict the future, and while software development claims it’s a “science”, I often see some black magic when teams try to guess a delivery date.
Agile to the rescue
That’s one of the goals of Agile, to break the famous “Iron Triangle” of project management.
Since it is almost impossible to deliver a project on time, on budget and with full scope, Agile offers to take the scope as the main variable and prioritize the value delivered to the customer.
Then, in the Agile toolbox, we have some practices around estimating, such as the now famous Planning Poker, but it’s still based on gut feelings. Gut feeling is subjective and situative.
It’s all about communication (again)
Giving the customer a delivery date is often a source of stress, because you can’t be wrong. If you are late, either you’ll have to:
- Pay for the extra costs of the delay
- Or ask your customer to do so, which is not an easy ask
But how to easily engage in a fair discussion about the delivery dates.
After some missing deadlines on my projects, I started to simply give a range instead of an exact date.
I think we can deliver this project between the 1st and the 20th of June
Exact dates look like contracts, and they seem immutable, you can’t change them.
While giving a range of dates, you already express some doubts, and it shows your customer that there is already a part of uncertainty.
Statistics FTW!
While this first approach has improved my way of announcing delivery dates, since it sparks interesting discussions with the customer, it was perfectible.
You probably already know that you need to check the past to predict the future. Scrum tells us that with the Velocity: by measuring each increment on each Sprint, the promise is to forecast what we could ship on the next Sprint.
While I find it great in theory, it’s hard to apply, especially when starting on a new project, or when the team changes.
And I got my Ah Ah moment when I attended a Lean conference a while ago.
The idea is simple, and it’s effective to communicate delivery dates to the customer: just add a percentage to your estimates:
There is an 80% chance that we’ll reach the goal between 4 and 5 months.
Yes, simple as that.
And if the customer has a hard time understanding the uncertainty, I usually say: “There is a 100% chance that we’ll reach the goal between tomorrow and 20 years from now.”
Usually, we find an agreement 😜
Header photo by Harrison Haines