Card Cheatsheet

gistfile1.txt

# Cheatsheet : Writing Story Cards

## Remember Your Audience

Each feature & task card has *all* of these readers:

* **Stakeholder** - reviewing & approving the story
* **Project Manager** - estimating, staffing, & planning for the implementation
* **Developers** - estimating & implementing the story
* **Quality Assurance** - verifying the implementation
* **Stakeholder (again)** - accepting the final implementation

## Features: The Big Story

A feature defines a "finish line", not a list of tasks.

* **Who** - What type of user is doing the action?  Are there more than one?
* **What** - What does the user want to accomplish?  What problem are they solving?
* **When** - How often?  For how long?  Before, after, or during a specific event?
* **Where** - Where is the user physically? (office, emergency room, aircraft carrier deck) What kind of device? (laptop, cellphone, tablet)
* **Why** - Why does the user want/have to do this?  Why does our client want this feature?
* **<strike>How</strike>** - Leave the implementation details to the designers & developers!

## Tasks: Bite-Sized Stories

Most cards are "tasks" and they have the following sections:

* **Motivation** - How does this task fit into the larger feature?
* **Acceptance Criteria** - A terse description of the task, and how you'll know it's done.
* **Tech Notes** (optional!) - *Hints* on how this card might be implemented.  Technical bits that will save developers and/or QA time.
* **How To Test** (optional?) - *Instructions* or time-saving *tips* for QA & stakeholder testing, usually written by the implementing developers.

## Cards: Features or Task?

* Depends on the project and the stakeholders.
* We often blur the line between features & tasks.
* We tend to stuff "round" feature-pegs into "square" task-holes.
* If in doubt, start with tasks and only build up to features if necessary.

## Features & Tasks Tips

* Cards are placeholders for conversations.
* Cards should NOT capture all details.
* Cards should NOT dictate implementation.
* A card is NOT a failure if a few clarifying questions are necessary.  This is expected as implementation uncovers small details.
* A card is a failure if it confuses the team into building the wrong thing.
* The most common mistake is omitting the user type who will use the feature.
* Keep a "grab bag" list of small, stand-alone tasks that don't fall under a specific feature.
* Give the reader just enough that they can make reasonable judgements on if the feature/task is being implemented correctly.
* Have someone review your cards if you cannot pair on them.
* Err on the side of readability, never on detail.
* Call a "time-out" to change your card stories when a big project assumption changes!
* If you can't tell a good story about it -- something is wrong!

## Storytelling Devices

* "In Media Res" - Start in the middle of the story.
* "Chekhov's Gun" - Do not include any unnecessary elements in your story.
* "Red Herring" - Don't distract or lead your audience on a wild goose chase.
* "The Hero with a Thousand Faces" - Our user is the "hero," and we are only the "mystical advisors", preparing the user with "weapons" and knowledge.  Our user must fight the "dragon" without us.