Numerous articles on Scrum discuss story cards. They usually explain how the cards contain a user story, an informal statement about the value of a feature in the system to someone. A common form of the statement is:
, I want so that .
Most articles explain that the cards are merely an artifact to begin the conversation about the full requirements of the feature. Some teams transcribe the stories into spreadsheets, documents or project management systems.
At this point, some people may toss out the cards, but wait! Even if the story is documented electronically, the physical card has value for the project. Since the principal goal of story cards in Agile development is to raise visibility and focus for each feature, keeping story cards posted in a public place is a good way to do this. Think of the card as an icon for the full feature.
The card can also be a shortcut for the additional details associated with each story. For example, on each card we write a unique tracking ID, the story size, and the initial priority. If the story has a particular champion, the PO writes that person’s name on the back of the card.
|An all-too-familiar artifact|
This card shows the size, XL,
the original priority, 16th,
and you can see the value was
Even when a story is tracked electronically it is useful to revert to low-tech by printing the summaries on labels and putting them on sticky notes. For multiple, parallel projects use different colored cards for each one.
A word of warning about using story cards: watch out for the nighttime janitor or strong air conditioning. If there is a mysterious gap in the backlog, you might want to look around on the floor. This emphasizes the need to keep an electronic copy of the stories in a spreadsheet or requirement management system.
<< Previous Tip
Next Tip >>