Good Estimates Have S.P.A.C.E.
Specificity, Precision, Assumptions, Confidence and Exactness
A good estimate comes with Specificity, Precision, Assumptions, Confidence and Exactness. It is Specific in its units of measure, Precise in its timeline, detailed in its Assumptions, articulates its Confidence, and Exact in what is being estimated.
Getting to a SPACE estimate isn’t cheap or easy, but once one has been delivered it becomes possible to build atop the estimate and incorporate it into larger plans.
Not all estimation techniques deliver all of these and getting all of these in an estimate can be quite expensive. When we leave out parts of the S.P.A.C.E. framework we take on risk while cutting costs, but not all of these risk are easily apparent.
Leaving out a Letter (or two)
I was once in a meeting where we agreed to spend roughly $2MM of the engineering org’s bandwidth over the next year on a major replatforming. I learned, only later, that half the room thought we weren’t going to need support from two critical teams. This added another ~$250,000 to the cost of the project and, had the decision makers known, it might’ve been enough to scuttle the whole thing before we’d committed more than a few tens of thousands. Had I communicated, Exactly, what was going to be done, we might’ve had a better outcome for the company.
Early in my career I watched a Product Manager (PM) lean on a Sr. Engineer pretty hard for an estimate. The engineer was trying her damndest to say she couldn’t give a good estimate, but she was a pretty conflict adverse person and the PM was pretty influential around the company. I was too new to even recognize how bad this situation was at the time, so I sat there as he wore her down and she caved. She told him something to the effect of six days. The PM told the rest of the company it’d be done in six days and an Account Manager told a major customer the feature would be live on the 7th. As so often happens the engineer was asked to work nights and weekends and management got more people involved and despite it all the team didn’t quite make the date and quality was lacking. Had she shared her Confidence in the estimate the whole team might’ve had a better outcome.
Somewhere around my third year as a software engineer I was estimating a multi-month project in my capacity as a Tech Lead. I was rather pleased with myself, I’d done the research, talked with the team, pressured the PM on the requirements, written up a technical proposal, gotten input from the other engineers and slapped an estimate together. I told the PM we’d get it done in four weeks. The PM took my word for it and said we were on track for our quarterly goals to upper management. Two weeks later half my team started putting in for PTO during ski season. We missed our deadline by three weeks. I was young and a workaholic and forgotten to even ask my team about their holiday plans. Had I done that, or included no PTO as an Assumption the outcome might’ve been different for the team.
At one point I was in a quarterly planning meeting at a company that operated under a SAFE model. We were all sitting around the table throwing things on team’s plans and trying to figure out our capacity for the quarter. Half the teams were talking about how many points they had, another group was talking about T-Shirt sizes, one of the architects was throwing out Stupid Wild Ass Guesses (SWAGs) in real time. It was impossible for anyone to understand, with any Specificity and Precision how much of any given team’s bandwidth had already been allocated. It was also impossible to compare a team’s velocity, success rate or capacity quarter over quarter because sometimes the unit would change!
A good S.P.A.C.E Estimate
My team and I believe we can build the password reset flow defined in Jessica’s V2 Password Reset Flow document. We think we have a 30% chance of delivering in five business days, a 60% of chance of delivering in eight business days and a 90% chance of delivering in fifteen business days. We’re assuming that the work can be split amongst three engineers relatively easily, that our frontend engineer can work with mocked data for a few days, that our mocked data isn’t incorrect, that Jessica can deliver the templates for the emails by the end of day two and that no one has any unplanned PTO for the duration of the project.
We know
Exactly what is being estimated: Jessica’s V2 Password Reset Flow.
How Confident the team is in their estimations.
The Assumptions the team has built into their estimations.
In Specific units and with Precision how long it’ll take: Between five and fifteen business days.
Paying for S.P.A.C.E.
Specific units is usually just a matter of setting up the culture and repeatedly asking “What unit is that?” when the units are missing.
Precise numbers are generally pretty expensive as it requires the estimator to have an understanding of the current system, how it might be evolved to solve the problems being discussed, what the team is capable of, and everyone’s velocities involved. This is usually the most expensive part of the process and can take many days and in some cases weeks. It also isn’t often done within the bounds of Engineering. Don’t be surprised if your engineers are trekking all across the company to get questions answered!
Assumption lists are usually pretty cheap once your team has built the muscles. A good checklist can help to prompt engineers about common assumptions until they’ve learned to think through them on their own.
Confidence intervals are a bit wonky. It’s pretty fast (minutes) to give low confidence estimates, but getting higher confidence estimates that aren’t ridiculous is usually pretty expensive. Don’t be surprised if your engineers want to spend a week figuring out a plan before they’ll give you a 90% confidence estimate less than a full calendar year or an outright “I don’t know”.
Exact definitions of what problems are being solved are really dependent on the quality of your PRDs. If you’ve got mini-ceos who are very exact in their problem definition and user stories your engineers should be able to lean pretty heavily on that and this will be cheap. If you’ve got less talented PMs you might need to rebuild your product org. Fortunately that’ll pay dividends in other ways!