A deep dive into User Stories

Most of us working in IT have some idea of what a User Story is. We know it is an easy, proven way to conceptualise business requirements for an app or IT solution.

Google’s Search Labs provides us with a simple definition that would be a great starting point. It describes a user story as “a short, informal description of a software feature or product or service from the perspective of the end user or customer. It's used to explain how a feature will provide value to the customer and to inform design decisions.”

The purpose of this essay is to reflect deeper on how to write great user stories that are self-contained and self-explanatory. The idea is to produce user stories that leave little doubt in their consumer’s minds about the details of the business and software requirements, and thereby facilitate an accurate technical design of the described feature, at first pass.

To make this meditation intuitive and easy to follow, let us consider a hypothetical yet plausible business requirement. A requirement that depicts a reasonably complex feature addition to an existing system, which justifies careful thought when drafting its user stories.

Let us say there already exists a system, which connects veterinary clinics with pet owners, allowing pet owners to place appointments and obtain prompt and quality medical services for their pets.

Let us assume that it is a recurring complaint among pet owners, that some ailments are either (A) referred to other veterinary clinics after the initial consultation due to lack of expertise, or that in some rare cases (B) treated ineffectively at the initially consulted clinic for the same reason.

Let us further assume that stakeholders have brainstormed and decided that the best solution would be to profile clinicians for expertise, and to try and matchmake the closest clinic that has the required expertise for the concern described in the appointment.

The idea would be that a pet owner would provide a brief natural language description of what ails their pet (if anything) when making an appointment. An AI would parse this description, identifying words or phrases that suggest certain predefined conditions, and suggest nearby clinics that have clinicians with the required expertise. Let us say that up to three clinics would be suggested, and the pet owner would be given the choice to visit one of them or bypass these suggestions and visit a clinic of their own liking.

So, here’s our suggested method for drafting a backlog of user stories to describe this “new” feature to the existing appointment solution.

Step 1: Model the Domain

The first step is to construct a domain model of the business requirement, to accurately understand the way things happen, or ought to happen, in the real world. It is an excellent way to educate oneself about the actors and processes, and the relationships between them. Here is an example domain model for the said enhancement to a veterinary appointment system.

Figure 1: Example Domain Model

Step 2: Identify the Personas involved and what they do

The second step is to identify the personas in the domain that would be affected by this business requirement, and what actions each of them expect to perform at a high level. The above domain model comes in handy with this step.

1. System Admin

Define widely recognised conditions in different pet types for which prior experience and positive results (i.e. proven expertise) is relevant for effective treatment, such as fractures or hemangiomas or knuckling in cats. 

2. Clinician

Maintain one’s expertise profile.

3. Clinic Admin

Maintain the list of serving clinicians and their calendars and validate expertise profiles.

4. Pet Owner

Provide a natural language description of one’s pet’s concern or concerns, to be addressed during the veterinary appointment, and then be able to choose a nearby clinic that has the necessary expertise to address the concern.

Step 3: Write the “story” parts of the user stories

In most feature requirements like the one above, there is a “main” user story that describes the cash value of the solution. Its best to begin by writing this story first. In this case, it is the story of the pet owner choosing a best suited clinic at the time of making the appointment, for addressing the concerns their pet has. 

If there isn’t such a “main” user story, that’s fine. We then can just pick on any persona’s expectation and go ahead and begin writing stories.

So, let’s begin our example story.

User Story 1: Matchmaking clinics to address pet concerns

As a Pet Owner,

I want to provide a brief description of my pet’s concern(s) at the time of making the appointment, and get an idea of the most suitable and convenient veterinary clinic(s) and their free time slots for addressing these concerns,

So that 

A) my appointment won’t be a waste time and money, where I’m referred to another clinic or time slot after an initial consultation, or worse have my pet maltreated at the clinic due to the lack of necessary expertise, and

B) my clinician could be well prepared for addressing specific concerns during the appointment.

That’s the raw story. There are a few points to note about this example story.

• The I want to part – the expectation – is covered concisely but accurately, so that the essence of the requirement is conveyed to the reader without gaps. So, for example, it describes the time at which the expectation is salient (at the time of making the appointment), the fact that the Pet Owner is looking for two types of advantages in a clinic (suitable - meaning having the right expertise, and convenient - meaning being not too distant in location). And so on.
  

• The So that part – the business reason behind having this expectation – is written quite exhaustively. This is the only place in a story where the reader is provided with a clear understanding of the backstory, the real-world motivations behind this new requirement becoming salient. It can prevent teams from making seemingly minor tradeoffs between design and requirements, that would ultimately undermine the success of the entire feature.
  

• The story is written using domain and business language, and not using system language (i.e. user experience language such as button taps, input fields and popups). There are several reasons for making this abstraction, such as educating the engineering team of the business processes and not having them lose themselves in the details immediately, and keeping the business requirement invariant of the user experience design.

The latter point allows us to follow a handy three-step approach to completing a business requirement as a user story ticket in an Agile backlog.

1. Writing the story.

2. Drafting and appending its relevant user experience.

3. Defining the acceptance criteria for the story.

It is when writing the acceptance criteria that we must reference details of the user experience, to describe exactly how things must happen on-screen.

We’ll come back to user experience and acceptance criteria in a moment. Once we have finished our first story, we can continue to draft the rest of the stories. So, in the case of this example business scenario, another story could be:

User Story 2: Defining clinician expertise

As a System Admin,

I want to define areas of frequently required expertise for addressing specific medical conditions such as fractures, knuckling, snake bite and so on, which are not common amongst all clinicians,

So that clinicians can update their profiles with the expertise they have and leverage them during appointments.

And so on, until we have the full backlog of user expectations as user stories.

Step 4: Draft the User Experience

It not being the objective of this essay to dig deep into UI/UX design, we will not share a complete example UX for our hypothetical requirement here.

We will however share a wireframe of just one key step in the appointment making flow – the providing of a description by the pet owner about what concerns them – to serve as an example of what a rudimentary user experience suitable for elaborating a user story might look like.

Figure 2 – Example Wireframe

There are a few important methodological points around UX design that are worth considering here.

• The Domain Model and the Story Backlog must be provided as a necessary input to UX design.
  

• Net new business process knowledge arises out of the UX design process, and a Business Analyst must collaborate closely with a UI/UX Specialist to churn out options for the UX. So, for example, where would we slot in the different steps of the appointment making process, such as the concern description, time selection, clinic selection and so on? It may be that, for example, it serves pet owners better to provide a free time slot first, before matchmaking a suitable clinic, as the most important parameter is the free time slot of the pet owner. I.e. net new domain knowledge is gained.

• It is important to present A/B testing options to sample end users and get feedback on these options for the UX design, prior to deciding the right experience. Crucial business processes and usability inputs might be missed if we don’t “test” user experiences at this early stage of software development.

Step 5: Update the Acceptance Criteria

Now we’ve come to the final step in detailing user stories, where we’ve updated the story ticket with the user experience flow and are writing the acceptance criteria. Here is an example criterion.

Acceptance Criterion 10: Clinics > Generating Clinic Choices

Given a Pet Owner stepped into the Concern screen in the appointment flow, has provided a concern description and uploaded at least one photo,

When they tap on the Next button,

Then they are shown a list of clinic choices that match the concern, in the next “Clinics” step described in UX Figure 5. The choices list will be generated according to the algorithm described in research subtask 1 [linked to a technical task describing exactly how the list of up to three matching clinic choices are generated, leveraging rules and an AI framework].

And so on.

This style of “business level” user story writing can sometimes result in “bulky” stories, in that the UX description and acceptance criteria for the story might be lengthy, describing many different micro-features and operations. There is however an easy way to subtask this type of story and make sprint planning easy; simply map each acceptance criterion to a subtask.

It may take a tad more time at sprint planning to carefully create and self-assign ten or twelve subtasks as one’s goal for the sprint, but the holistic view of things makes understanding of the features and how they work together well worth it.