User Stories – Answers On A Postcard
This content is syndicated from by Kelly Waters. To view the original post in full, click here.
If you're capturing user requirements using User Stories, write them on a postcard... (a blank one of course!).
A User Story Card should ideally comprise 3 parts: Card, Conversation and Confirmation...
The heading section of the card should include the name/description of the user story, any reference numbers, estimated size, etc.
Most of the front of the card should include further information about the user story and what the software is meant to do. This can be a sketch or diagram of the feature, or notes about how it should function. Anything that helps to concisely explain the feature. Remember this is a reminder of the story and notes about it, not a full specification on a card. The team should collaborate to get more details at the time of development.
Write test cases on the back of the card. Writing tests up-front helps to ensure the software is designed to pass. Writing tests up-front also helps to identify scenarios that users, developers and/or analysts may not have thought of.
Keeping User Stories small enough to fit on a card helps to ensure that requirements are broken into small, manageable pieces of functionality, i.e. individual features.
Cards also work nicely in conjunction with whiteboards, providing clear visibility of progress and enabling team collaboration, moving cards around the board as things progress.