Writing User Stories within IBM Rational Team Concert
First Rule: Write Good User Stories
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. |
RTC itself is merely a tool. The content of the tool is only as good as what the analyst puts into the tool. Garbage in – garbage out. If you learn anything from this blog, learn the INVEST mnemonic and stick to it.
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.
As you can see from above, the the entire content of the front of the card is placed in the Description field. We’ve put the “what” of the card in the Summary line for brevity (this makes it easier to find in work item queries). But what about the back of the index card (i.e. the criteria)?
Acceptance criteria
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
Other useful resources:
