In agile development methodologies user stories are a common way of capturing requirements that need to be implemented by the development teams.
In my opinion user stories are a very good way to describe functionality from a user perspective, there is however one big pitfall that people always fall into with open eyes (time after time).
The biggest mistake you can make with a user story is to see it as as static description of functionality, basically a small part of a design. This is definitely not how user stories were intended. A user story is an element on the product backlog that evolves over time. It’s alive… It’s alive…
User stories are often referred to as Card Conversation Confirmation (Jeffries 2001).
- Card; The basics of a user story should be small enough to be written on a card or sticky note. Within one sentence you should be able to describe the functionality that is requested.
- Conversation; The most important role of a user story is to trigger conversation. A user story is not complete, it represents a customers’ requirements but it does not document them. Team members, product owners and stakeholders should always keep that in mind. The story is there to get people talking, not to provide a “design” (damn I said the D word).
- Confirmation; Even though conversation is the most important factor of a user story, it does not mean that the results of the conversation should not be stored in any way. The outcome of discussions related to a user story should be added as acceptance criteria, development notes, attachments, etc to the user story.
Ok this is all very interesting but you are probably thinking “I can find this in any wikipedia article or agile related book, but how does this actually work”. And you are absolutely right about this so let’s look at an example of how a user story progresses through an agile development process.