Better User Stories

While I will not claim to be an expert at writing user stories, I am experienced. It is not always enough to simply follow the pattern. Like any analysis pattern, there are some things that one can do to improve their stories. Over the last couple years I have learned the following:

1) User stories for a new software product are different than stories for subsequent releases.

 When you start writing stories for a new product, you may not know who all the actors are. You may not know what all of the relevant metaphors or entities in the business domain are. You haven’t defined any software capabilities or features yet – so your stories tend to be a little more abstract – a little more open. If you already have a domain model from an earlier analysis or a prior system, it can help to reflect on the nouns in your stories and see if they correspond to known domain entities. It is important to drive consistency in your words, across all stories in the backlog, so that you don’t confuse either your subject matter experts or your development team. When you already have a software product, sometimes the user experience abstractions become nouns in their own right. You have defined innovative capabilities that make possible business practice that was not practical without your software. Often stories in later releases reference capabilities delivered in earlier releases, as an enhancement, expansion, or alteration of the original capability.

2) The words we use in user stories are important.

Regardless of what form we use to capture requirements, words are important. The semantics of abstractions we describe are important. The who is doing, the act that they are doing, and what is being acted upon are all important parts of the story. Even the descriptive words adjectives and adverbs and prepositional phrases describe aspects of the abstraction that are important. Ambiguity in our language leads to confusion and chaos when building software. Having definitions for the actors, the business entities, and the actions that are maintained and clarified over time is important. Pay attention to adverbs, adjectives and prepositional phrases as they are often signals to requirements that we haven’t clearly spelled out. They “beg the question” – quantification (how fast, how much, how often, how good, how big, how easy), or they point at general standards that need to be defined within the user experience.

3) Even though user stories are “independent” from an implementation perspective, they are not from a language perspective.

By defining a glossary of terms representing abstractions in the business domain, we can begin to form a language that is shared between the business users and the developers forming the software product around those abstractions. Maintaining that glossary and ensuring that stories that use terms from the glossary are using them consistently is a key to maintaining the simplicity of the software. Sometimes system capabilities and features

Here are some positive ideas that you can apply to improve your user stories:

  •  Pay close attention to the nouns in your user stories. Nouns are either actors, metaphors, or features. Make sure they are consistent, and maintain a list with definitions, so that you can explain these to your developers. Effectively, these become the metaphors or entities in your domain model.
  •  Pay attention to the verbs in your user stories. Verbs are actions that are either done by the actors or by the system on behalf of an actor. Make sure that all your verbs have a clear actor and a clear object. This is one way to flush out the hidden actors and metaphors in your domain. For each action, ask “who does this?”
  •  Pay attention to adverbs and adjectives in user stories. In my experience, adverbs and adjectives are nothing more than unwritten acceptance criteria. They describe other nouns and verbs in your stories and they simply beg to be elaborated. Ask yourself, how you could “quantify” that adjective or adverb. Or how you could define it. Sometimes it is performance, other times it is user experience.
  •  Reflect across your stories, to ensure that the language is consistent. Make sure your nouns mean the same thing in all the stories. Make sure your verbs mean the same thing in all your stories. Make sure where you have adjectives and adverbs, that you quantify them or define them consistently. Adjectives and adverbs that are used frequently, may become first class stories of their own, describing performance requirements, or user experience standards.

No Comments

Leave a Reply