The estimation multipliers we bet our own delivery on

What is the Klientele estimation formula?

Direct answer: The formula is `adjustedEstimate = baseEstimate × complexityMultiplier × clarityMultiplier × 1.3 (testing) × documentationMultiplier × (1 + bufferPct)` — a set of multipliers that turn an honest "this should take four hours" into a delivery window that accounts for everything the four hours left out.

Every piece of work starts with a base estimate — the honest answer to "how long is the actual work." The calculator then adjusts it before anyone commits to a date:

adjustedEstimate = baseEstimate
                 × complexityMultiplier
                 × clarityMultiplier
                 × 1.3  (testing)
                 × documentationMultiplier
                 × (1 + bufferPct)

None of these multipliers was invented for a blog post. Each one came out of a piece of our own work that went badly and a post-mortem that named the reason. The formula fits technology and IT work best, because that is the work it was built from.

How does the complexity multiplier work in estimation?

Direct answer: The complexity multiplier runs from 1.0× (Simple — a contained change in familiar territory) to 2.0× (Very Complex — cross-cutting work with a real chance of scope creep), with 1.3× for Moderate and 1.5× for Complex. It is the multiplier people already know intuitively but rarely apply consistently.

The complexity axis is closest to what people mean by "hard": how many moving parts the work touches, how much of it is unfamiliar, and how much has to change underneath it.

A four-hour base estimate on Complex work becomes six hours before anything else is applied. That is the least surprising multiplier, which is exactly why it gets skipped when everyone is in a hurry.

Why does clarity matter more than people think in estimation?

Direct answer: Clarity is the axis nobody talks about and the one that ruined the most of our estimates. Very Unclear work (2.0×) means someone will be making product decisions during the build, and clarity compounds with complexity — Very Complex plus Very Unclear is 4.0× before testing and buffer, which is usually the signal that the work needs a discovery step before it is estimated at all.

Because clarity and complexity multiply, a piece of work that is both very complex and very unclear stops being an estimate and becomes a guess. For us, that combination now means a short discovery task first, then an estimate.

“"Requirements are clear" is the most common thing a team tells itself at estimation time, right before it spends two days doing product decisions inside the build.”

Why does Klientele always apply a 1.3× testing multiplier?

Direct answer: Testing is part of the formula rather than an optional checkbox because, in our own work, estimates for "no tests needed" jobs were the ones that kept running over. Untested work is faster to write and slower to trust, so the 1.3× is about trust, not about tests.

This was one of the earliest arguments inside Codefree — engineers asking why a small job needed a testing allowance at all. Our post-mortems kept answering it: the jobs estimated without testing were the jobs that came back. Pricing testing out of an estimate is how it stops happening.

When does the documentation multiplier apply?

Direct answer: The documentation multiplier is a simple yes/no worth 1.2×. It applies when the work introduces something a future colleague or user has to understand without reading the code — a new API, a new setting, a new user-facing feature, a new operational routine. Bug fixes and changes that don't alter behaviour skip it.

Why does the buffer bracket follow a U-curve?

Direct answer: The buffer is U-shaped — 50% under 4 hours, 30% from 4 to 16 hours, 40% from 16 to 40 hours, 50% above 40 hours — because small jobs are usually mis-scoped ("just add a field" hides a cascade of edge cases) and large jobs touch more people and more state. Medium jobs are the most predictable because they are big enough that someone actually thought them through.

Everyone expects big jobs to need more buffer. Fewer people expect very small jobs to need more than medium ones. We used to apply one flat buffer to everything, and we were consistently short on the smallest and largest jobs and padded in the middle. The bracket fixed both ends.

What has tracking estimate against actual taught Codefree?

Direct answer: Recording the estimate and the actual time on the same piece of work showed us where misses come from. Ours clustered in two places: unclear work that should have had a discovery step first, and estimates where someone skipped or lowered a multiplier under deadline pressure.

Klientele keeps the estimate and the logged time on the same item, so the difference between them is visible per job rather than reconstructed from two systems.

The second pattern is the one to watch. If a team can switch the multipliers off when a date feels tight, it will — and the miss shows up a few weeks later, when nobody remembers why.

“The multipliers only work if they are applied every time. The deadline you miss later will not remember that you skipped them.”

Where do the estimation multiplier values come from?

Direct answer: The multipliers came from our own post-mortems: work that ran well over its estimate got a short written root cause, we reviewed those causes together periodically, recurring causes became named axes on the estimate form, and each axis's multiplier was set from how far over the affected work had actually run.

1. 1.
   Work that ran well over its estimate got a short written root cause from the person who did it.
2. 2.
   We reviewed the root causes together and looked for patterns.
3. 3.
   Recurring patterns became named axes on the estimate form.
4. 4.
   Each axis's multiplier was set from how far the affected work had actually run over.

The result is the closest thing Codefree has to shared estimation discipline. Everyone who joins inherits it on their first day.

How do you apply the estimation formula without Klientele?

Direct answer: You can put the multipliers in a spreadsheet and get most of the value. What breaks without a system underneath is consistency: manual estimation maths gets skipped under pressure, and you can't compare estimate to actual unless both live in the same place.

1. 1.
   Nobody updates the spreadsheet. Maths that has to be applied by hand when work is opened gets skipped when the day is busy. In Klientele the calculator sits on the estimate itself.
2. 2.
   Comparing estimate to actual needs both in one place. Before Klientele, our time lived in Toggl and our work lived in Jira, and joining them was a manual export every Friday.