"Hours" Sequence
Estimating in hours is controversial in agile for good reason: hours conflate effort, complexity, and duration into a single number, and they imply a precision that software development rarely delivers. Standard agile advice is to use story points instead. That said, hours estimation is genuinely appropriate in specific contexts: operations tickets with known patterns ("we always deploy in about 4 hours"), support engineering where tickets are scoped and time-tracked, design tasks where the output is a defined deliverable, and any work that is repetitive enough for the team to have a reliable baseline. The Hours deck (2, 4, 8, 16, 24) covers half-day to three-day tasks — the range where hour estimation is most meaningful.
Cards: 2, 4, 8, 16, 24.
How to use "Hours" Sequence in planning poker
Before using this deck, agree on what an hour means for your team: "calendar time" (including meetings and context-switching) or "focused work time"? The distinction matters more than it sounds. Establish a reference task the team has completed recently — "the last server migration took about 8 hours" — and estimate relative to that. Review estimates against actuals after each sprint for the first few cycles. If your estimates are consistently off by more than 50%, hour estimation is not well-calibrated for your work type and you should switch to story points.
Example tasks and point mappings
2h: Update a dependency and run tests, write a one-page technical spec. 4h: Deploy a security patch across environments, conduct a design review session with stakeholders. 8h: Infrastructure migration for a single service, create wireframes for a new feature flow. 16h: Load testing campaign for an upcoming release, audit and document an existing API. 24h: Set up a new environment from scratch, conduct and synthesise user research interviews.
When to consider a different deck
Novel software feature development where unknowns are significant. Hours estimation on engineering stories consistently produces overconfident estimates and creates implicit calendar commitments that teams then feel pressured to meet. If your work involves meaningful design decisions, third-party unknowns, or complex system interactions, use Fibonacci instead.
Related reading