First Rule: Write Good User Stories
If you are just getting started with writing user stories, I highly recommend Mike Cohn's book User Stories Applied: For Agile Software Development
. Perhaps you're coming from a background of writing large use cases. Perhaps you're fresh out of school and not familiar with requirements management.
If you're already familiar with user stories and want to take requirements management to the next level, check out Dean Leffingwell's book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)
INVEST in the content of the user story
While I won't cover the book here in this blog, I will emphasise a few key points that are important to understand when working with RTC. In it you will learn about the INVEST mnemonic, which is an acronym to describe the quality of the user story.| Letter | Meaning | Description |
|---|---|---|
| I | Independent | The user story should be self-contained, in a way that there is no inherent dependency on another user story. |
| N | Negotiable | User stories, up until they are part of an iteration, can always be changed and rewritten. |
| V | Valuable | A user story must deliver value to the end user. |
| E | Estimable | You must always be able to estimate the size of a user story. |
| S | Small | User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. |
| T | Testable | The user story or its related description must provide the necessary information to make test development possible. |
Here is an example of what a simple user story would look like. A story has 3 C's: the card, the conversation, and the criteria. At the top of the index cards is the name of the story. On the front of the card is the conversation with the stakeholders, elaborating on this need.
Taking this approach, here is what this user story would look like in the RTC story:
Acceptance criteria
This is likely the most neglected step in writing a user story. The back of the index card is where we should be putting acceptance criteria. This has the format of the card shown here to our right. This establishes conditions for when a person interacts and performs a series of operations, what should be expected out of the system.We can take the acceptance criteria content and put it on the RTC user story like this:
Acceptance criteria makes it much easier to create test cases. Whether you manage your test cases in spreadsheets, in HP ALM, or (our preference) Rational Quality Manager, having the analyst and stakeholders document what their criteria for acceptance is, makes writing the test case much more efficient. While it is easy to write test cases that test conditions that the stakeholders may never think of, if you don't test for the conditions they require, you'll never deliver a product that satisfies the target audience.
Additional References for User Stories
These links below are to help you with the content of your use cases. Again, the 'bible' of user story authoring is Mike Cohn's book listed above. All the information below follow from its cannon.
No comments:
Post a Comment