The Art of Storytelling

 In User Stories Applied: For Agile Software Development, Mike Cohn defines user stories as simple, clear and short descriptions of customer valued functionality. They are composed of three aspects:

1. A brief description of the story used for planning.

2. Conversations of the story that serve to flesh out the details.

3. Acceptance tests to determine when a story is complete.


User stories offer a number of advantages over requirements documents and use cases. These include:

1. Emphasis on verbal rather than written communication.

2. Encourage deferring details until you have a better understanding about what you really need.

3. Provide the right size for planning.

4. Are comprehensible by customers and developers.

5. Work for iterative development.


Good user stories should follow the INVEST principle:

1. Independent: Stories should not be interdependent as this might lead to prioritization and planning problems.

2. Negotiable: A story should be brief and it is not a detailed contract. It should encourage conversation and negotiation between the customer and the developers.

3. Valuable: A story should provide value to the customer or the user.

4. Estimatable: Developers need to be able to estimate a story. It should be written in such a way that the developers can understand it and have an idea of how to implement it.

5. Small: Not too big, not too small, but just right!

6. Testable: Stories should be testable in order to verify that a story is complete.


Additionally, good user stories follow these guidelines:

1. Start with Goal Stories: For each user role, identify the top priority goal for that user.

2. Use Templates:

• a. Use the following template to incorporate User Role and Value into a story: - As a [type of user], I can [goal] so that [reason].

• b. Use this template for acceptance tests: Given [context] And [some context] When [event] Then [outcome] And [another outcome].

3. Slice Vertically: Stories should represent some level of end to end functionality. This reduces overall risk and delivers some value to the customer.

4. Annotate Stories with any constraints.

5. Keep the UI Out for as long as possible: This avoids mixing requirements with a specific solution.

It is important to remember that the main purpose of a story is to act as a reminder and encourage conversation to flush out details the closer we are to implementing a story. Also, not everything needs to be a story. Some aspects of the system might be expressed better using different formats.