Estimates, dependencies, blockers, edge cases, and risk

“How long will it take?”

It is a reasonable question with a long history of wrong answers.

This lesson is about why, and about the vocabulary that lets product people and engineers discuss timelines honestly instead of theatrically.

What is an estimate?

An estimateConcept · lights on your mapestimateA forecast of effort, given before the work has revealed its surprises. Treat one like a weather report: useful, dated, and worth re-checking as conditions change — never a contract, however hard it gets quoted back. is an informed guess at how long work will take.

Software estimates are famously wrong, and after ten modules you know the deep reason. Most tasks contain undiscovered work, which makes the task an iceberg — nine-tenths of it below the waterline. The estimate is usually a price on the visible tenth.

Watch one get decomposed honestly:

Three habits separate honest estimating from theater:

• Ranges over points. “Two to four weeks” carries real information; “seventeen days” carries false precision.
• Re-estimate as you learn. The estimate made before opening the iceberg is the worst-informed one anybody will ever make.
• Say it plainly: an estimate is not a promise — though it will be remembered as one, which is exactly why it deserves care.

What is a dependency?

An old friend takes its final bow: dependencyConcept · lights on your mapdependencyFourth and final formal encounter (Modules 3, 6, 9, and now project management): here it means a schedule coupling — your timeline contains other people’s timelines. The reason “how long will it take?” so often means “how long will they take?”.

In planning, a dependency is work that waits on other work. The delivery feature needs the payments team’s new API first, so their delay is now your delay, through no fault of anyone on your team.

Chain the dependencies together and you get the plan’s skeleton. The longest chain of work-that-waits-on-work is called the critical path, and no amount of effort elsewhere can finish the project faster than the critical path allows. Experienced planners find it first. It is the bottleneck idea from Module 10, wearing a calendar.

What is a blocker?

A blockerConcept · lights on your mapblockerWork at a standstill until something outside the worker’s control moves. Saying “I’m blocked” early is a professional virtue, not an admission — stuck-and-silent is the expensive version. is anything currently preventing work from proceeding.

The distinction from a dependency is tense. A dependency is structural — this waits on that. A blocker is now. The waiting has begun, and progress is stopped today.

Blockers come in every shape: another team’s unfinished API, a decision nobody has made, a broken test environment, an expired credential.

“I’m blocked” is the one sentence guaranteed to get everyone’s attention at tomorrow’s standup, and unblocking people is half of a lead’s actual job.

What is a risk?

Things that might go wrong are riskConcept · lights on your mapriskSomething that could go wrong later, said out loud while there is still time to hedge: an unproven library, an unfamiliar scale, a team you are waiting on. The professional opposite of hoping.s — possible future problems the team names now, on purpose.

“The payments API may slip.” “This library is unmaintained.” “We’ve never handled this much traffic.” The middle one is Module 3’s dependency wisdom, resurfacing.

Naming a risk is not pessimism; it buys insurance early because a named risk can be:

• Mitigated — start the risky part first, while there’s time to recover
• Investigated — with a spike, defined below
• Given a plan B — agreed while everyone is calm

An unnamed risk gets handled too, at the worst possible time and by surprise.

What is a milestone?

Big plans get milestoneConcept · lights on your mapmilestoneA dated marker a long project promises to pass — internal MVP, first beta café, launch. Coarser than tickets on purpose: the resolution at which a quarter can be discussed in one meeting.s — named checkpoints so anyone can see where the caravan is.

The craft is making milestones demonstrable. “MVP in internal hands” is a fact anyone can verify; “60% done” is a feeling wearing a number.

Engineering folklore has a joke about that feeling, old enough to have earned a name. The ninety-ninety rule: the first 90% of the work takes 90% of the time. The remaining 10% takes the other 90%. Demo-able milestones exist because of everything that joke knows.

Happy paths and edge cases

Now comes the pair that explains where the undiscovered work hides.

The happy pathConcept · lights on your maphappy pathThe single storyline where every step succeeds — the one a feature is first imagined as, demoed as, and too often estimated as. Module 3 named it; this lesson prices it. is the version of the feature where the world cooperates. For delivery: the address is real, the card has money, a courier says yes, the latte arrives warm. One smooth line from tap to doorstep — and it is what everyone means when they say “add delivery.”

An edge caseConcept · lights on your mapedge caseA situation the feature’s first sketch never included: an extreme input, an unlucky timing, a failure halfway through. Handling these is most of professional engineering, and the honest bulk of any estimate. is a scenario at the boundaries of that smooth line: quantity zero, a name with an emoji, a card expiring mid-purchase, two taps on Pay in one second.

Each one costs real work, because each one forces a decision and then code to enforce it. Take the card expiring mid-purchase: someone must decide what happens to the half-placed order — cancel it, hold it, ask for another card? — and then build whichever answer wins. An edge case is not detected weirdness; it is a small feature nobody planned.

Individually, each edge is rare. Collectively, they are constant, and at real scale one-in-a-million weirdness happens hourly.

So the happy path is an afternoon, and the edges are the three weeks. This is Module 3’s unhappy-path lesson, finally presented as arithmetic. And it is why “what are the edge cases?” is the most engineer-respected question a non-engineer can ask. It announces that you know where the mass of the iceberg lives.

Story points and spikes

Two recognition-tier words complete the estimating vocabulary, both signs of a team being honest about the fog.

Story pointsRecognition — just know it existsstory pointsSizing tokens from a Fibonacci-ish scale — a 5 should feel like roughly two 2s and change — letting teams compare tasks without promising calendar time. Converting them to hours out loud is a classic newcomer faux pas. are sizes, not durations. The scale runs 1, 2, 3, 5, 8, and the numbers measure nothing except how tickets compare. A 5 is bigger than a 2 and smaller than an 8, and that is all it claims.

To size a new ticket, the team holds it against work it has already finished. The double-submit fix was a 2, so if delivery feels like four of those, it is an 8. People guess badly at hours and well at comparisons, which is the whole trick.

A spikeRecognition — just know it existsspikeA ticket whose deliverable is an answer: box off a day or two, investigate, report back. Teams buy one when estimating the real work would otherwise be a guess about a guess. is what a team reaches for when a ticket cannot be sized at all. The planning meeting stalls because nobody knows how hard the payments-team integration is. So a two-day ticket goes on the board, and its only job is to find out. What comes back is knowledge, and the real estimate gets made after it arrives.

The mental model to remember

An estimate is an informed guess quoted on an iceberg’s visible tenth — honest ones come as ranges, get revised, and are never confused with promises.

A dependency is work waiting on work; the longest chain of them is the critical path, and it sets the timeline’s floor.

A blocker is a dependency’s tense. The waiting is happening now. A risk is one that might happen — named early so it can be insured against.

A milestone is a demonstrable checkpoint, a fact, not a percentage.

The happy path is the afternoon; the edge cases are the three weeks. Asking about the edges is asking about the real work.

Story points size work relatively; a spike buys knowledge before the estimate.

You should now be able to hear “three weeks” and ask the questions that open the iceberg (what edges, which dependencies, what risks) instead of negotiating the number.