User Stories

A user story describes a piece of functionality from the users perspective:

Example: After clicking the submit button the entries are checked using plausability rules. If no error is detected, the ticket record will be inserted into the database.

The customer wants to be sure (and he also has the right!) that the user story is implemented correctly. In order to achieve testability, the customer specifies - or even better implements - acceptance tests, which enable him, to easily check the correctness.

Although there is nothing like an "optimal size" for a user story, it typically represents work worth 2 to 3 days of effort. This means that a pair can implement a user story and its associated acceptance tests within 2 to 3 days. Whether it is always 2 to 3 days depends on the individual XP teams.

The programmers estimate the required effort for a user story by figuring out which tasks are necessary in order to implement it. The effort for each task is then estimated. Finally, the effort for the tasks is summed up and results in the total effort for the story. Based on this estimate the user can translate the effort into cost. In turn this enables him to make a sound decision on the order in which the stories are implemented, or whether a story gets implemented at all.

Splitting a User Story

In each release cycle the programmers implement several user stories. Sometimes it turns out, that some time is left over, or that a user story does not fit completely into the remaining time of the release cycle. In this case the user story should be split up into two pieces: one part to be implemented in the current release cycle, and one part to be moved into the next release.

In all cases, this should be done with the involvement of the user. It is him, who decides what gets implemented and when.

Dependencies

In rare cases, you might think, that there are dependencies between stories. Take the following examples:

Story 1: Show a list of all registered users.

Story 2: Add a new registered user.

At first sight, it looks as if story 1 can be implemented only after story 2 has been finished. If you take a closer look, then you might just add one single task to story 1 in order to have some users to display.

For instance if registered users are stored in a SQL database, then you could write an SQL script that simply fills the table "Users". It just takes a few minutes, but allows you to either implement story 1 first - or - to have a second pair working on story 2 in parallel.

Examples

The following pictures show two user stories from our project:

Tips

• Consider splitting if a user story requires an effort of more than 2 to 3 days to implement.
• If a story does not fit onto one story card, consider splitting the story.
• For user interfaces staple a drawing onto the back of the story card.