Story Card

This page is about an IndexCard used in ExtremeProgramming to hold a UserStory.

The snips below are things I found in the XpMailingList archive when I was researching this - SteveCline - however- later discussion of StoryCards on the XpMailingList indicates that they typically contain just the story title, a descriptive paragraph if needed, and an estimate

Images of some of the first actual eXtreme Programming StoryCards are now posted at http://www.xprogramming.com/xpmag/story_and_task_cards.htm. That page is thumbnails: the actual files are large. Note that these cards are excessively complex for almost any purpose. C3's project manager made them and included every field he could think of, based on something RonJeffries was sketching at the time. The team never used all those fields, and quickly went back to blank cards. Don't try this at home.

Looking at what was actually filled in on the example cards, I would assume a simplified version would be a nearly blank card, with a spot for Date, Type (New,Fix..), Area & Number, with the rest of the card for the description.

"If you find yourself running out of room on the cards, use smaller cards". --PhlIp (NOT TomPoppendieck?!)

At 06:21 PM 6/1/2000 +0000, Merlin wrote:

>What are the best tools for tracking user stories?

Here are some REALLY easy tools, i.e. cards and pen/pencil.

Write them on cards.

Estimate them, writing estimate on card, as you plan the release. Now you have tracked the expected cost of each story. Update the estimate from time to time.

When you schedule them in an iteration, write the date on the card, if you want to know when you did it. Write the finish date when it comes back done. Else reschedule. Write actual time to implement if you want to track estimate vs actual.

When you define acceptance tests, write their numbers or file names on the story card they test. Now you are tracking requirements against tests.

When you get a story done, move it to a separate pile from the not-done ones. The size of the piles tells you how nearly done you are.

What else might we want to track?

from RonJeffries on the XpMailingList

Description of how to build a "card rack" moved to ManagingCards

And yet one more from the XpMailingList:

Date: Thu, 1 Jun 2000 19:07:14 -0600 From: "Jim Little" <jiml@inconnect.com> Subject: Re: Re: Tracking User Stories

> Maybe not so much "track" as "organize". By author, priority, > subject, etc... So that other team members can see them and I can > keep pace with status. Maybe even a tool in which the stories can be > entered electronically instead of on cards (?)

I put all the user stories for the current iteration on a whiteboard, vertically by user priority. Then all of the engineering tasks related to each story horizontally by priority. When we work on a task, we take it off the whiteboard and draw a box to hold its place. When we're done, we put it back. (This also addresses the danger of losing cards -- we had a couple of scares at first, but no longer.)

This approach seems to work pretty well -- it allows everybody to see the entire status of the iteration at a glance. We draw green boxes around tasks and stories that are entirely done, so you can easily get a rough idea of status even at a distance. If you want more detail, you walk up to the whiteboard and read descriptions.

We hold the cards in place with business card magnets that we cut up into small pieces.

-- Jim

Would a simple card look something like this?

 ID#_____ USER STORY PRI__  EST ___
 <Story name>_____________   |
 Source: ______    |
 <Story text>     |
 ...
 Start date     Finish Date

and on the back:

 Acceptance Tests (or IDs)

Is this The Simplest Thing That Could Possibly Work? -- SteveCline

I don't think so. Why do you need: ID#, PRI, Start date, Finish Date, and Acceptance Tests? Why not just Name, Estimate, Source (so you know who to ask about details), and text? -- Anonymous

Some people use ID#'s for tracking purposes. PRI is for priority level, which is helpful during release planning and iteration planning. That way, the customer gets what they need most early on in development. You may not need start date and finish date because that's really determined by release planning and iteration planning, but you may need a "need by" date to give a story a drop dead date. Acceptance tests should be attached to card, not actually on the card. Acceptance test IDs are acceptable (just in case the tests get separated from the stories). -- JustinHickman

Seems to me that you would want to have start and end dates as feedback for when you revise and make new estimates. I guess if you are doing XP you need to write that information down somewhere, so why not on the story card? -- ChrisSteinbach

CategoryCrcCards CategoryStories