We finished the previous chapter of Uncovering Work with a Deliverable divided into a collection of correctly sized Sub-tasks. Such a division is valuable to a more accurate Estimation. As the smaller and well-defined the Sub-task is, the smaller the mean and variance of the Estimation would be. And as such, it would be a more accurate buffer taken. Eventually all leading to a more accurate Plan.
In this chapter, we’ll explore how do achieve such Estimations. But first, we need to understand what it is we do wrong.
When we ask an engineer for an estimation, he’d give us exactly one number. The odds of that number to correctly estimate an effort is almost 0%. Instead, in this chapter we’ll learn of three-pointed estimations. Out of it, with some mathematical tricks, we’ll create a certain enough buffer.
Sounds much better than relying on gut feelings. But those still get in the way, because we still have many misconceptions. About our guts about our brains, and about the one who estimates.
A Mind Divided
The Nobel Prize Winner, Professor Daniel Kahneman has proven we estimate with our instinctual part of the brain. It is less accurate than our logical part of the brain, the one we use to do math and solve engineering problems. Whether we like it or not, it’s our guts that do Estimations, even the three-pointed ones. It is inevitable, so we be better not give up but give in to it.
Fortunately, that’s exactly what Professor Daniel Kahneman did. He also discovered our guts can be focused, tilted and nourished. To get the best of both worlds via a mental voyage. We had already taken our engineers through it, during the process of Uncovering Work. We had them going through the code. We had them writing down the solution by naming Sub-tasks.
We loaded and cached their instinctual brain with relevant information. Making it ready to give a less inaccurate estimation, on top of an even more accurate three-pointed estimations.
The mental voyage has tilted both of them, but maybe not sufficiently. So lastly, we’ll throw in some math to overcome all these instinctual inaccuracies themselves. Three birds with one stone.
Okay, let’s get down to business and do some actual estimations.
[Note: this is not the only practice out there, nor am I saying it is a best practice for you. You know best. At the very least, follow and understand the principles described and how it fits in the bigger picture of Planning. ]
Phase 1: Estimation
Let’s take the collection of our correctly sized Sub-tasks we’ve gathered while uncovering work, and add three columns to it, one for each of the three-pointed estimations.
| Deliverables | Sub-tasks | Optimistic | Realistic | Pessimistic |
| Allow free-text search | A | |||
| B | ||||
| C | ||||
| D | ||||
| (Another deliverable) | ||||
| (Another deliverable) |
The engineer with the already tilted brain should be the one to estimate, and estimate his effort. Execution is tightly coupled to his experience and his capabilities, which are already reflected in his estimation. That is his to do.
It will create a sense of internal responsibility, instead of someone else imposing it on him. If we recall the The Yerkes-Dodson law, this is a way to apply the right pressure needed for effective work. With responsibility, committed and owned effort.
One Sub-task after the other, we should ask him “how long do you think it’s going to take?”. He would give us a number, 4 days. When asked so, a person would give us what his guts thinks is the likeliest effort, with the highest probability. Not even the mean/average.
4 days is the one number we’ve always been asking for. As a result, no one mentions any other likelihoods of plausible efforts. This is the main reason why Plans and Estimations always fails to meet expectations.
In an engineer’s mind, the average effort is 4.5 days = (45% * 4) + (35% * 2) + (20% * 10). The average not given is 12.5% off the single number of 4 days. Even worse, the probabilities he thinks off are based on nothing, and divert from an already known distribution.
Time to use the magical math we’ve mentioned before, named the PERT formula. The actual probability of the 4 days single number is 2/3 (66%). We call it PERT’s realistic estimation of effort. PERT is one of the three-points estimation methods. It requires us to extract two more numbers from our engineers – the optimistic estimation and the pessimistic estimation. Each one’s probability is 1/6 (16.67%).
Ask “why do you assume that?”. Write down the engineer’s assumptions, which would be mostly technical. Ask around if “Everyone agrees with these assumptions?”. Let them speak and let the engineer reconfirm his realistic assumption, “are you sure about that?”. That’s his final realistic estimation.
To extract the optimistic estimation would require do some acting and to over-exaggerate, to tilt his brain again towards it.
“It turns out this assumption is correct, but it might be easier than we thought”. And now tell him of some scenarios, such as “you coded this in one shot without bugs” or “this package was easier to install” or “it required less tests than that”. Ask him “if it turns out I’m right, how long do you think it’s going to take?”. The answer would be the optimistic estimation. Let’s write it down.
And now we need to tilt his brain at the reverse direction, towards the pessimistic estimation. This time with dire scenarios such as “it turns out the code is more complex than we thought”, “this integration would be more complicated than expected”. Ask for a number and write it down.
Continue to do so with each and every Sub-task. Yes, this process may take a few minutes.
Once done, we should convert hours into days (8 hours per day) and calculate the PERT weighted mean and PERT weighted variance (easily done by Google Sheet).
A Sub-task estimation with a certain enough 95% probability = AVG + 2STD.
For our example of 2,4,10 it would be 3.33 + 2 * 1.33 = 6 days. It is 33% more than the initial number of 4 days. Don’t forget we made up these numbers, but as we do it with each Sub-task the difference between gut feelings and PERT estimations accumulates to the entire Deliverable.
Phase 2: Pause, Review and Feedback
We’ve ended up with a table full of estimations. The first Sub-task estimation is “we are certain enough it would be done up to 6 days”, not “I think it’s exactly 6 days”.
| Deliverables | Sub-tasks | Optimistic | Realistic | Pessimistic | Mean | STD | 95% estimation |
| Allow free-text search | A | 2 | 4 | 10 | 3.33 | 1.33 | 6 days |
| B | 0.5 | 1 | 2 | 1.083 | 0.25 | 1.5 days | |
| C | 1 | 2 | 4 | 2.167 | 0.6 | 3.3 days | |
| D | 1 | 3 | 5 | 3 | 0.667 | 4.3 days | |
| (Another deliverable) | |||||||
| (Another deliverable) |
The 95% estimation of the Deliverable is the sum of all the Sub-tasks estimations, and it means “we are certain enough it would be up to 15.1 days”. By saying “up tp”, we properly convey that a buffer exists and it might be done earlier but no later than that. And that is the Deliverable’s deadline for the external customers.
Have everyone around look at it, pause to think about it. See if that sounds reasonable to everyone. See what the longest Sub-tasks are, and think maybe we can shorten it by reducing the content, by changing the design or requirements. See if anyone else has any final thoughts.
If the Deliverable fits a single Sprint, we’re all okay. If not, we might have to be split into several Deliverables and aggregate it into an Epic. It might be split into two User Stories, or to one Technical Task + User Story.
Remember to be wary of Epics that last longer than two Sprints. Remember that feedback is critical. If we’re afraid that after two Springs we’d end up in the wrong rabbit hole, maybe there are more uncertainties to uncover, or proper validations to do.
We now have one well-estimated Deliverable. Should we continue to estimate the other Deliverables? As Change entails Feedback entails Change, once delivered the other Deliverables might change. If we anticipate this will happen, it’s better to put it to rest for now. It might be a waste of time to dig deep into it right now.
If we wish to choose alternatives between several Deliverables by considering effort and value, we can go ahead and estimate them as well. Same if we see that we still have a capacity for more Deliverables in the upcoming Sprint.
However, we should be aware that Estimations expire. They are valid only for the current state of the system and the current experience of the engineer. As both continuously evolve, the longer time passes between the estimation and execution, the less valid it is. It may take less, it may take more. No one should say “but 6 months ago you said it would take up to 7 days!” and expect the Estimation to still be valid. Estimations are tightly coupled to timing which is tightly coupled to value.
Phase 3: Execute and Stand Tall
Have everyone commit to these Deliverables, Sub-tasks and Estimations. Let them say some last words. Add the Sub-tasks and Deliverables to the Committed Plan. Get the work done. Convey that the Deliverable would be done up until the Sprint’s end, not at the exact end of it. Nobody would mind it being delivered before the deadline.
We can all monitor the progress on the Agile Board, as one Sub-task after the other is completed. As Sub-tasks are deployed independently, use them as breakpoints to get feedback or to do Code Reviews. Have the engineer show it to the product manager, or the design owner. A good reason to why it’s better to first execute UI/UX related tasks.
Sure, uncovering work and effort takes time. Could be 20 minutes, could be 2 hours. With practice even one engineer can do it on his own. Once done, we can be proud and confident with the result.
We’ve finally reduced the uncertainty of a design and its Deliverables, and predicted as much as we can what needs to be done to get it delivered. And that’s exactly what an actionable Plan needs. Something we can commit to and be sure of its deadline, work, effort and value. And if someone argues from his guts about it, we can honestly say “We’ve done the process, you can see the math for yourself. We’re certain of it!”. We can stand tall behind it.
Thank you for reading this series. I hope it does you well.