Break work down, estimate with ranges, and communicate scope, risk and technical debt honestly.
Why it matters
"How long will this take?" is one of the most common questions an engineer hears, and one of the hardest to answer well. Managers, designers and other teams plan around your answer: launch dates, marketing, hiring, who works on what next. A good estimate is not a promise of an exact date. It is an honest statement of scope, uncertainty and risk that helps other people make decisions. Learning to give one, and to explain the trade-offs behind it, builds more trust than being fast.
Why estimates go wrong
- Unknown work. The task you are estimating is never quite the task you end up doing. Edge cases, reviews, tests, deployment and bug fixes are easy to forget.
- Optimism. People estimate the happy path: the time it takes if nothing goes wrong.
- Anchoring. Someone says "this should be quick, right?" and your estimate bends toward it.
- Interruptions. Meetings, on-call duty and code reviews take real hours from every week.
Break the work down
Large tasks are impossible to estimate; small tasks are merely hard. Split the feature until each piece is about a day or less, and include the parts people forget.
Example: "Users can export their order history as CSV."
| Task | Estimate (days) |
|---|---|
| API endpoint that streams orders as CSV | 1 |
| Escape commas, quotes and newlines; handle 10,000+ rows | 0.5 |
| Button and download on the orders page | 0.5 |
| Unit and integration tests | 1 |
| Code review and fixes | 0.5 |
| Deploy behind a flag, check logs, enable | 0.5 |
| Total | 4 |
Show the uncertainty: three-point estimates
Instead of one number, give three for each task: optimistic (O), most likely (M) and pessimistic (P). A common way to combine them is the PERT formula:
expected = (O + 4M + P) / 6
For the whole export feature, suppose O = 3 days, M = 4 days, P = 9 days (the pessimistic case is that the orders table is too slow to export and needs a new index or a background job):
expected = (3 + 16 + 9) / 6 = 28 / 6 ≈ 4.7 days
The gap between 3 and 9 is information. It tells the listener there is a specific risk, and what it is.
Communicate scope and risk
How you say it matters as much as the number. A clear status message has a range, the assumptions behind it, the main risk and what you will do about it:
Export to CSV: about 4–6 days, with 5 as my planning number. This assumes we export only the fields shown on the orders page. The main risk is query speed for large accounts; I'll test that on day 1 and tell you by Wednesday if we need a background job, which would add 3–4 days.
Practical habits:
- Give ranges, not points, and say what would move you to the top of the range.
- Separate effort from calendar time. Four days of work may take seven calendar days with reviews, meetings and on-call.
- Re-estimate early and say so. "I found X; the estimate is now 7–8 days" on day 2 is welcome. The same news on the due date is not.
- Track your estimates against actuals. After a few projects you will learn your own bias (most people are low by 1.5 to 2 times).
Trade-offs: scope, time and quality
When the estimate does not fit the deadline, there are only a few levers: reduce scope, move the date, or add people (which rarely helps late in a project: new people need onboarding, and coordination costs grow). Cutting testing or review looks like a fourth lever, but it borrows time from the future.
That borrowing is called technical debt: a shortcut that saves time now and costs extra time later, like interest on a loan. Some debt is a reasonable business decision ("ship the simple version for the conference; replace the polling with webhooks next sprint"). Make it deliberate and visible:
- Write it down as a ticket, with the cost of leaving it.
- Agree when it will be paid back.
- Bring it up in planning when it starts to slow the team ("Every change to checkout takes two extra days because of the duplicated pricing code").
Common mistakes
- Estimating only the coding, not tests, review and deployment.
- Giving a single number with no assumptions.
- Saying yes to a date you do not believe, then working weekends to hit it.
- Hiding bad news until the deadline.
- Treating all technical debt as bad, or all of it as fine.
Recap
- Break work into small pieces, including tests, review and deploy.
- Use ranges or three-point estimates; the spread shows the risk.
- State assumptions, the main risk and when you will know more.
- Scope, date and quality are the levers; technical debt is a loan, so record it and plan the repayment.
Try it
In the Do tab, estimate a real feature, write a status message and track how your estimate compares with reality.