Use AI to Estimate Tickets Without Sandbagging

Use AI to estimate tickets only after you have decomposed the work and attached evidence. A model that sees a title like "fix checkout" will output "3 points" with the confidence of a weather app. That number is not an estimate. It is a prior from other companies' blogs. This article is the daily method: split the ticket, retrieve similar closed work, demand ranges and risks, then let humans own the commitment.

Key Takeaways:

• Estimate slices (repro, patch, test, docs, rollout), not epic titles.
• Ask the model for a range and the missing information, never a single Fibonacci number.
• Compare against your closed tickets, not against the internet's "average CRUD app."
• Recalibrate in standup when the range was wrong; do not quietly sandbag the next one.
• Scan ticket attachments and dump files for secrets with Ocherfort before they go into a cloud model.

Table of Contents:

• Why Ticket Estimates Go Wrong
• Decompose Before You Prompt
• Historical Analogues Beat Vibes
• A Prompt That Returns Ranges
• Uncertainty, Buffers, and Sandbagging
• Feeding Estimates Back Into Delivery
• Frequently Asked Questions

Why Ticket Estimates Go Wrong

Software estimation is a forecast under incomplete information. The Cone of Uncertainty is old because it is still true: early in a ticket you are wrong by a factor, not by a point. AI does not collapse the cone. It can hide it behind a tidy integer.

Three specific failure modes show up when teams use AI to estimate tickets:

1. Title-only prompting. "Add SSO" looks like a library call in training data. In your company it is four IdP edge cases, a migration of session cookies, and a week of developer documentation.
2. Point inflation as politics. People ask the model to "be conservative," then add another buffer, then pad in planning poker. The sprint fills with fog.
3. Point deflation as heroics. A senior engineer pastes a stack trace, the model says "one hour," and nobody prices the canary, the runbook, or the customer email.

Honorable engineering looks like DORA's research on throughput and stability: you want small batches you can finish, not theatrical numbers. Estimation is a tool for sequencing and risk, not a moral score.

If the ticket is an incident leftover, do not estimate from the Slack vibe. Use the evidence pack from AI debugging production errors: trace ids, deploy SHAs, blast radius. A "fix 502s" ticket without a reproducing request is a research spike, and you should estimate it as a spike.

API work is especially easy to under-price. Changing a handler is small. Changing the error contract that mobile clients parse is not. HinterBuild backend and API engineering estimates include OpenAPI, consumer tests, and a rollback flag. Streaming endpoints need extra room for abort and reconnect behavior; see streaming LLM responses in production.

Decompose Before You Prompt

Short answer: if you cannot list the slices, you cannot estimate, and neither can the model.

A decomposition that works for implementation tickets:

Ask the model to propose slices first, then estimate each slice. If it returns one number, reject the output.

You are estimating engineering work for our team, not writing a blog.
Ticket: [title + description + linked PRs]
Constraints: stack listed below. Do not invent services.
Step 1: split into slices (repro, patch, tests, docs, rollout, security).
Step 2: for each slice, give low / likely / high in hours, and the assumption that if false blows the high.
Step 3: list questions that would collapse the range. Do not answer them with guesses.

Security slices are not optional when the ticket touches env files, CI, or agent tools. Price a Ocherfort scan and gate check the way you price tests. Ocherfort is a local-first repo security CLI: builtin checks plus optional scanners, evidence under .ocherfort/runs/, ship/no-ship gates. It is not a GRC platform. For agentic tickets, include the agentic gate — MCP servers and prompt files are part of the blast radius. Read MCP explained with real code and MCP tools for daily development before you estimate "just add a tool."

Learning work is a slice too. If the engineer has never touched the framework, the ticket is part delivery and part curriculum. Do not hide that in a 5-point lie. Sequence it with learn a new framework in one week or a Cadensend email series grounded in your own sources — open source, self-hosted, no hosted signup.

Historical Analogues Beat Vibes

The only calibration data that matters is your closed tickets. Models have a strong prior that "CRUD is two days." Your CRUD might include a dual-write to a warehouse and a PII review.

Build a tiny analogue set:

• Last 20 tickets in this service, with cycle time from first commit to production
• Whether they slipped, and the stated reason
• Whether docs and flags were in the original estimate

Then prompt:

Here are 8 closed tickets with cycle times. Map the new ticket to the two nearest analogues.
If none are near, say so and keep the range wide.
Do not average incomparable work (a typo fix and an SSO project).

This is closer to reference-class forecasting than to planning poker theater. It also gives you a paper trail for standup: "we estimated like PAY-182, which slipped on consumer tests."

Assistants with repo context (terminal AI CLI workflows, OpenClaw vs Claude Code) can see the actual files. That improves the patch slice and does nothing for the org-process slices unless you paste those too. A local model is preferable if tickets contain customer names; see local vs cloud AI coding assistants.

Observability tickets are analogue-rich if you already have dashboards. "Add a RED dashboard for inventory-svc" is not like "invent SLOs from scratch." Price the latter with observability and monitoring as a project, not a chore. Field names should match structured logging or you will estimate a dashboard that nobody can query.

A Prompt That Returns Ranges

Single-point estimates are the bug. Use hours or half-days if your team does not actually speak Fibonacci. Points are fine if you already have a stable scale; the model does not.

Output contract:

Return markdown:

| Slice | Low | Likely | High | Killer assumption |
| ... | | | | |

Total likely: X
Total high: Y
Confidence: low/med/high
Questions (max 5): ...
Recommended ticket split: ...

If Y > 2 * X, you do not have an implementation ticket. You have a spike plus a follow-up. Split it. Estimating a 10× range as "8 points" is how sprints die.

When the work is "write the PR description later," stop. Price PR descriptions reviewers actually read as a 20-minute slice, not as zero. When the work is "AI will just generate tests," price review time. Generated tests that never fail are a liability, not a savings.

Keep secrets out of the analogue dump. CSV exports of Jira often contain customer URLs. Run Ocherfort on the export directory, or strip columns first. The same rule as debugging: you are exporting data into a model.

For MCP-heavy estimates, include tool blast radius: read-only vs write, and whether a human gate exists. Under-pricing "add MCP" is how you get a filesystem server that can read ~/.aws. The MCP tutorial is the technical companion.

Uncertainty, Buffers, and Sandbagging

Sandbagging is padding you will not admit. AI makes it easy to launder: "the model said 5 days." Own the buffer or delete it.

Legitimate buffers:

• First time on a framework (price learning explicitly)
• Cross-team IAM or DNS
• Production-only reproduction
• Compliance review

Illegitimate buffers:

• "Someone might interrupt me"
• "The last sprint slipped so this one should too"
• Doubling because the PM wants a lower number and you want a higher one

Put the buffer on the high end of the range, not on the likely. Likely should be what happens if the assumptions hold. That is how you can say in standup "we are tracking to high because assumption 2 failed" without shame.

If your culture punishes hitting the high end, people will lie to the model and to you. No prompt fixes that. Process does: small tickets, frequent merge, visible cycle time.

Learning curricula reduce estimation noise over a quarter. A coding journal plus Cadensend onboarding means the next "first time with X" is cheaper. Cadensend plans a cited email series from your sources; it is not a marketing tool and has no hosted signup.

Compare assistant products only insofar as they change cycle time. OpenClaw vs Claude Code is a tooling estimate of its own: setup cost vs per-token cost. Include that when the ticket is "roll out a coding assistant."

Feeding Estimates Back Into Delivery

An estimate that never meets reality is astrology. Close the loop.

1. At start: store the range and the assumptions on the ticket.
2. Mid-work: if a killer assumption dies, split or re-range the same day. Mention it in standup prep.
3. At merge: record actual hours or cycle time. This is analogue fuel.
4. At incident: if the ticket was a hotfix, tag it so you do not train the model that all 502s are two-hour jobs. Use the debugging playbook.

Docs and runbooks are part of "done" or they are not. If you skip them, the next estimate for the same area goes up because on-call cannot see. Generate docs from spec as in AI for developer documentation. Keep traces queryable via observability.

CLI-native teams should estimate from the same shell they use to implement — terminal AI CLI workflows — so the analogue set and the working tree stay together. For privacy, prefer local assistants on ticket bodies.

If you want help installing this into API delivery and on-call, contact HinterBuild. About the team is the human context; backend API engineering is the delivery context.

A note on story points vs hours: pick one language per team. The model will happily mix them. Your board should not.

Frequently Asked Questions

Can AI estimate tickets more accurately than humans?

Not from a title. With decomposition, analogues, and a range, it is a faster first draft than a blank planning session. Humans still own the commitment and the political context the model cannot see.

Should I use story points or hours in the prompt?

Use whichever your team already calibrates. Do not let the model convert between them. If your points are unstable, switch the prompt to half-days until the scale means something.

How do I stop the team from sandbagging with "the AI said so"?

Require the range, the assumptions, and the analogue tickets on the card. "The model said 5" is not an audit trail. Recalibrate in public when you miss.

What if the ticket is exploratory?

Estimate a time-boxed spike with an explicit output (repro, ADR, or kill decision). Do not estimate the follow-up implementation until the spike exists.

Is it safe to paste Jira exports into a cloud model?

Often no. Exports contain customer names, URLs, and sometimes credentials in attachments. Redact, or use a local model, and scan files with Ocherfort.

How should we estimate onboarding or learning tickets?

As a curriculum with a finish line, not as an open-ended "ramp." Cadensend and one-week framework learning make the work visible.

Conclusion

• Decompose, then estimate slices with low/likely/high.
• Calibrate on your closed work, not on internet folklore.
• Put uncertainty on the high end; do not launder buffers through a model.
• Record actuals so the next prompt is smarter.

Use AI to estimate tickets as a forecasting aid on top of engineering evidence. For the systems that make slices small — APIs, tests, traces — see backend engineering, observability, contact, and about.