The estimation multipliers we've bet a 12-person agency on

What is the Klientele estimation formula?

Direct answer: Klientele's estimation formula is `adjustedEstimate = baseEstimate × complexityMultiplier × clarityMultiplier × 1.3 (testing, always applied) × documentationMultiplier × (1 + bufferPct)` — five multipliers that turn a developer's honest "this should take four hours" into an honest delivery window that reflects everything else the four-hour estimate ignored.

Every ticket in Klientele carries a base estimate — the developer's honest answer to "how long is the actual work." Klientele then adjusts it through five multipliers before committing to a deadline:

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

Not one of these multipliers was invented for a blog post. Every one earned its place after a specific ticket blew up on us and a post-mortem produced the axis. The formula is what we now bet the entire operation on.

How does the complexity multiplier work in estimation?

Direct answer: The complexity multiplier ranges from 1.0× (Simple — contained change, single file, familiar territory) to 2.0× (Very Complex — cross-cutting, needs a spike, real chance of scope creep), with 1.3× for Moderate (2-3 modules, some coordination) and 1.5× for Complex (touches core state or unfamiliar library) — this is the multiplier developers already intuitively know but rarely apply consistently.

The `complexity` axis is the closest to what people think of when they say "hard": how many moving parts does this touch, how much unfamiliar code, how much refactoring under load.

A 4-hour estimate on a "Complex" task becomes 6 hours. That's the least surprising multiplier — developers over-estimate the "Simple" side and under-estimate the "Very Complex" side, so we push both directions.

Why does clarity matter more than developers think in estimation?

Direct answer: Clarity is the axis nobody talks about and the one that ruins the most estimates — a Very Unclear ticket (2.0×) requires the developer to make product decisions during implementation, and clarity compounds with complexity so a Very-Complex-plus-Very-Unclear ticket carries a 4.0× multiplier before testing and buffer, which is usually the signal that the ticket belongs on a spike, not a sprint.

The one nobody talks about, and the one that ruins the most estimates.

The interesting effect: `clarity` compounds with `complexity`. A "Very Complex + Very Unclear" ticket has a multiplier of 4.0× before we've even added testing or buffer. That's usually the signal that the ticket doesn't belong on a sprint — it belongs on a spike or a discovery session first.

“Clarity is what everyone lies about at estimation time. "Requirements are clear" is the most common lie a dev team tells itself, right before they spend two days doing product management inside implementation.”

Why does Klientele always apply a 1.3× testing multiplier?

Direct answer: Klientele always applies 1.3× for testing because Codefree measured a 40% higher variance on tickets marked "no tests needed" — not because the code was worse, but because developer estimates for untested code are systematically over-optimistic; untested code is faster to write and slower to trust, so the multiplier is trust math, not test math, and it cannot be turned off in the ticket form.

Every ticket gets multiplied by 1.3× for testing. Not because we always write tests — because we always *should*, and pricing testing out of the estimate means we won't. The multiplier is enforced. It cannot be turned off from the ticket form.

This was one of the earliest fights inside Codefree — engineers arguing "this ticket doesn't need tests, why the tax?" The answer, after we tracked variance for two quarters: tickets marked "no tests needed" had 40% higher variance than tickets with tests. Not because the code was worse, because the developer's estimate for "no tests needed" tickets was systematically over-optimistic. Untested code is faster to write and slower to trust. The 1.3× is trust math, not test math.

When does the documentation multiplier apply?

Direct answer: The documentation multiplier is a boolean 1.2× that applies whenever a ticket introduces a new API, a new setting, a new user-facing feature, or a new operational pattern — anything that requires a future engineer or user to understand the change without reading the code. Simple bug fixes and refactors that do not change observable behaviour skip the multiplier.

Simplest axis. `needsDocumentation` is a boolean. If yes, `× 1.2`. If no, `× 1.0`. If the ticket introduces a new API, a new setting, a new user-facing feature, or a new operational pattern, documentation is needed. Otherwise it's not.

Why does the buffer bracket follow an inverted U-curve?

Direct answer: The buffer bracket is U-shaped (50% for tickets under 4 hours, 30% for 4-16 hours, 40% for 16-40 hours, 50% for 40+ hours) because small tickets are usually mis-scoped ("just add a field" hides a cascade of edge cases) and big tickets touch more state with more coordination — medium tickets in the 4-16 hour range are the sweet spot because they are big enough that someone actually thought them through.

This one surprises people. Klientele applies a buffer based on the *size* of the multiplied estimate:

The counter-intuitive part is the U-shape. Everyone expects "big tasks need more buffer." Nobody expects "very small tasks need more buffer than medium ones." But the data was unambiguous — a 2-hour ticket has a wider variance distribution than an 8-hour ticket. The reason is that small tickets are usually mis-scoped ("just add a field") and hide an entire cascade of edge cases the developer discovers halfway through. Medium tickets are the sweet spot because they're big enough that someone actually thought them through.

Codefree used to give a flat 20% buffer regardless of size. We were consistently under on the tails and over in the middle. The bracket fixed both.

What has 12 months of variance tracking taught Codefree?

Direct answer: After 12 months of Codefree tickets running through Klientele: 68% closed within ±25% of the adjusted estimate, the median variance was -4% (slightly under, which is healthy — multipliers were not padding into fantasy), and the worst-variance tickets fell into two patterns: Very Unclear tickets that should have been spikes, and tickets where developers manually overrode a multiplier under sprint pressure.

Every ticket in Klientele records `estimated_time` and `actual_time`. Klientele computes `variance_percentage = ((actual - estimated) / estimated) × 100` on every close. Aggregated, this is the honest report card on the formula.

After 12 months of Codefree tickets running through Klientele:

• 68% of tickets closed within ±25% of the adjusted estimate
• Median variance: −4% (we were slightly *under* on the median, which is healthy — it means the multipliers weren't padding the estimates into fantasy)
• The worst-variance tickets were consistently in one of two categories: "Very Unclear" tickets that should have been spikes, or tickets where the developer manually overrode a multiplier at estimation time

That last one is the pattern to watch. If you give teams the ability to disable multipliers, they'll disable them under sprint pressure — and the variance shows up on the next sprint.

“The multipliers are not optional. If a team can turn them off, they will, and the deadlines they missed six weeks later will not remember why.”

Where do the estimation multiplier values come from?

Direct answer: Every multiplier value came from a specific Codefree post-mortem process in 2024: tickets that closed with >30% variance got a written 3-line root cause analysis from the developer, patterns were aggregated quarterly, recurring patterns became named axes on the ticket form, and each axis's multiplier was calibrated to the median variance of tickets scoring high on that axis — the formula has been unchanged for 14 months.

None of these multipliers are guesses. They came from a specific post-mortem process at Codefree during 2024:

1. 1.
   Every ticket that closed with >30% variance got a written 3-line RCA (root cause analysis) from the developer.
2. 2.
   We aggregated RCAs quarterly and looked for patterns.
3. 3.
   Recurring patterns became named axes on the ticket form.
4. 4.
   Each axis's multiplier was chosen based on the median variance of tickets that scored high on that axis.

The formula shipped with the numbers you see above. It's been unchanged for 14 months. It's the closest thing Codefree has to institutional estimation discipline. Every developer we've hired since inherits it on their first day. Nobody has argued to change it.

How do you apply the estimation formula without Klientele?

Direct answer: You can paste the multipliers into a spreadsheet and get most of the value, but three things break down without the platform underneath: (1) estimation math applied manually gets skipped 90% of the time under deadline pressure, (2) variance tracking requires estimated and actual time in the same system, and (3) the multipliers should be tunable per vertical — Klientele's template layer handles each of these; a spreadsheet does not.

The formula works whether or not you use Klientele. You can paste the multipliers into a spreadsheet and get most of the value. But three operational things break down without the platform underneath:

1. 1.
   Nobody updates the spreadsheet. Estimation math that requires manual application at ticket-open time gets skipped 90% of the time under deadline pressure. Klientele bakes it into the ticket form — a developer can't submit an estimate without going through the axes.
2. 2.
   Variance tracking requires structured data. You can't measure variance without recording estimated and actual time in the same system. If time lives in Toggl and tickets live in Jira, the join is a manual Friday-afternoon export.
3. 3.
   The multipliers should be tunable per vertical. Legal tickets have different clarity distributions than agency tickets. Klientele's template layer lets each vertical override the multipliers without a code deploy.