Jump to: navigation, search


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


The dish



  • 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.


A good rule of thumb of how to write a storycard is to include an actor who performs an action (with the system-to-be) in order to expect a specific result. So in bullets:

  • Who does it?
  • What does actor do?
  • Why does actor do it?

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 and follow the rule of thumb given above.

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

The priority is given by the customer indicating the importance and value of the functionality expressed in the story.

The initial cost calculation is based on the developer's initial estimate of the costs in units. Units can be hours/days of work, or anything else that the developer uses to measure or express workload.


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 is to 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.

There are two ways to store the storycards:

  • On a Kanban board as described under Development_Planning_Realisation#Kanban_Board or
  • In a box and 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.