AI Effort Estimation: Stop Guessing and Estimate from History

The danger of single-point AI estimate guesses.

[0:00]Hi, I'm Sanjanna, a project manager at Humanitarians AI, and this video is about something every plan quietly depends on, the estimate. How long will this task take? We usually answer with a gut number. I'll show you how to use AI to turn that guess into an honest range one built from how your team's work has actually gone before, not from how you

The four-step framework for evidence-based effort estimation. - Using Claude to match new tasks to historical reference classes.

[0:22]Hope it'll go this time. Here's the trouble. When someone asks how long a task will take, we picture it going well. Add oath login about a week. Build a settings page a couple of days. So the sprint gets a confident total 10 days. But think about the last time you did work like this. The integration that hit a surprise. The quick page that grew. We estimate from the best case and then we're shocked when reality lands later. Psychologists call it the planning fallacy and a single gut number walks right into it. So here's the method before we build anything. It's called reference class forecasting and it's four steps. One, describe the task in plain features. What kind of work is this really? Two, match it to its reference class, the pile of similar tasks you've actually completed. Three,

Calibrating for team velocity and reporting ranges instead of single numbers.

[1:12]Read that class's real distribution, not what you hoped they'd take, what they actually took. Four, calibrate Nudge for how fast your team is moving right now and report a range. Notice what changed. Your estimate now comes from evidence, not optimism. Let's build it with Claude and let's start the way most people do with the simple ask. Take my three tasks and just estimate each one in days. It's

Identifying spikes when no historical reference class exists.

[1:37]The obvious first move and it's worth doing because seeing where it falls short is exactly what tells us what to fix. Here's what it wrote. It's honest about what it is. There's a list of tasks and then points one number for each straight from the gut. Five days for oath, two for the settings page, three for the end point. The estimate function just looks that number up. No history, no range, and that comment says it out loud. This is the same thing you get if you ask an AI to just estimated in one shot. A confident number with nothing underneath it. Add them up and the sprint is 10 days. Run it and here's the plan. Three tasks, three tidy numbers, one clean total, 10 days. And it looks great. That's the danger. There's no visible uncertainty anywhere on the screen. So, everyone treats 10 days like a fact. But nothing here knows how work like this has actually gone for us before. It's

A guess wearing the costume of a measurement. So, let's fix it. The missing ingredient is our own past. We have a stack of completed tasks, and we know how long each really took. Let's revise the ask. Don't guess a number. Match each new task to similar finished work. read what that group actually took and hand me back a range from the middle to the 80% mark and scale it for the fact that we're running a bit slower this quarter than we used to. The whole revision is really one line. We pull the actual times from the matched class, take the 50th and 80th percentiles and multiply by velocity. That percentile call is the heart of it. It lets the real spread of past work set the estimate instead of a hopeful guess. The 50th is a coin flip. The 80th is the number you can actually commit to. And because we multiply by velocity, the estimate tracks how fast the team is really moving

Today, not how fast we were 6 months ago. Rerun it and the plan grows up. Every task is a range now. Ooth isn't 5 days, it's 8 to 12 because integrations like it really do run long. The settings page holds near 2 to three. The end point 3 to 5. Watch the old gut numbers. Each one sits right on the optimistic edge of its range. Add the honest ends up and the sprint moves from 10 days to about 19. And here's the honest part of the method. The new database migration has no similar past work to match. So we don't fake a number. We flag it to spike first. When there's no reference class, the right answer is I don't know yet. Not a confident guess. So here's the rubric you can run on any estimate with or without code. Ask three questions. What's the reference class? What kind of work is this really? What did that class actually take? Read the spread, not

The best case. And what's our velocity? Are we faster or slower than that history right now? Answer those. Report a range instead of a point and flag anything with no reference class as a spike, not a promise. That's how a guess becomes an estimate you can defend. Your turn. Grab your backlog and just as important, your last dozen or so finished tasks with the days they really took. that history is the whole trick. Paste this prompt into Claude. It'll group your finished work into classes, match each new task, and hand you back honest ranges, and it'll flag the tasks with no match the ones to prototype before you ever put a date on them. A good answer gives you ranges and names its evidence. A bad one hands you a single confident number, which is exactly what we just learned not to trust. AI effort estimation with Sanjana for humanitarians. AI estimate from your history. Report a range and stop being surprised. Thanks for watching.