Storycard

From EUDP
Revision as of 09:17, 23 April 2015 by Charlotte (Talk)

Jump to: navigation, search

What

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

How

The dish

Storycard

Ingredients

  • A Story: One or two sentences describing a simple functionality of the system from the customer's point of view - the customer's needs.

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, each containing a story describing a single functionality of the system.

It is very important to keep the storycards as simple as possible with each card describing only 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, arranged in order of implementation priority if possible. If you keep the index cards in a box arranged in order of implementation priority, it will give the customer the possibility of easily changing priority.

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

StorycardsEx.png