Outcome, not chore

A task names work to do. A story names a change in what someone can do once the work lands. The test that separates them is whether anything a role can use changed.

That test is demonstrability: a story can be demoed, a chore cannot. Sort the eight Portal work items on the right by whether a role could be shown the change — the stories all can be, the chores all cannot.

The definition Reframe a chore On the Portal References

The demonstrability test · switch the lens

Lens: all items · 8 of 8. Four can be demoed (the stories) and four cannot (the chores). The check beside each item is the demonstrability test.

A task is work; a story is a change

A task — a chore — names work to do. “Add the courses table.” “Wire the LiveView socket.” It is real work, often necessary, but once it is done nothing a role can observe has changed: a seeded table is not something a learner can use. A story names a change in what a role can do. “A learner browses the catalogue of courses.” Once it lands, someone can do something they could not before, and the change is visible.

The line between them is one question, the demonstrability test: can you sit a role in front of the result and show the change? If yes, it is a story. If the only thing to point at is a schema or a wired socket, it is a chore. A chore can be true and done and still demo nothing — because demonstrability asks about an observable change for a role, not about effort spent.

task / chore: A unit of work to do. Real work, often necessary — but nothing a role can observe changed. Placed by the story it serves, not on the backlog of its own.
story: A unit of value: a change in what a role can do once it lands. Observable, and therefore a backlog item.
demonstrability test: Can a role be shown the change? Yes → a story. Only a schema or a socket to point at → a chore.
acceptance check: The demo, written down: Given / When / Then. A story has one; a chore has none.

Demonstrability is why the loop can prove a slice before the next begins: a story carries its own demo, so “done” is something a role can watch happen, not a claim about work spent.

Reframe a chore as the outcome it serves

A chore is rarely wrong — it is only the wrong unit. Each chore is a step inside building some story, and the story is the unit that belongs on the backlog. The move is to ask, for any chore, “what can a role do once this and its siblings land?” and to name that outcome instead.

Switch the toggle below to re-render one Portal item between its chore phrasing and the story it serves. The chore changes nothing a role can see; the story it serves is demoable, and the chore becomes its means.

One item, two framings · switch the view

As a chore: “add the courses DB table.” Demoable: no — nothing a learner can use changed. It is a step in building a story, not a backlog item of its own.

A chore is how a story gets built; the story is what gets demoed. Name the outcome, and the chore becomes its means.

The demonstrability test on the Portal

On the Portal — the learning platform this course builds — take the rung “a learner browses the catalogue of courses.” Underneath it sit chores: add the courses table, seed it, wire the catalogue read. None of those, alone, is demonstrable. The story is: open the catalogue, and every published course is listed. Its acceptance check is its demo, written down.

# A chore: real work, but nothing a learner can observe on its own.
#   add the courses table · seed it · wire the catalogue read

# The story it serves — demonstrable, with its acceptance check as the demo:
Given a non-empty catalogue,
when  a learner opens it,
then  every published course is listed.   # this is what gets demoed and accepted

The chores are how the story is built; the story is what gets demoed and accepted. The same split holds one rung up: building the catalogue may use Portal.ID.generate/1 to mint a course id, but “mint an id” is a chore inside the story — the demo is the listed catalogue, not the id.

The principle

A backlog item is a unit of demonstrable value — a change a role can use, not work done. The test is whether a role can be shown the change.

On the Portal

“Browse the catalogue” is the unit on the backlog; “add the courses table” is a step inside building it, demonstrated through the story, never on its own.

Demonstrability is the line: a story can be demoed, a chore cannot — so the story is the unit of work, and the chores are its means.

Recap — name the outcome

A task is work to do; a story is a change in what a role can do. Demonstrability separates them: a story carries its own demo, a chore carries none. Name the outcome a role gets, and the chores fall into place beneath it as the means. The next dive asks the question that makes an outcome concrete: who, exactly, is better off?

Next in A2.01: A2.01.2 · Who benefits — every slice names a role and the value to that role, and value, not effort, is the ordering key for the backlog.

References

Sources for the story-not-task distinction and the demonstrable increment, and where this dive connects in the course.

Sources

Cohn, M. — User Stories Applied — a story is a unit of value, not a unit of work.
Beck, K. — Extreme Programming Explained — the increment is demonstrated to the customer.
Hunt & Thomas — The Pragmatic Programmer — tracer bullets: build a thin, observable thread first.

Related in this course

A2.01 · Value, not tasks — the module hub.
A2.01.2 · Who benefits — the next dive.
A2.01.3 · The vertical slice — value through the layers.
A1.04.2 · The spec layer — the acceptance check the demo becomes.
A2 · Decomposition — the chapter.
Companion · Functional Programming in Elixir — the Portal’s foundations.