Better estimates: Trivariate Estimation.

Tell me if this story sounds familiar.
You sit in yet another meeting. Listen to business stakeholders talk about what they want. Then you're straight into another meeting where you sit down to come up with an estimate. Eventually you emerge and present it to the business stakeholders. They take this number as fact, as a concrete answer for how long this piece of work will take. Of course in the end the number is not representative of reality. Someone gets upset, because you’ve gone over budget, missed a deadline or simply because reality didn't match with the image in their head. Postmortems are done. The next project starts and the cycle repeats. Eventually people start padding estimates. The whole process breeds distrust, distrust kills teams. Familiar? I thought so.

What can we do about it? As an industry we’ve tried a few things. Solutions such as estimating in comparative complexity units like story points hasn't solved this problem, nor has only having experience team members do the estimation, or having the whole team estimate. The current buzz word in estimation is #noestimates, I feel that this is just hiding the estimate somewhere. Just like the cloud is someone else’s computer, no estimate means someone else is estimating your work, for you, without you. My answer to the estimation problem is the trivariate estimate method, rather than using no estimates, use more.

I was introduced to the trivariate estimate method reading The Clean Coder by Robert C.’Uncle Bob’ Martin. I have since used it in the real world and found that it has greatly helped with the quality and acceptance of the estimates I have provided.

The idea is simple, three estimates, the Best Case, the Worst Case and what you actually think it’s going to take:
  • Think about how long it’s going to take, write that down. This is the Normal Case.
  • Now imagine what could go wrong, everything, you’ve had a terrible night’s sleep, the coffee machine is broken, the work is only half specced, last minute changes come through, and people. Just. Keep. Bothering you. How long will that take? Write that down. This is the Worst Case estimate, if it looks too high then it’s probably in the right ball park.
  • Now think about what would happen on your best day, everything goes great, you’ve got all the details, you slept blissfully, the coffee machine is putting out better coffee than it has in years, and the work environment is perfect. How long will that take? Write that down. This is the Best Case estimate.

With these three estimates in hand there is enough data to compute some meaningful information. A quick warning if you give these estimates to business stakeholders directly they are almost certainly going to be misconstrued. Some people will look at the upper estimate and say “Whoa Nellie! That’s too high. Do it again”, others will look at the minimum and say “Yeehaw! Let’s pile some more work in.” either way the goal of providing a more realistic and trustworthy estimate is out the window.

The computation to turn these numbers into more useful information is (Best Case + Worst Case + 4 x Normal Case)/6 this gives the Final Estimate.

If you think about estimating something that isn’t software development, let’s say driving across town you’d never say that “I Estimate that it will take exactly 1 Hour 17 Minutes and 12 Seconds” You might say. “It’ll take an 1 hour and 15 minutes, give or take 10 minutes depending on the traffic.” This “give or take number” is the Error Margin. The Error Margin can be generated using a very simple function (Worst - Best)/6. The Normal Estimate plus/minus the Error Margin should account for the majority of the estimates if we presume a normal distribution.

By being able to give not only Final Estimate but also a indication of the confidence of the estimate, provided by the Error Margin, and being able to communicate the Worst and Best Cases allows business stakeholders to make decisions with a better understanding of the full picture. This improves communication between the teams and the business stakeholders. Allowing them to understand the estimate and it's stability.

Better communication and understanding, breeds trust. Trust grows healthy teams. Healthy teams make better software.

Postscript:

As with anything, this estimation tool won’t solve all estimation problems. You need to be pragmatic with the use of any tool. Trivariate Estimation is certainly not the correct way to estimate for a number of situations. However, if you need a way to improve your estimates so that the that provide more meaningful information to base decisions on then this tool may be what you’re looking for.


Important Calculations

Estimate Value = (Best + 4 * Normal + Worst)/6
Error Margin = (Best + Worst)/6

Comments

Post a Comment

Popular posts from this blog

Solving `Empty reply from server` in DotNet Core

tldr; If you’re getting  curl: (52) Empty reply from server  check that you’ve configured Kestrel correctly. Long version I’ve started playing with Dotnet Core and Docker and have had a few issues getting started. I’ve had a little bit of experience with Docker, though only a little. I’ve worked with DotNet previously but never with Core. Environment The setup I’m using is a Windows laptop running Vagrant. Via Vagrant I’m running an Ubuntu Virtual Machine with the Docker run time installed. Feels a litle like inception. Key Problem The key problem that I’ve had getting started was having my Docker container not responding correctly to my curl commands. I get this: curl: (56) Recv failure: Connection reset by peer curl: (52) Empty reply from server Given that I’m not all that familliar with Docker or Dotnet Core I decided to remove one of the variables and set up a simple Express app in a different docker container. This validated that the commmand I was using to run
Read more

Testing functions that use local storage with Jest

Testing functions that use the browsers local storage API seems easy when you know how. Here's a quick run down on how to mock it out with Jest if, like me, you're not familiar with how to test it. In the end it's very little code. Consider the following TypeScript code. import { get, save, key } from "./storage"; describe(save, () => { let setItem: jest.Mock; beforeEach(() => { setItem = jest.fn(); Storage.prototype.setItem = setItem; }); it("should call set item with predefined key and json object", () => { const valueToStore = { value: "toStore" }; save(valueToStore); expect(setItem).toHaveBeenCalledWith(key, JSON.stringify(valueToStore)); }); }); The key lines are in the beforeEach call where the setItem function of the Storage prototype is assigned to an instance of jest.fn() . This allows us to make assertions on what is passed to the local storage setItem API.
Read more

Building a verify JWT function in TypeScript

# Verifying an RS232 signed JWT JSON Web Tokens (JWT) are used as a way to verify the identity of the caller of an API. **The best way to verify a JWT is to use a verification library.** I wanted to have a look at some of what those libraries are doing under the hood by putting together a function that will return if a given token is valid. In this blog I'll go through what I have done to get a validation function working. To simplify things assume: - That the signing algorithm is RS232 all others are considered invalid. - That the public keys are available on a JWKS url provided to the function eg [https://klee-test.au.auth0.com/.well-known/jwks.json](https://klee-test.au.auth0.com/.well-known/jwks.json) - I only want to know if the token was signed by a key available at the above url. I wont be checking if the token has expired, if the scopes or other claims are valid. # Break up the token A JWT is made up to 3 parts. The first thing to do in validating the token is to brea
Read more