Build Requirements Around Real Journeys

Build Requirements Around Real Journeys (Experience driven development. Part 2)

In the previous article in the series (Design for Real People) we have explored how an end-to-end experience of getting a problem solved is important for customers and how this experience can be captured in a form of customer journeys.

Let us look at it from a different angle now and derive the requirements out of the customer journeys.

Solution components

It is impossible to introduce a change... if the change is big and you try to implement it in one go.

This is the reason we tend to break any solution into smaller components. Each solution component should be small and independent enough to be changed individually in a controlled manner. So that eventually we will compose a new experience out of them. Pretty much like using a set of Lego blocks.

Allocating requirements to solution components is a very important task. First thing one needs to understand is which solution component supports which part of the customer journey. For each component there is always two parts:

1. Front-of-house: what the customer sees when interacting with a solution component
2. Back-of-house: what are the business capabilities that support it from the inside of the business

Let us take for example a process of receiving a bill. What a customer sees is a printed bill in the mailbox with all the relevant data they need to action it. This is the front of house, and bill recipient will have a long list of requirements for what needs to be on that bill. But for the bill to arrive, the business needs to have a (preferably) automated reconciliation process that calculates the balances, a printing process, a delivery process, etc. All these form the back of house for the same component of the solution.

To finish this task, one will need to identify all the touchpoints on the customer journey (this are moments in time when the customer interacts with the business). For each touchpoint, one needs to list all the business processes that support it, as well as information systems and data sources. This will produce a sliced view of the enterprise architecture through the lens of one particular customer journey.

Writing stories

There are always gaps between the current and desired states. Otherwise we would be living in a paradise and a profession of a business analyst wouldn’t have existed.

A great way to highlight and document those changes is to use user stories. A user story is a very popular format for documenting requirements. It is a common knowledge it consists of three elements. The template looks like this:

As a <persona>

I want <a feature>

So that <value>

This format can be easily utilised for our experience driven situation:

1. In the first statement focus on who benefits from the change. Try to also add context. Avoid using “As a user” all over the place, give the user some personality. For example, “As a user with an outstanding bill” or “As a user who has just paid a bill”. Context matters.
2. In the second statement, describe what the change is about. Specifically, which capability is missing in the as-is state that this story will introduce.
3. In the last statement, describe what is the value that the change will bring, why the missing capability is needed.

It is important the user stories describe the desired state rather than the steps to achieve that state. The actions taken to achieve the desired state are not a part of the solution scope - they form a project scope when the solution to be delivered is already understood. The logical order of steps is: first, define what you want to achieve (user stories), then understand how you will achieve it (actions). A healthy product backlog will mostly consist of the user stories, and not the tasks. This is how the team can properly scope the final product and track the progress in terms of delivered functionality and value, not the effort spent.

Let us have another look at the customer journey from a previous article:

Customer journey map for paying a bill

Here are a few examples of user stories that may describe parts of solution for the situation captured above:

The user story is the main way to connect the customer we are helping (“as a”) to the need (“I want”) and the why behind it (“so that”).

An important side note is that one is most likely to create the user stories at least twice. First, user stories will serve as a basis of validation process. You need a tool to scope the prototyping.

Second, once the solution is defined you need more detailed (“development ready”) user stories to feed the delivery process.

Getting those acceptance criteria right

How do we know if we have successfully delivered a user story in a way that supports the expected experience? Typically, a user story will be accompanied with acceptance criteria for this. Writing acceptance criteria is an art on its own.

Acceptance criteria are used to check if a user story is done. The way I usually put it, they help prove that the story is delivered in full. What is important, acceptance criteria have to be agreed with interested parties before the story is delivered.

A good way to write precise acceptance criteria that are easy to communicate and agree on is to use examples. As a user story may have multiple acceptance criteria, it is not uncommon to have multiple examples for each story.

Let us take this user story from above:

As a customer who paid online

I want to get a paper receipt and statement mailed to me

So that I can store them for my records

It may have an acceptance criterion like this:

After the user pays online, a letter with a printed receipt should be delivered to the user’s address.

This is a good starting point, but it can be noticeably improved.This criterion is declarative and very broad. Such a criterion is not directly actionable or testable, therefore it does not enforce the expected behavior and may even be out of scope of the solution control. With mail delivery, if the company does not own the delivery service they cannot guarantee the printed documents will be received. All they can control is that the envelope is sent to the proper address.

Let us fix this issue:

After the user pays online, a letter with a printed receipt should be sent to the user’s address.

We have changed the word “delivered” with the word “sent”, which returned the criterion into the solution scope. Now, we can start adding examples to this criterion to make it actionable:

Given a user lives at 20 Main road

And has to pay $70

When the user pays online

Then a message is shown that a receipt will be posted

And a receipt is queued for postal delivery to 20 Main road

This is a great addition to the original criterion as it can be easily discussed with the stakeholders. Quite often these conversations are as important as the process to come up with the user stories in the first place, as they uncover lots of missed alternatives in the processes and missed requirements. This is a collaborative process.

First, the BA prepares a list of user stories for the team. Second, each user story is accompanied with acceptance criteria. Third, the team explores the domain outlined in the story and collaborates to produce scenarios. It is important the three perspectives take part in the process:

• Business - people who know the problem domain

• Development - people who will be developing a solution

• Testing - people who will perform quality control on the output

This meeting is often referred to as a Three Amigos meeting. There is an amazing article about it on modernanalyst.com [1]. The main objective is to get people to talk to each other and get aligned before the start of development to uncover tricky cases that may appear on the customer journey and get an agreement on the scope of development for a particular story.

In the example above, one of the researchers may say that people she talked to mentioned they often pay a bit more than the bill amount so that the next bill comes smaller. This can get reflected in the reassurance story as a modified example scenario:

Given a user lives at 20 Main road

And has to pay $70

When the user pays $75 online

Then a message is shown that a receipt will be posted

And that extra $5 will be accounted for in the next bill

And a receipt is queued for postal delivery to 20 Main road

It always helps to relate the acceptance scenarios back to the customer journeys. This will help prioritise the ones that matter to the customer and not to miss important interactions.

What makes development driven by experience?

Summing it all up, what makes the development driven by experience?

1. Understand the expected end-to-end journey
2. Base requirements on research not opinions
3. Prepare acceptance criteria in the form of scenarios that may appear on your customers’ journey

If one doesn't talk to their customers when developing requirements, they are probably designing something no one dreams about. This is a sad situation to be in. Let us try to avoid it.

Let the customers dream. Let the business analysts ensure those dreams come true.

In the next article

By now, we have discussed the process of customer journey mapping and the translation between journey maps and requirements backlog. In the next and final article of this series we will explore how to use the insights about customer behaviour to build better enterprise architecture and assign business KPIs to architecture elements.

References:

1. https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/2495/The-3-Amigos--BA-QA-and-Developer.aspx
   

Author: Igor Arkhipov, Business Analysis Practice Manager