The estimate sized a slogan
“We need a portal in six weeks” has no exclusions, no named audience, and no reviewed rules. Developers then invent the missing product while a date is already public.
Missed engineering estimates
Why do engineering estimates always miss deadlines
Engineering estimates miss deadlines when they size only the code. Story points, a hallway date, and an incomplete request leave training, process change, and first-month support off the record. Pair both sides before anyone publishes a day.
For engineering leads, product managers, and department owners who keep watching honest build estimates turn into missed dates.
A date is honest when
- The request has a first-release boundary, not a slogan
- Business rollout sits next to the technical estimate
- A recorded yes cites both numbers and the assumptions
The date slipped because only the build was estimated
Planning poker, three-point ranges, and better story-point hygiene do not fix a missing gate. Teams estimate a half-written ask, publish a hallway date, and treat rollout as someone else’s later plan. The engineering number can be honest and still be the wrong commitment.
Only the code had a number
Story points and vendor hours size the build. They do not size training, procedure changes, legal review, or first-month support. That work still consumes the same calendar.
The deadline was a hallway yes
A date spoken in a meeting becomes the plan. Nobody recorded what the date included, what it excluded, or which estimate it was based on.
Missed Engineering Estimates Method: Size Both Sides Before Anyone Treats a Date as a Promise
Do not start with a better estimation workshop. Start with a reviewable request, a first-release boundary, and two estimates on the same record. A date published before that gate is a wish.
Refuse a size until the ask is a complete request on software project intake. A slogan with a hallway date is how engineering estimates always miss deadlines.
Freeze the answers that change the size in requirements gathering software so both estimates describe the same first release—not a product invented after the date is public.
Park a mid-build add until it returns through software project intake. Silent extras are calendar time, even when the original build number was honest.
- 1
Stop estimating a slogan
Refuse a size until the request names the broken work, the people, the first-release outcome, and a reachable owner.
“Client intake portal, six weeks” is not estimable. “Staff can submit a complete client request and see status; public self-service is later” is. If you cannot write that sentence, you do not have an estimate problem. You have an intake problem.
- 2
Freeze the first-release boundary
Write what is in scope and what is deliberately out. Hidden extras are how an honest six-week build becomes a twelve-week product.
A warehouse feed, a historical import, or a public status page is new work. If it is not on the boundary, it is not in the estimate. Park it or reopen the request before anyone quotes a date.
- 3
Size the technical build against that boundary
Engineering estimates software work, integrations, data movement, and cutover for the named first release—not for the slogan that started the conversation.
Confidence and unknowns belong on the record. A number without “we have not seen the identity vendor” will be reused later as if it covered identity.
- 4
Size the business rollout on the same record
Count training, communication, procedure changes, coverage, and first-month support. If that side is “ops will handle it,” the date already has a hole.
The engineering estimate can be right and the launch still slip because supervisors are in session, legal has not cleared the notice, or the queue has no backfill. That is calendar time, not a footnote.
- 5
Write what the date is not
Assumptions and exclusions travel with the numbers. A date without them will be treated as a promise to finish whatever anyone later remembers.
State the audience, the first-release outcome, the loaded unknowns, and what a slip would reopen. “Six weeks for staff submit-and-track, excluding migration and a public page” is a decision input. “Six weeks” is not.
- 6
Record a yes that cites both numbers
Publish a date only after a leader accepts the paired estimate. New work returns through the gate instead of landing on the sprint as a silent add.
That is why engineering estimates always miss deadlines when the organization treats the developer number as the whole plan. The fix is a recorded commitment, not a new pointing scale.
Practical template
Deadline honesty checklist
If a row fails, do not publish a date. Send the request back one step. The examples use a fictional client intake change.
| Check | If this is missing | Example of “ready” |
|---|---|---|
| Complete request | A slogan forces developers to invent the product after a date exists. | Staff submit a complete client request and see status. Owner is the records supervisor. |
| First-release exclusions | Unwritten extras become implied work the moment the date is public. | No historical import, no public status page, no warehouse feed in the first release. |
| Technical estimate against that boundary | A build number for a larger product will miss even if the math is careful. | Six weeks for submit-and-track, including the current identity vendor. Warehouse feed unknown. |
| Business estimate on the same record | Training, notices, and coverage consume the same weeks as the build. | 36 staff × 1.5 hours, supervisor floor support for four weeks, legal notice still unconfirmed. |
| Assumptions written beside the numbers | A date without assumptions is reused as if it covered later inventions. | Legal copy uses the current retention policy until counsel confirms. Migration is out of scope. |
| Recorded paired yes | A hallway date has no owner when the extra report appears. | Approved for the first-release outcome and both estimates. Public page is a separate request. |
| New work returns through the gate | Silent ticket adds are how an honest estimate becomes a missed deadline. | Director asks for a public status page; it is parked, not folded into week three. |
Worked example
A six-week build that missed because only the code was sized
A fictional Client Intake Portal is estimated at six weeks by engineering. Leadership publishes the date. Three unestimated items were already in the room. None of them is a story-point error.
| Moment | What happened |
|---|---|
| Engineering estimate | Six weeks to ship staff submit-and-track in the current identity vendor |
| Published date | A hallway “let’s do it before quarter end” becomes the plan |
| Miss 1 | Supervisor training and desk coverage were never estimated |
| Miss 2 | Legal has not cleared the client-notice wording |
| Miss 3 | A director adds a public status page “while we are in there” |
| What the team is blamed for | Engineering missed the deadline |
| What actually missed | A code-only number was treated as the whole commitment |
The developers can still be right about the build. The date is wrong because training, legal, and a new page were never on the same record. Re-pointing the stories will not put them there.
What the engineering estimate covered vs. what the date still needed
| What the engineering estimate covered | What still had to happen before the date |
|---|---|
| Developer hours to ship staff submit-and-track | Supervisor training, desk coverage, and first-month questions |
| The current identity vendor, already known | Legal notice wording that nobody had asked counsel to clear |
| A first-release build with no public page | A director’s public status page added after the date was public |
| A range with named technical unknowns | A hallway date treated as a promise to finish whatever arrived later |
Habits that turn an honest estimate into a missed date
Treating story points as calendar days
Velocity can forecast a build. It cannot forecast training, legal review, or work that was never in the request. A pointing scale is not a deadline method.
Estimating before the request is complete
If people, outcome, and exclusions are still missing, the team is guessing a product. The date will absorb every later answer.
Calling rollout “ops will handle it”
Ops still uses the same weeks. If that work has no number, the engineering date is a partial plan wearing a full commitment.
Publishing a hallway date
A spoken quarter-end becomes the plan. Nobody can point at what the date included when the extra report appears.
Running another estimation workshop
Planning poker, t-shirt sizes, and three-point ranges do not add the missing business side. Fix the gate, then size both records.
In Precision Foundry
How Precision Foundry keeps the date attached to both estimates
Precision Foundry asks for a Business Effort estimate beside the technical estimate on the same request. Approval waits until both exist, so a published date cites the paired numbers instead of a developer promise.
- Business and technical estimates are separate, required steps before approval
- Training, communication, and launch support sit with the build number
- Assumptions and unknowns stay attached to the same project record
- The estimate is for a decision, not a promise of an exact completion date
Common questions
Questions about missed engineering estimates
Why do engineering estimates always miss deadlines?+
Because they usually size only the code. Story points and a hallway date ignore training, process change, legal review, and work that was never in the request. Pair a business estimate with the technical estimate against a first-release boundary, then record a yes that cites both numbers.
Is this a story-point or planning-poker problem?+
No. Better pointing hygiene can improve a build forecast. It cannot add rollout, exclusions, or a complete request. If those are missing, a more precise engineering number still misses the date.
Should the deadline come from the engineering estimate?+
The engineering estimate is one input. The date should come from a recorded yes that accepts both the build number and the business rollout, with assumptions written beside them. A developer range is not a calendar commitment.
What belongs in the business estimate vs. the technical estimate?+
Technical effort covers the software work, integrations, data movement, and cutover. Business effort covers training, communication, procedure changes, coverage, vendor coordination, and first-month support. Leaders need both before they publish a date.
When is an estimate good enough to publish a date?+
When the first-release outcome, exclusions, both estimates, and major unknowns are named on one record. A range with assumptions is safer than a single day that hides who still has to confirm training coverage or legal copy.
What if a stakeholder adds work after both estimates exist?+
Treat it as a change to the decision. Re-estimate both sides against the new boundary, then record a new yes, no, or not yet. Do not fold it into the current date because the team is already building.
Try Why do engineering estimates always miss deadlines on one real request
Precision Foundry keeps this guide attached to the request so the template does not live in a forgotten doc.
Join the private alpha waitlist