Everybody loves a good story. In agile, the classic template of, “I want to do something in order to get this result or benefit,” is enough to get work moving smoothly. What are the inner workings that really allow user stories to function smoothly though? Allan Kelly answers this question in an article for Agile Connection.
A Tale of Progress
As we all know, agile encourages just-in-time requirements over comprehensive documentation upfront. The product owner (or some equivalent) should be the person who understands the requirements, and thus should know where the user stories are. Kelly finds that user stories adhere well to agile because they embody these three things:
- Lightweight: They don’t impose a lot of (upfront) costs on the team.
- Easy to understand: You don’t need a five-day course to understand them.
- Easy to share: Objectives are simple to communicate between the technical team and customers.
While there are more sophisticated, ultimately superior techniques that can be used to measure work, Kelly finds that the beauty of user stories is in that third point, the ease of sharing. Sophisticated techniques create barriers between people who are familiar and unfamiliar with an approach, whereas a user story is just a story. Kelly thinks of user stories as “tokens” to be traded in for a more detailed discussion in the future for what the work entails. He goes on to write:
Each story should have some business value. The story may earn revenue, reduce costs, attract customers, make employees more effective, or deliver value in some other way. Putting a value on a story may require sales projections or an understanding of time savings. Ideally, I’d like to see a financial amount on each story—a hard dollar number that states the monetary value of the story. Having a financial value on a story makes prioritization easy.
Even if the reason for a user story is merely indisputable corporate mandate, it is still important to document that reason, so that there is a line of logic others can follow. The user story is the skeleton of progress. Flesh it out as required, and nothing more.
You can read the original article here: http://www.agileconnection.com/article/user-story-heuristics-understanding-agile-requirements