What Should We Capture on the Story Card?

The way to think about the information on a card is that, while you do not list out all the details you have, you use the card to capture the basics, to act as a reminder and to provide information on where to find more details if required. One way to think about the level of information is to think about an old library system to find books - an index card would allow you to find the information you need.

On a card, even if that card is implemented in an agile tool, you will typically find the following information:

  • Title: Experience shows that cards (and tools) get very “busy” if you use the user voice format of the story to reference it. After spending time with the story, people will naturally use short cuts to reference the information. This is the short cut and is used to reference the requirement in discussions and meetings. Titles work best when it completes the statement:
    • “I wish I had…” or
    • “I wish the system would…”.
  • Description: This is user voice version of the requirement - who, what, why in the “as a”, “I want”, “so that” format.
  • Acceptance Criteria: This is the understanding of the how you know you have finished the worked from an end user perspective.
  • Other Information: Information such as:
    • Estimate of size. This is typically in the form of story points.
    • Value of value to the business if it is implemented. This might be as simple as Small, Medium, Large, but could also be more sophisticated than this.
    • Dependencies
    • Status. Could be as simple as “To Do”, “In Progess” and “Done”.

If you are doing this with physical 5×3“ index cards, the back of the card will have the acceptance criteria and other notes that come up during the discussion, while the front will have the title, description, estimates, etc.

A couple of reminders:

  • The main purpose of the user story is to have a conversation, so this is really just a reminder for that.
  • If you use a some kind of tool to track work, you will need to replicate the updated information from the card to the tool.
  • Some teams prefer to use these cards as a big visible radiator of information, even if they have some kind of tool because there is something more visceral about physical boards. What ever works for the team, but this also means that the team would need to update the tool as well in most corporate situations. Try to figure out the minimal updates required to support the work and the corporation.
You could leave a comment if you were logged in.
  • /home/hpsamios/hanssamios.com/dokuwiki/data/pages/what_should_we_capture_on_the_story_card.txt
  • Last modified: 2018/12/29 13:40
  • by Hans Samios