Hello. I’m Tom Hathaway. I’m wearing my BA hat, so let’s talk business analysis. In this nugget I’d like to discuss how to write good user stories. We’re going to talk about what the components of a user story are and how to make your user stories more effective. These techniques will help you when you are the one wearing the BA hat.
What Are User Stories?
User stories have rapidly become one of the most popular forms for expressing stakeholder requirements management software on projects whether your project follows an Agile approach or a more traditional methodology. Many feel that the mold, “As a role the author represents. I/we can do or have something with these qualities to achieve my goal or objective” by itself is sufficient to explain how to write user stories.
I believe there are still a few dimensions missing. For instance, examine two implementations of this mold. “As a website visitor, the role, I can view all training, do something, which I need, quality requirement, to qualify for the CBAP exam, goal.” Second example: “As a human being, role, I can differentiate sounds, do something, in my native tongue, quality requirement, to comprehend what others are saying, goal.”
Note that both statements follow the mold, and, by that definition, are user stories. Whereas the first gives the developers great guidance, I question the value of the second. As a result, I have developed a set of guidelines or rules for writing an effective user story that go beyond the mold and might help you.
Keep The Story Simple
The first rule in writing an effective user story is simple: keep the user story simple. A simple sentence states only one thing. However, it does a good job at that. If you try to express too much in a single sentence, you add confusion. For instance, the user story, “As an applicant I can navigate to the coverage screen, enter personal and vehicle data, and submit the application online to request automobile insurance coverage,” contains three distinct thoughts. It would be clearer if you expressed each thought as a single user story, i.e., “As an applicant I can navigate to the coverage screen to select the insurance coverage I need. As an applicant I can enter personal and vehicle data to compare premiums. As an applicant I can submit an application online to request automobile insurance coverage.”
Avoid Compound Sentences
Compound sentences are by definition never simple. That means you should not have ifs, ands, or buts in the user story. Well, you actually have to take that with a grain of salt. The word and is a phenomenally versatile word in the English language, and in my experience in any language. It can be a sign of a compound sentence if the sentence contains two phrases, each of which contains an action, a verb, and a subject or object, nouns.
The other use of the word and is to create a list of items based on common characteristics. For example, let’s look again at our previous example. The original user story, “As an applicant I can navigate to the coverage screen, enter personal and vehicle data, and submit the application online to request automobile insurance coverage,” uses the word and in the phrase, “and submit the application,” to create a compound sentence. The use of and in the user story, “As an applicant I can enter personal and vehicle data to compare premiums,” simply connects common types of data.
Be Careful When Using Delimiting Phrases
I also recommend against using delimiting phrases, starting with words like unless, or except, in the user story. For instance, the user story, “As an underwriter I can override a coverage denial for an applicant to increase our customer base unless the denial was due to bad credit, in which case I can confirm the denial to protect our customer base.” That user story is confusing and would be much clearer if I expressed it as two user stories.
“As an underwriter I can override a coverage denial for an applicant with good credit to increase our customer base. As an underwriter I can confirm the coverage denial for an applicant with bad credit to protect our customer base.” Delimiting phrases commonly create a user story with two different goals. By expressing each goal in a separate user story, the intent and purpose of each becomes much clearer.
To sum up my first rule, an effective user story is a simple sentence that does not contain conjunctions, and, or, but, etc.; or limiting phrases, unless, without, except, etc. Following this rule facilitates user story elaboration, the process whereby developers ensure that they understand the story and can implement it.