Task Estimation

Task Estimation

Use this skill when the job is to turn messy scope into one estimate packet with the right horizon, honest uncertainty, and one next move.

task-estimation owns:

• relative sizing before commitment
• choosing the lightest credible estimate unit
• confidence / uncertainty language
• split-or-spike decisions
• short forecast-safe translation notes
• cross-functional burden visibility for launch or game work

Read these support docs before unusual cases or when the request starts to sprawl:

• references/estimation-modes.md
• references/intake-packets-and-route-outs.md
• references/boundary-guide.md

When to use this skill

• A user asks “how big is this?”, “how risky is this?”, or “how should we estimate this?”
• A team needs story points, t-shirt sizing, planning-poker preparation, or confidence framing before a sprint or milestone discussion.
• A roadmap item, bug cluster, launch task, or game milestone needs an estimate without pretending it is already schedule-safe.
• Work is mixed enough that the first useful output is an estimate packet plus split/spike guidance.
• The estimate must surface dependencies, approvals, QA, release, content, or live-ops burden rather than only code effort.

When not to use this skill

• The main job is decomposition into execution-ready slices → task-planning.
• The main job is daily status, blockers, or team synchronization → standup-meeting.
• The main job is reviewing how the process went after delivery → sprint-retrospective.
• The user wants a hard ship date, fixed commitment, or executive promise with no uncertainty language.
• The only honest estimate is discovery itself. In that case, estimate the spike/prototype/vertical-slice work, not the fantasy final implementation.

Instructions

Step 1: Classify one primary estimation mode

Normalize the request before assigning any numbers.

estimation_intake:
  primary_mode: coarse-triage | sprint-candidate | forecast-support | discovery-spike | milestone-cross-functional
  domain: developer-workflow | web-fullstack | product-ops | marketing-gtm | game-development | mixed
  source_material: issue-spec | roadmap-note | launch-packet | gdd-playtest | bug-cluster | chat-context | unknown
  novelty: low | medium | high
  confidence: high | medium | low
  output_shape: estimate-packet | comparison-table | spike-brief | unknown

Use one primary mode per run:

• coarse-triage — rough sizing for intake, backlog cleanup, or roadmap comparison
• sprint-candidate — relative sizing for near-term work
• forecast-support — range-and-assumptions help for scope/date conversations
• discovery-spike — estimate investigation/prototype work, not final delivery
• milestone-cross-functional — work where engineering is only part of the burden

Do not blend several primary modes into one answer.

Step 2: Gather the smallest credible evidence packet

Pull only the evidence needed to support an honest estimate:

• item summary and intended outcome
• current artifacts: issue, PRD, spec, note dump, playtest notes, bug list, launch notes
• systems touched: frontend, backend, data, infra, QA, analytics, content, store/release, live ops
• dependencies, approvals, or external constraints
• known unknowns that could swing the estimate

If evidence is thin, lower confidence immediately or switch to discovery-spike.

Step 3: Choose the lightest estimate unit

Use references/intake-packets-and-route-outs.md.

Default selection:

• T-shirt / coarse bucket for intake and roadmap comparison
• Story points / relative scale for sprint-candidate discussion
• Range + assumptions for forecast-support packets
• Spike estimate when uncertainty dominates

Rules:

• Keep relative sizing visible even if someone asks for time.
• Translate to time only after stating assumptions.
• If discovery and delivery are mixed together, estimate them separately.

Step 4: Calibrate against anchors and burden

Do not estimate in a vacuum.

Compare against 2-3 anchors when possible:

• one small familiar item
• one medium normal item
• one large item that usually needs splitting

Check burden explicitly:

• complexity and novelty
• unknowns and dependency count
• testing / QA / validation load
• rollout, migration, approval, or coordination work
• content, localization, certification, or live-ops burden for GTM/game cases

If no anchors exist, say so and increase caution rather than pretending confidence.

Step 5: Produce one estimate packet

Every answer should include:

• estimate mode
• estimate unit and value
• confidence
• why this size
• uncertainty drivers
• dependencies / approvals
• split-or-spike recommendation
• forecast note: how this should and should not be used
• adjacent handoff when the next job changed

Use one compact packet, not a long agile tutorial.

Step 6: Trigger split-or-spike decisions early

Recommend a split when:

• the estimate reaches 13, XL, or similar “too big” territory
• discovery and implementation are bundled together
• more than one owner/system/approval path is hidden in one item
• validation, migration, or launch burden is non-trivial

Recommend a spike when:

• key unknowns dominate the estimate
• external APIs, vendors, or platform behavior are unclear
• product/game direction is still being validated
• the estimate would otherwise be fake precision

Step 7: Route adjacent work explicitly

Before finalizing, state what comes next:

• use task-planning for slice design, acceptance criteria, owners, and execution packets
• use standup-meeting when the next need is daily coordination on already-chosen work
• use sprint-retrospective when the next need is learning whether the sizing process worked
• do not turn this skill into roadmap commitments, status theater, or board management

Output format

# Estimate Packet

## Mode
- Primary mode:
- Domain:
- Why it fits:

## Evidence used
- Main artifacts:
- Systems / functions touched:
- Assumptions / gaps:

## Recommended estimate
- Unit:
- Estimate:
- Confidence:
- Comparable anchors:

## Why this size
- ...
- ...

## Uncertainty drivers
- ...

## Dependencies / approvals
- ...

## Split or spike recommendation
- Keep as-is | Split | Estimate the spike first
- Reason:

## Forecast note
- Safe use:
- Unsafe use:

## Adjacent handoff
- Next skill / process:

Examples

Example 1: Sprint-candidate SaaS feature

Input

Estimate adding Slack OAuth login plus account linking for the next sprint. We already have user accounts and one OAuth provider in production.

Good output direction

• mode: sprint-candidate
• unit: story points
• estimate: moderate relative slice with medium confidence
• include auth-flow and verification burden
• route final decomposition to task-planning

Example 2: Product/ops roadmap item with high ambiguity

Input

How big is a full creator analytics dashboard for Q3? Metrics, data sources, and stakeholder definitions are still fuzzy.

Good output direction

• mode: coarse-triage or discovery-spike
• unit: t-shirt size or spike brief
• confidence: low
• explicitly say the estimate is not ready for a hard date conversation

Example 3: Game milestone packet

Input

Estimate adding a tutorial checkpoint system before the public demo build. It touches save state, UI messaging, QA regression, and demo flow polish.

Good output direction

• mode: milestone-cross-functional
• include non-code burden like QA/polish and release readiness
• recommend split or spike if checkpoint rules are still undefined

Best practices

1. Estimate the current decision horizon, not the entire dream scope. 2. Keep relative sizing separate from hard commitments. 3. Use anchors and comparable work when available. 4. Separate discovery from delivery early. 5. Surface non-code burden instead of hiding it in one engineering number. 6. Prefer one compact estimate packet over a lecture on agile theory. 7. If the estimate is weak, say it is weak.

References

• Scrum Guide
• Atlassian: What are story points in Agile and how do you estimate them?
• Scrum.org: Story Points: To Estimate or Not to Estimate
• John Cutler: Can You Stop Using Story Points?
• Rami Ismail: Prototypes & Vertical Slice
• Mountain Goat Software: Why I Don't Use Story Points for Sprint Planning

Boundary Guide

task-estimation should stay focused on sizing and forecast-safe language.

Use task-estimation when the main question is

• How big is this?
• How risky / uncertain is it?
• Should we use points, t-shirt sizing, or a discovery spike?
• Is this too large to estimate honestly as one delivery slice?
• How should we describe the estimate without turning it into a promise?

Route to task-planning when the main question is

• What are the execution-ready slices?
• What are the dependencies, acceptance criteria, and owners?
• How do we turn this roadmap item or spec into ready work packets?

Route to standup-meeting when the main question is

• What changed today?
• What is blocked right now?
• How should the team coordinate daily progress?

Route to sprint-retrospective when the main question is

• What did we learn after the sprint or milestone?
• Which process changes should we keep?
• Why did our estimation process succeed or fail?

Guardrails

• Do not invent precision the evidence cannot support.
• Do not turn story points into performance metrics.
• Do not present one estimate as both internal sizing and an external deadline without adding assumptions and uncertainty.
• Do not hide discovery, rollout, or QA work inside one engineering-only number.

Estimation Modes

Use the lightest estimation mode that still supports the decision.

1. Coarse triage

Use when comparing roadmap candidates, backlog intake, or fuzzy large items.

Recommended output:

• XS / S / M / L / XL or a similarly coarse bucket
• 1-2 lines on the biggest uncertainty drivers
• explicit note when the item should become a spike before further sizing

2. Sprint-candidate sizing

Use when the team is deciding what can fit into a near-term sprint or milestone.

Recommended output:

• story points or another relative team scale
• comparable reference stories
• split recommendation for anything too large or too mixed

3. Forecast support

Use when someone asks for date/scope implications.

Recommended output:

• keep the relative estimate visible
• add confidence and assumptions
• translate to a range only if necessary
• remind the reader that throughput/history should drive forecasting more than point totals alone

4. Discovery spike estimation

Use when the work is mostly unknowns.

Estimate:

• the investigation
• the prototype / validation activity
• the decision that the spike should unlock

Do not estimate the final implementation as if the unknowns are already solved.

5. Milestone cross-functional estimation

Use when engineering is only part of the burden.

Remember to include:

• QA/regression load
• content or design follow-through
• release/store/localization/publishing tasks
• approval and coordination burden

Intake Packets and Route-outs

Use this reference when task-estimation needs a compact packet instead of a long explanation.

1. Pick the smallest truthful packet

2. Quick burden checklist

Check these before finalizing the packet:

• Is the work mostly discovery or mostly delivery?
• Are migration, rollout, or approvals hidden inside the item?
• Does QA or validation effort meaningfully change the size?
• Is there content, localization, platform-cert, or live-ops burden?
• Would this estimate be misread as a deadline unless you add a forecast note?

3. Safe forecast language

Good phrases:

• "This is a relative size signal, not a delivery promise."
• "Confidence is low because key dependencies are still unresolved."
• "Treat this as a discovery-spike estimate until the unknowns shrink."
• "If you need a date forecast, pair this with historical throughput and current capacity."

Avoid:

• "This will take exactly ..."
• "This should definitely fit ..."
• "The points already imply the ship date."

4. Common route-outs

Route to another PM skill when the job changes:

• task-planning — turn the estimate into execution slices, owners, acceptance criteria, and ready/not-ready packets
• standup-meeting — coordinate already-selected work day to day
• sprint-retrospective — review whether the team's estimation process or commitment language worked

5. Game / launch nuance

For launch or game work, estimation often fails because the item hides too many non-code tasks.

Explicitly name:

• QA / regression / compatibility testing
• content or copy updates
• release/store/certification steps
• demo-flow polish or live-ops readiness
• approvals, signoff, or publishing windows

If those dominate the item, keep the estimate cross-functional instead of pretending it is one engineering story.