Writing Good User Stories
Over the last few weeks, I've written alot about writing good User Stories - you can see them all here: User Stories.
User Stories are a simple way of capturing user requirements throughout a project - an alternative to writing lengthy requirements specifications all up-front.
As a guide for people writing User Stories, they can follow this basic construct:
As a [user role], I want to [goal], so I can [reason].
This helps to ensure that the requirement is captured at a high level, is feature oriented and covers who, what and why.
As well as capturing User Stories in the above format on the Product Backlog, User Stories should be written on a card.
The card comprises 3 parts:
Ultimately, User Stories should be small. But when they're first entered on the Product Backlog, when they're quite a way from being developed, they can start out large and fuzzy. While they are in this state, they are known as Epics.
Software requirements are a communication problem. There is no perfect solution. User Stories seek to find a balance between written and verbal requirements, relying on collaboration between team members to clarify details near the time of development.
Here's a PowerPoint presentation about User Stories to help share the concept with others.
The INVEST acronym can help you to remember and assess what makes a good User Story. User Stories should be:
* Independent. Okay, for some systems, it's near impossible to make each feature completely independent. In other solutions, e.g. web sites, it's easier. But it's an important aspiration. User Stories should be as independent as possible.
* Negotiable. User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.
* Valuable. User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.
* Estimable. User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.
* Small. User Stories should be small. Not too small. But not too big!
* Testable. User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.
I hope this series of posts has been useful. If you want to browse through all these posts about User Stories, you can do so here: Writing good User Stories.
Kelly.
User Stories are a simple way of capturing user requirements throughout a project - an alternative to writing lengthy requirements specifications all up-front.
As a guide for people writing User Stories, they can follow this basic construct:
As a [user role], I want to [goal], so I can [reason].
This helps to ensure that the requirement is captured at a high level, is feature oriented and covers who, what and why.
As well as capturing User Stories in the above format on the Product Backlog, User Stories should be written on a card.
The card comprises 3 parts:
- Card (i.e. the bit above, "as a user, I want...")
- Conversation (notes and/or small wireframe to remind people about the feature)
- Confirmation (the tests that will show the feature is complete)
Ultimately, User Stories should be small. But when they're first entered on the Product Backlog, when they're quite a way from being developed, they can start out large and fuzzy. While they are in this state, they are known as Epics.
Software requirements are a communication problem. There is no perfect solution. User Stories seek to find a balance between written and verbal requirements, relying on collaboration between team members to clarify details near the time of development.
Here's a PowerPoint presentation about User Stories to help share the concept with others.
The INVEST acronym can help you to remember and assess what makes a good User Story. User Stories should be:
* Independent. Okay, for some systems, it's near impossible to make each feature completely independent. In other solutions, e.g. web sites, it's easier. But it's an important aspiration. User Stories should be as independent as possible.
* Negotiable. User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.
* Valuable. User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.
* Estimable. User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.
* Small. User Stories should be small. Not too small. But not too big!
* Testable. User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.
I hope this series of posts has been useful. If you want to browse through all these posts about User Stories, you can do so here: Writing good User Stories.
Kelly.
11 April 2008 12:30
Kelly,
congrats, a very good summary.
PierG
http://pierg.wordpress.com
7 February 2009 15:12
Hello
Nice set of articles. I read the comments on making user stories Independent. Making a user story Independent is really hard especially on large projects.
Pat
18 April 2009 18:17
This article reminded me about one user story that was once presented to me as an example. In this case the user were prospects at a trade show that would need a demonstration of a hypothetical company's yet-to-be-completed software product. So given a limited time to include the features of the product in a demo, what do you include.
Almost everyone thought that a login would be necessary, which seems like a logical starting point. However, for the purposes of a demo, it really isn't that necessary. It is not exactly a feature you want to show off. Much better to focus on features that will impress and bypass the login.
22 April 2009 21:16
Kelly,
Very useful and well written. It helped me come up to speed with Agile, a lot of PMs will find this a good starting point.
Best,
Rajeev
3 September 2009 09:21
very nice article
,
bhavtosh