| name | wp-effort-estimation |
| description | Use when asked how long WordPress work will take, when sizing or scoping a ticket, or when planning a sprint — covering pure WordPress (PHP/theme/plugin) and the React surfaces of WordPress (Gutenberg blocks, Interactivity API, block themes, headless WP like Next.js / Faust). Triggers: "how long", "estimate", "how complex is this", "can we do this in a day", "is this a big task", "how should I scope this", "break this down", sprint planning, ticket sizing, story points, t-shirt sizing, project planning for WordPress or React-in-WP work. Do NOT use for generic standalone-React projects with no WordPress involvement.
|
Effort Estimation Skill
Produce structured effort estimates for WordPress development tasks — including
the React surfaces of WordPress (Gutenberg blocks, Interactivity API, block
themes, headless frontends). Always output three things: Complexity Tier,
Hours/Days Range, and Confidence Range.
Scope: "React" in this skill always means React in a WordPress context
(block editor, Interactivity API, admin UIs, headless WP). Generic
standalone-React projects (no WP involvement) are out of scope — decline and
redirect.
Before You Estimate: Clarify if Needed
If the task description lacks a clear deliverable or scope, ask up to 2 clarifying questions before estimating. Do not produce a number when the spread would be meaninglessly wide (e.g. ±300%).
Good triggers to pause and ask:
- No clear deliverable ("build a membership system", "improve performance")
- Stack is ambiguous (WordPress + React could mean headless WP, an Interactivity API block, a custom Gutenberg block, or a wp-admin React app)
- Integration mentioned but API/provider unknown
Ask the minimum needed to produce a useful estimate. One focused question is better than a checklist. Once you have enough, proceed.
Output Format
Every estimate must include:
1. Complexity Tier
| Tier | What it means |
|---|
| S | Straightforward, well-understood task. Minimal unknowns. |
| M | Moderate scope. Some design decisions or integration work. |
| L | Significant scope. Multiple components, systems, or edge cases. |
| XL | High uncertainty or large surface area. Requires breakdown before dev starts. |
2. Hours/Days Estimate
Give a specific midpoint estimate, e.g. "~6 hours" or "~3 days".
Use hours for tasks under 2 days; days for anything larger.
3. Confidence Range
Give a best-case / worst-case spread, e.g. "4–10 hours" or "2–5 days".
Wider range = more unknowns. Always explain what drives the spread.
Ticket field guidance: Use the tier for portfolio/roadmap views (S/M/L/XL is coarser and ages better). Use the hours/days for sprint commitment. Don't paste both into the same single-value field — pick one per field and put the other in the description.
Estimation Process
-
Classify the tech stack — Is this pure WordPress (PHP/theme/plugin), React-in-WP (block editor, Interactivity API, headless WP), or both? MUST read the relevant reference file(s) before writing the estimate — baseline numbers and risk multipliers live there, not in this file.
- WordPress (PHP) tasks → read
references/wordpress.md
- React-in-WP tasks → read
references/react.md
- Both → read both
-
Identify task type — What category does this fall into? (See reference files for task taxonomies.)
-
Check for unknowns — Flag anything that could expand scope:
- Third-party APIs or integrations
- Design not finalized
- Legacy codebase / tech debt
- Performance or accessibility requirements
- Multi-environment (staging, prod, CDN, etc.)
- Cross-browser or mobile requirements
-
Apply complexity multipliers (see General Multipliers section below)
-
Write the estimate using the template below
Baseline Assumptions
- Developer seniority: Senior-level dev highly familiar with the stack. Flag if the task needs a migration-specialized senior dev (platform migration, custom DB schema, multisite, headless cutover, Woo subscriptions) — those warrant a separate spike or higher rate.
- Scaffold: Pre-configured project scaffold assumed (build tooling, CI, base theme/plugin shell). Greenfield multiplier stays at ×1.0.
Estimate Template
## Effort Estimate
**Task:** [one-line description]
**Stack:** WordPress / React-in-WP / Both
**Complexity Tier:** [S / M / L / XL]
**Estimate:** ~[X hours / X days effort] / ~[Y days duration]
**Confidence Range:** [low]–[high] [hours/days]
### Breakdown
*(Required for M, L, XL tasks. Optional for S.)*
| Subtask | Estimate |
|---------|----------|
| [step 1] | X hrs |
| [step 2] | X hrs |
| ... | ... |
| **Total** | **X hrs** |
### What's Included
- [assumption 1]
- [assumption 2]
### Risks & Unknowns
- [risk 1 — impact on range]
- [risk 2 — impact on range]
### Recommendations
*(Required for XL tasks. Optional for S/M/L.)*
[For XL: always recommend a spike/discovery ticket instead of committing to a full estimate.
For L: flag if the task should be broken into smaller tickets.
For S/M: omit or leave blank if nothing noteworthy.]
General Multipliers (apply on top of base estimates)
| Condition | Multiplier |
|---|
| Greenfield (no existing codebase) | ×1.0 |
| Existing codebase, clean | ×1.1–1.3 |
| Legacy / messy codebase | ×1.5–2.0 |
| No design provided | +20–30% |
| Third-party integration (unknown API) | +50–100% |
| Accessibility (WCAG AA) required | +15–25% |
| Tests required (unit/e2e) | +25–40% |
| Multi-language / i18n | +20–35% |
How to stack multipliers
Apply codebase factor first (multiplicative), then additive factors on top of the result. Keep one decimal of precision in intermediate steps; round only the final number.
Worked example — base: 8 hrs for a dynamic Gutenberg block, clean existing codebase, no design, WCAG AA required, unit tests required:
8 × 1.2 (clean codebase) = 9.6
9.6 × 1.25 (no design, +25%) = 12.0
12.0 × 1.20 (a11y, +20%) = 14.4
14.4 × 1.30 (tests, +30%) = 18.7
→ round to 19 hrs (~2.5 days)
If multiple codebase-factor rows could apply, pick one (the worst-case one) — don't stack ×1.2 × ×1.5.
Effort vs Duration
The estimate is effort (focused dev time). Duration — wall-clock from ticket open to merge — is typically 1.5–2× longer due to code review, design handoffs, QA, deploy windows, and context switching. State both when the audience is a PM or client, not just engineers.
Example output: ~8 hrs effort / ~2 days duration (assumes 1 review round + staging QA)
Calibration
Log actual hours when closing the ticket. If actual vs estimated variance is >30%, note what caused the drift — this is the highest-value input for improving future estimates. Common drift sources: underestimated legacy debt, API surprises, scope creep in review, and QA finding edge cases late.
Tone & Communication
- Be direct and specific — give a number, not just "it depends"
- Always explain the confidence spread (what makes it wider or narrower)
- If the task is XL, a spike is the recommendation — not a wide range
- If critical info is missing, state what you'd need to tighten the estimate
- Keep output skimmable — the person likely needs to paste this into Jira, Linear, or a client proposal
