Storycard

From EUDP
Revision as of 07:38, 15 May 2009 by Klaus (Talk)

Jump to: navigation, search

What

On simple index cards let the customer write short stories which each describes a single functionality. The developer can help the customer write the stories.

How

The dish

Storycard

Ingredients

  • A Story: a sentence or two describing a simple functionality of the system from the customer's point of view. It may be appropriate to include additional information such as:
  • a card number (identity) which may also describe the number of editions
  • the date of creation and latest edition
  • the project/system identity (for example name or number)
  • the customer name (editor) and developer name
  • the priority of the story with regard to implementation in the project
  • comments on the purpose of the story

Process

The developer asks the customer to write stories on the storycards in order to communicate development needs. It is advisable that the stories are written in co-operation with the developer to ensure that the storycards are as simple as possible. It is then very important that the developer is careful only to suggest how to break the functionality into pieces, not to suggest which functionality to implement.

The storycards should only contain a description of the functionality from the customer's point of view; no implementation, no infrastructure.


Why

In the preproject phase storycards can be used to describe and structure the functionalities of a system. Storycards are simple index cards which each contains a story describing a single functionality of the system.

It is very important to keep the storycards as simple as possible, where each card only describes one business functionality. Otherwise the story on one storycard may start to predict how the different functionalities should interact and how the architecture/structure should be. The storycards should only contain information about the functionality which is to be implemented; it should not contain information as to how this should be implemented.

The storycards also help to keep the implementation simple. Estimations of time consumption are more accurate, because it is easier to predict the time needed to implement a single functionality rather than predicting the time needed for implementing a more complex system.

A practical advice is to keep the storycards in a box eventually arranged after implementation priority. If you keep the index cards in a box, arranged after implementation priority, it will give the customer the possibility of changing priority easily.

The use of storycards is flexible in the way that stories (cards) can be changed or even removed easily by the customer without interfering with other stories. New stories can be written by the customer simultaneously with the implementation of other stories.


Example

Storycard-empty.gif Storycard-filled-in.gif