We finished the previous chapter of Uncovering Work with a Deliverable divided into a collection of correctly sized Sub-tasks. Such a collection 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. Which would lead to a more accurate buffer taken, one of the outcomes of the practice we’re about to explore in this chapter.
Let’s recall that the probability of estimating an effort to be exactly X=x time is almost 0%. And if we ask for one number, we get one number. To overcome this, we better use a three-pointed estimation and extract three estimations from our engineers. Then, in order to get an Estimation with a certain enough buffer, we’ll do some math with PERT Formula instead of relying on gut feelings.
Well, that’s not exactly 100% true. Let’s talk about our guts and brains and some mis-conceptions we might have about the estimator.
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 when Professor Daniel Kahneman did. He has also discovered our “guts” can be focused, tilted and nourished. To get the best of both worlds via a mental voyage. Which is why we took our engineers through it during the process of Uncovering Work. We had them going through the code. To write down the solution by naming Sub-tasks, in order to load and cache the relevant information the instinctual brain feeds upon. It is now ready to give a less inaccurate estimation. Three of them actually, so the PERT Formula can compensate for the instinctual inaccuracy.
That is not the only information our brain holds or lacks. A Junior’s brain would lack experience. That’s why we need a more experienced engineer in the process. Alas, an experienced brain might be too locked in to past experiences to notice the conditions are different than before. According to Daniel Kahnman’s research (and Zen’s Beginner’s Mind), that may lead him to trust his gut estimation too much. The mental voyage has tilted both of them, but maybe not sufficiently. We should still pay attention to this variance.
With all of the above, let’s 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. That would help you to better tailor and change this to your needs.]
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. The process creates 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. Responsibility and committed 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 asked for. Because we didn’t ask, a person would not mention any other likelihoods. Neither the probabilities or the plausible effort. This is the main reason why Plans and Estimations never answer expectations.
In his mind, the average effort is (45% * 4) + (35% * 2) + (20% * 10) = 4.5 days, that is 12.5% off the single number of “4 days”. Worse than that, the probabilities he thinks off are based on nothing, and divert from already known probabilities. That’s where the PERT formula and distribution comes in. The actual probability of the “4 days” single number is 2/3 (66%), the realistic estimation by PERT. The formula expects two more estimations: the optimistic estimation and the pessimistic estimation, each one’s probability is 1/6 (16.67%). Let’s extract those from our engineer.
Ask him “why do you assume that?”. Write down his assumptions, which would be mostly technical. “Everyone agrees with these assumptions?”. Let people speak and let the engineer reconfirm his realistic assumption, “are you sure about that?”. That’s his final realistic estimation.
We’d be extracting his optimistic estimation by doing some acting and exaggeration, tilting his brain again for 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?”. Let’s write it down. And now we need to do this again, tilt his brain again towards pessimistic estimation and ask for it. 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”. Let’s write this pessimistic estimation down. Continue to do so with each and every Sub-task. Yes, it 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. That 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 and we don’t want to find ourselves after two Sprints in the wrong rabbit hole. If we found ourselves afraid of it, maybe more uncovering uncertainties and proper validation is needed.
We now have one estimated Deliverable. Should we continue to estimate other deliverables, originally divided from the design? 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 (considering effort & 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.
Speaking of time, 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. Have the engineer show it to the product manager (or the design owner). Which is why it’s better to first execute UI/UX related tasks. The buffer/variance is for this as well.
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.