1

CRAFT STORIES THAT DELIVER

VALUE FOR CUSTOMERS

STORY QUALITY
CHECKLIST

INDEPENDENT

TESTABLE

Stories shouldnt overlap in concept,

and we would like to be able to schedule and implement them in any order.

We cant always
achieve this; once in a

There are three kinds of

dependency: overlap,

while we may say

things like 3points for
the first report, the n 1
point for each of the

order and containment.

I story is well enough understood that

after negotiation the UX/PM could
write a test for it.

NEGOTIABLE

This supports design

approaches that
minimise and manage
implementation
dependencies.

Stories typically represent at most a

few person-weeks worth of work. Some
teams restrict them to a few-person
days of work.

ESTIMABLE

VALUABLE

A good story can be estimated. We

A story needs to be valuable. We dont

care about value to just anyone. It
needs to be valuable to the customer.

A good story
captures the essence
and not the details.

dont need an exact estimate, but

enough to help the product manager
rank and schedule the implementation.

Story descriptions can be small as well.

Alistair Cockburn describes the cards as
tokens for future conversations.

We want to give the customer the

essence of the whole cake, and the
best way is to slice vertically
through the layers.

Being estimable is partly a function of be ing

negotiated, as it is hard to estimate a story
we dont understand.

Whats easy to estimate depends on the

teams experience.

Sometimes a time-boxed
spike it required to support
an estimate.

Developers often have an inclination

to work on only one layer at a time
(and get it right); but a full database
layer has little value to a customer if
there is no presentation layer.

THEN BREAKDOWN STORIES

INTO TASKS FOR
DEVELOPERS

S.M.A.R.T

Developers may have legitimate

concerns, but these nee d to be
framed in a way that makes the
customer perceive them as
important.

Original article at http://xp123.com/articles/

invest-in-good-stories-and-smart-tasks/

ment.

A team can treat non-functional requirements (such as performance) as things that

need to be tes ted.

Bigger stories are harder

to estimate.

TASK QUALITY CHECKLIST

Over time, the card may acquire notes, test

ideas, and so on. But we dont need these to
prioritise or schedule stories.

Adapted by Russell Kallman from articles by

Bill Wake and Mike Cohn . Famously referenced by Alistair Cockburn in one of his blog
articles.

Writing tests early helps us understand

whether the goal will be met by the develop-

SMALL

A good story is negotiable. It is not an

explicit contract for features; rather,
details will be co-created by the PM/
UX and programmer during development.

Time-Boxed: There should be an expectation of duration so

people know when they should seek help. If a task is harder
than expected, the team needs to know it, must split the task,
change players or do something to help the task get done.

Relevant: Every task should be relevant, contributing to the

story at hand. Stories are broken into tasks for the benefit of
developers, but a PM should still be able to expect that every
task can be explained and justified.

Achievable : The task owner should expect to be able to

achieve a task. Teams have a rule that anybody can ask for help
whenever they need it.; this includes ensuring that task owners
are up to the job.

Measurable: The key measure is, can we mark it done? The

team needs to agree on what that means, but it should include

does what it is intended to,tests are included, the code has
been refactored.

Specific: A task needs to be specific enough that everyone can

understand what is involved in it. This helps keep other tasks
from overlapping and helps people understand whether the
tasks add up to the full story.