Playbook · 12 min read
A 59-question playbook for engineers, tech leads, and delivery managers. Covers objective, context, scope, assumptions, dependencies, Gherkin acceptance criteria, estimates, and ownership. Built on SMART, DACI, and the Definition of Ready.
TL;DR
Stories describe outcomes for users. Tasks describe work to be done by a named person in a bounded time. The gap between a one-line reminder and a finishable task is the set of questions below. Run them before a task enters a sprint, not after it stalls halfway through.
Clear the terminology first
These three get conflated in refinement, which is how a half-defined chunk of work ends up labelled whatever the team is least embarrassed by. Pick the right label, because the label changes the questions you ask.
Type
An outcome for a user, written in the As a, I want, So that format. Lives in the product backlog. Answers why.
Type
A unit of engineering or operational work that moves a story forward. Sits under a story or epic. Answers what and how.
Type
A time-boxed research or proof-of-concept task. Acceptance criterion is a decision, not working code. Always has a deadline.
Foundations
Each question in this playbook maps to one of three patterns. Pick the pattern first, then the questions become obvious.
Framework 01
George Doran, 1981. The clarity checklist.
Framework 02
Intuit origin. The ownership model.
Swap in RACI if your org prefers it. Either way, name one Driver.
Framework 03
The gate model.
Ready gates entry. Done gates exit. Both are team-wide, not per-task.
The question bank
Work top to bottom when the task is risky, cross-team, or new ground. Cherry-pick for routine work. Any blank row is a red flag worth logging explicitly rather than leaving unanswered.
A task is a promise to produce something specific. If you cannot describe the outcome in a single sentence that a new joiner would understand, the task is not ready. Borrow from SMART: Specific, Measurable, Achievable, Relevant, Time-bound.
Question B from your intake sheet lives here.
Context is the reason future-you, or a new joiner, will spend two hours re-reading the ticket before asking questions in Slack. Front-load it.
Question C from your intake sheet lives here.
Scope is the fence around the work. If the fence is fuzzy, the task grows until it collides with another sprint. Write the inclusions down.
Question D from your intake sheet lives here.
The "out of scope" list is worth more than the "in scope" list, because it stops the task growing overnight. Say it out loud, in writing, even if it feels obvious.
Question E from your intake sheet lives here.
Every task carries assumptions, whether you wrote them down or not. The ones you wrote down are debatable. The ones you did not become the root cause of the next incident.
Question F from your intake sheet lives here.
A task with no named owner and no named tool is a task that sits in the backlog for six months. Match the work to the people and the kit needed to finish it.
Question G from your intake sheet lives here.
A task that quietly waits on someone else is a task that misses the sprint. Name the dependency, the owner, and the date.
Question H from your intake sheet lives here.
Tasks that look internal still need acceptance criteria. A migration is done when the rows match. A refactor is done when the tests still pass and the diff is reviewed. Write the rules, even when the task is engineering-facing.
Question I from your intake sheet lives here.
A task without a size is a task that will eat a sprint. Pick an estimation style, commit to it, and time-box anything exploratory.
Every task has one owner and many stakeholders. Confusing the two is how tasks become meetings.
Copy and paste
Paste this into your Jira ticket, Linear issue, or the description of a tracked task. Columns A through I mirror the intake sheet most delivery teams already run. Columns J through O are the fields that typically get added after the first task slips.
| Field | What to capture |
|---|---|
| A. Task title and parent | One-line summary plus link to the parent story or epic. |
| B. Primary objective | The single outcome this task delivers. |
| C. Context and background | Why now, prior attempts, relevant docs. |
| D. In scope | Files, services, or surfaces being changed. |
| E. Out of scope | Adjacent work deliberately deferred. |
| F. Assumptions | What we treat as true, and how we would know if wrong. |
| G. Skills and resources | People, tools, licences, environments needed. |
| H. Dependencies and inputs | Blocking tickets, vendors, approvals, with owners. |
| I. Acceptance criteria | Gherkin or a bulleted rule list that proves done. |
| J. Estimate | Points, hours, t-shirt, or time-box for a spike. |
| K. Owner (Driver) | Single accountable person. |
| L. Reviewers and approvers | Who signs off, and on what. |
| M. Risks and mitigations | What could go wrong, what we do about it. |
| N. Reporting cadence | Where updates are posted and how often. |
| O. Closing ritual | Demo, hand-off, or artefact to attach at close. |
When you have 10 minutes
Not every task needs the full bank. For routine work, or for tasks that enter the sprint on short notice, this is the shortest responsible version.
FAQ
A user story describes an outcome for a user, written in the "As a, I want, So that" format. A task is a unit of engineering or operational work that moves a story forward. Stories live in the product backlog. Tasks live under a story or an epic. One story can produce many tasks: the backend change, the frontend change, the migration, the docs, the rollout. Stories answer why. Tasks answer what and how.
SMART stands for Specific, Measurable, Achievable, Relevant, Time-bound. It is a 1981 management heuristic by George Doran that survives because it forces clarity on the two things most tasks skip: a testable definition of done and a deadline. A SMART task names the outcome, the way the outcome is verified, the effort or date, and how the task connects to something the business cares about.
Small enough that one person can finish it inside a sprint, and ideally inside a few days. If a task needs more than two engineers or spans sprints, it is probably a story, or needs to be broken up. A common rule: if you cannot describe the work in a single sentence and estimate it in under a minute, split it.
Either works, but both should be time-boxed. A spike is a research or proof-of-concept task with a fixed duration and a decision as its output. The acceptance criterion for a spike is not "the code works" but "the team has enough information to commit to an approach". Close it at the time-box whether it succeeded or not, and write down the decision.
Yes. Even a refactor or a migration has criteria: the tests pass, the diff is reviewed, no new warnings, no regressions in the targeted metric. For behavioural tasks, Gherkin (Given, When, Then) is clear. For structural tasks, a bulleted list of conditions is fine. The rule is the same: if you cannot verify done, you cannot finish.
Both assign ownership. RACI names the Responsible, Accountable, Consulted, and Informed parties. DACI names the Driver, Approver, Contributors, and Informed. DACI is lighter and better suited to fast-moving task-level decisions because it explicitly names a single Approver. RACI is more formal and fits programmes and governance. For a single task, DACI is usually enough.
When the estimate grows past what one person can finish in a sprint, when two skills sets are needed (backend and frontend, or build and release), when the task crosses a deploy boundary, or when two parts of the work can be verified independently. Splitting is cheap. Recovering from a task that quietly sprawled is expensive.
Definition of Ready is the checklist a task must pass before it enters a sprint: objective clear, scope known, dependencies resolved, acceptance criteria written, owner assigned. Definition of Done is the checklist every task must pass to be closed: code merged, tests green, docs updated, observability in place, review signed off. Ready gates entry. Done gates exit.
Related reading
Product · Playbook
78 questions for the story layer above tasks. INVEST, the 3Cs, and Example Mapping.
Read the playbookQA · Playbook
66 questions for the defect layer. Reproduction, environment, evidence, severity vs priority, regression analysis.
Read the playbookOr skip the questions
Backlog.cloud joins your refinement or planning call, listens to the conversation, and pushes a Jira-ready task with objective, scope, assumptions, dependencies, acceptance, and owner captured. Every question in this playbook, every time.