Task

Origin & evolution

The task as a planning primitive comes out of the iterative-planning tradition, formalised in Scrum. The Scrum Guide, written by Ken Schwaber and Jeff Sutherland, does not actually use the word "task". It speaks of Product Backlog Items and of the Sprint Backlog being decomposed by the developers, "often to units of one day or less". Teams supplied the word "task" for those day-sized units, and it stuck.

The useful distinction the practice settled on is between the what and the how. A Product Backlog Item, often written as a story statement, expresses what value is wanted. The tasks beneath it express how the developers intend to build it. Mike Cohn made the same split explicit in agile estimating and planning: stories are owned by the whole team and estimated in relative points, while tasks are an implementation breakdown the developers create during planning, sized in hours. Ownership matters here. Decomposition into tasks is the development team's job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →, not the product owner's, because the how is an engineering decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →.

The risk🎲RiskComplianceA risk to the product or businessView reference → the field learned the hard way is task-shaped thinking. A backlog of two hundred tasks with no visible parent value reads as motion. Bill Wake's SMART tasks (Specific, Measurable, Achievable, Relevant, Time-boxed) were proposed in 2003 as the task-level counterpart to INVEST, a reminder that a task still has to earn its place against the story it serves.

How it works in practice

A team picks up the statement "As a finance admin, I want to export transactions as CSV". During sprint planning the developers break it into tasks: build the export endpoint, write the CSV serialiser, add a column-mapping config, handle the 200,000-row pagination case, write the integration test. Each is a few hours. Each is owned by whoever picks it up.

The breakdown does real work. The 200,000-row task surfaces a performance question that would otherwise have ambushed the team mid-sprint. The integration test task makes the acceptance criteria executable. None of the five tasks is independently shippable; the finance admin gets nothing from the serialiser alone. The increment becomes valuable only when the parent statement is complete, which is the line that separates a task from a story.

Task vs. its neighbours

• Story statement is a user-valuable increment with a named beneficiary. A task is a step toward delivering it, with no user inside. "Export CSV" is a story; "write the CSV serialiser" is a task. The first can be demonstrated to a stakeholder🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference →; the second cannot.
• Feature⭐FeatureProduct SpecificationA product capability or featureView reference → is a larger capability💪CapabilityStrategyAn ability that enables value deliveryView reference → that decomposes into several stories or directly into tasks. The relationship is hierarchical: a feature contains the work, a task is a leaf of it. Estimating a feature in tasks without the intermediate value layer tends to hide the trade-offs.
• Acceptance criterion✅Acceptance CriterionProduct SpecificationA condition that must be met for a story to be doneView reference → is a condition that proves a story is done. A task is work to be performed. A criterion is checked; a task is completed. They meet when a task is "make criterion 3 pass", but they answer different questions: one is a test, the other is an action.

In the graph

In the Unified Product Graph, task☑️TaskProduct SpecificationA unit of work within a story or epic lives in the product specification region as the leaf of the delivery hierarchy. Its edges keep it tethered to purpose. task_implements_story_statement ties each task back to the value it serves, so a task that implements no statement is a queryable orphan. feature_decomposes_into_taskFeaturedecomposes intoTaskhierarchy lets larger capabilities break down directly into work, and task_has_subtaskTaskhas subtaskTaskhierarchy allows finer splitting when a unit grows past a day. The fourth edge, research_question_generates_taskResearch QuestiongeneratesTaskcausal, captures the case where investigation🔍InvestigationEngineeringAn investigation into an issue or incidentView reference →, not a feature, is the origin of work: a study raises a question, and answering it spawns tasks. Modelling tasks this way makes the backlog auditable, because every unit of work can be traced upward to the user value or the open question that justifies it.