Work breakdown and spikes

Vague epics produce vague estimates. Break the project until each leaf task is something one person can finish in about a day or two of focused work. If a task is still "implement notifications," keep splitting: schema, producer, consumer, retries, metrics, feature flag, docs.

Estimating "migrate the billing pipeline" without a spike is fiction.

Walking through a breakdown

A PM asks: "Can we ship shared report folders by the 28th?" Today is the 4th.

Spike (day 1–2). Permissions model already has groups; folders do not. ACL inheritance is unclear. Spike result: reuse group ACLs, add folder_id nullable on reports, no new auth service. Confidence rises.

Then the leaves (raw eng-days):

Every row is ≤2 days. The ACL line is still the wild card — that is why it got a spike first, and why it will get a larger padding factor next.

Common mistakes

• Leaving a task at "implement notifications." That is still an epic.
• Estimating the unknown work before the spike.
• Letting a junior's optimism set the team date without a senior pass on the risky tasks.

Check yourself

The ticket says "implement notifications." What do you do before quoting a date?

Split it into schema, producer, consumer, retries, metrics, flag and docs — and spike anything you have not seen.

A spike shows you cannot reuse the existing outbox. What happens to the estimate?

The dependent work changes. Re-estimate now; do not keep the pre-spike number.

Key takeaways

• Break work to about one or two focused days per leaf.
• Spike unknowns before you pretend to know their cost.
• Write the spike down so it feeds the design and the next person.
• Risky leaves stay visible in the table. Do not bury them in a lump.

Further learning

Next, turn the raw sum into a range: estimate ranges and padding.