User stories exist to help the programmer implement some functionality.
The user story starts the conversation between the user (knows what the software must do) and the programmer (knows how to make it do things). In order to get detail on exactly how it should work, the two must have an exchange of ideas - a conversation.
- Face-to-face with a whiteboard - by far the best method.
- Voice-to-voice (phone) - much less effective.
- Chat - Even worse and time-consuming but may be the best for long-distance teams.
- Emails - Terrible! For Pete's sake avoid email.
A great user story is ...
- Written by the user.
- Simpler is better.
- Informal is better.
Don't be afraid to INVEST in your user stories.
- Independant - Stories should be decoupled. A story should not require another one to be done first.
- Negotiable (And Negotiated) - The story isn't a contract. It requires a back-and-forth between programmer and user/author. The conversation is the key.
- Valuable - If we can't articulate how it helps the business, we have no business coding it.
- Estimable - From the story, we should be able to provide a ballpark estimate in ideal hours.
- Small - Small stories tend to allow us to release quicker, thereby getting functionality to users quicker and with less risk. Typical stories should be on the scale of a couple of hours to a couple of days. If they're larger than that, they can probably be broken into smaller stories.
- Testable - If you can't easily envision how you'll test this functionality, you don't understand it well enough. Testability is an absolute requirement for TDD.
(This awesomely sticky INVEST anagram comes from William Wake.)
Story Descriptions
Description should be in this format:
In order to [business's goal]
As a [user's role]
I want [software's new behavior].
We're placing the "In order to" in the front to emphasize the value that it has. If we can't easily put it into words, we should really consider omitting the feature.
(Adapted from: Liz Keogh's blog.)
No comments:
Post a Comment