Better user stories

Research shows people retain information learned from storytelling better than other types of communication.

Long before writing came along, people communicated through stories. Ancient traditions, legends, myths, proverbs were – and still are – transmitted amongst people as stories. The works of Homer from pre-classical Greece survived for centuries, passed down the generations as spoken word narratives. This long history of communication using story telling means it is likely that humans are hard-wired to remember stories more readily than other forms of communication.

There are also good psychological reasons why stories are powerful. Stories engage emotions, encourage empathy, and connect us to each other. Stories go beyond specific content and allow us to share meaning, intention, and purpose. Most important of all, stories encapsulate the way humans think; they capture mental maps, metaphors, frameworks, and values.

In the past few decades storytelling has improved outcomes in fields as diverse as health outcomes and nursing effectiveness, corporate change management, energy and climate research, data analysis, nursing research, and academic research. The “story format” is also slowly conquering the world of social media: in the last few years Snapchat, Facebook, Instagram, WhatsApp, and Youtube have all released some type of “story format”.

If humans are so well-equipped to process stories and we know storytelling works in such disparate domains, why wouldn’t it also work in software development?

Well, it does.

User stories have become a standard way to capture requirements in agile environments. It is best to think of a user story as a reference or pointer to the actual requirements. A user story is a brief statement, usually following a format like this:

As a <user type> I want <goal> so that <outcome>

The brevity means you can repeat a user story quickly and clearly and write it on a sticky note. The format also forces the author to consider the user type, the goal, and the outcome.

Let’s break this apart a bit further.

●        User type: The “actor”. This is who does it. The user in mind might be a physical human user, or it may be another part of the system, or another system entirely. A product owner and the team should have a shared understanding of possible user types for the product.

●        Goal: The goal (or intention). This is what the system does, or in other words the desired behaviour.

●        Outcome: The outcome. This is why the system does it, or in other words the consequence(s) of the desired behaviour.

Of course, each user story is a product backlog item. Prior to refinement and prioritisation, user stories might exist as just one sentence. Importantly, as the product backlog is refined, more information can be added to user stories to clarify what is needed in increasing detail. It is useful to elaborate individual requirements that make up the user story in plain language.

In the author’s experience the following sections can add value to a fully elaborated user story:

●        Business background

●        Functional requirements

●        Security requirements (authentication, authorisation)

●        UX suggestions

●        Business rules

●        Configuration impacts

●        Reference to system-wide non-functional requirements

●        Special non-functional requirements that apply to this user story

●        Acceptance criteria (see separate blog post)

 Each of these is explained in a little more detail below.

 User Story

As a                      {user type}

I want                   {behaviour}

So that                 {outcome}

Business Background

{Briefly explain the business reason for the user story, how it fits with the product vision, and how it adds value to the product}

Functional Requirements

{List the functional requirements that make up the user story}

Security Requirements (Authentication, Authorisation)

{Explain any security restrictions – eg. which user types have access to the user story}

UX Suggestions

{Ideally this refers to pre-existing style guides for UX components; list any exceptions or requirements specific to this user story}

Business Rules

{List any business rules in plain language}

Configuration Impacts

{If the user story introduces new configuration or modifies existing configuration, list the impacts here}

Reference to System-Wide Non-Functional Requirements

{Refer to generic non-functional requirements (NFRs) for the product, as a reminder to the team; non-functional requirements are sometimes referred to as system “-ilities”, NFRs are things like reliability, testability, portability, usability, maintainability, performance, and so on}

 Special Non-Functional Requirements

{Explain additional non-functional requirements, or exceptions to the system-wide non-functional requirements for the product; a non-functional requirement is a property of the system (eg. a performance metric)}

Acceptance Criteria

{A list of items that must pass or be true for the user story to be “accepted” as working}

So, some practical tips…

The sections shown above are one way to fully elaborate a user story. You might include more or less sections, depending on things like the nature of your product and the level of your developer’s functional knowledge.

Here are some practical tips on writing more effective user stories.

●        Make story telling a two-way conversation.

Developers (and product owners) often see user stories as one-way communication, flowing from the product owner to the developer. This is an antipattern. Remember, one of the primary purposes of the story paradigm for requirements is to improve shared understanding. So, when writing user stories, always keep in mind the objective is to encourage two-way conversations and the exchange of ideas.

 ●        State user stories in plain language.

Don’t waffle. The most effective user stories use clear and concise language. If a user story contains domain-specific jargon, be sure to carefully define terms. Better still, refer to a domain glossary. In the terminology of Domain Driven Design (DDD), such a glossary forms part of “the ubiquitous language of the domain”.

 ●        Use specific examples to communicate generalities.

We know that people respond better to storytelling over blueprinting. To take advantage of this, “specify by example”. Describing a screen where users can place orders for a product in words will never be as effective as drawing an example of such a screen. It might even trigger a gathering around a whiteboard, to illustrate what you mean with more examples (reinforcing point 1: make story telling a two-way conversation).

 ●        Make user stories atomic.

We know that a user story should be a minimal increment of functionality. If not, break them apart into multiple stories. For example, a user story might initially be “As a salesperson, I want to manage orders, so that I can fulfil customer demand”. This user story is very broad. Better is to break it into several user stories, such as “As a salesperson, I want to create new orders, so that I can fulfil a customer demand for a product” or “As a salesperson, I want to amend existing orders, so that I can fulfil a customer’s desire to change their mind”, and so on.