The Process Map and User Story Tango
Stories from a Salesforce Veteran
The Spring 2021 Salesforce Business Analyst Summit featured a session, “Using Process Maps to Write Effective User Stories,” by Stuart Gascoyne, Salesforce Success Consultant and owner of CloudTeam in the UK. Since 2005, Stuart has accrued a lot of experience fulfilling business needs through implementing successful Salesforce solutions.
Stuart introduced a story template:
As a <role> I want <capability>, so that <receive benefit>
This generalizes the user story template, “As a {person in a role}, I need to {perform a task} so that I can {fulfill a purpose}.”
Stuart’s general story template makes it applicable to higher levels of a business initiative. He started with a top-level story:
As a business leader, I want to execute a CRM process with potential customers so that they become committed customers.
He showed how one story’s <receive benefit> can be another story’s <capability>:
As a business leader, I want to execute a CRM process with potential customers
so that they become committed customers
so that the company can grow
so that shareholder value will increase.
These benefits express the purpose of the CRM process - growing the company’s customer base, revenues and value.
This simple diagram illustrates the process of achieving the business goals:
There’s More to the Story Template
Stuart extends the general story template for cases where the person in the <Role> does not perform the <Capability>:
As a <process owner>, I want an <external role> to <capability>, so that <receive benefit>
For example, the business leader wanting to execute a CRM process in the story above will not do it herself. She will delegate it to department heads as shown in these stories:
As head of marketing, I want to attract unaware prospects so that they become leads.
As head of sales, I want to convert qualified leads so that they become customers.
As head of customer service, I want to support customers so that they become committed customers.
These are not user stories. Rather, they are brief stories breaking down the business leader’s “Execute a CRM process.” The diagram below illustrates these stories, including who does what at the bottom of each box:
The arrows connect the stories, showing how they flow as a process.
The stories and diagram also expose a common gap between marketing producing leads, and sales converting qualified leads. How do leads become qualified? The heads of sales and marketing can work that out, thanks to the stories and diagram revealing the gap.
Story and Process Diagram Tango Steps
Stuart proposed putting stories in a process diagram, with each story in an activity box. The activity box template shown below includes a role (WHO is responsible), capability (WHAT happens), and a benefit (WHY does this happen?). It asks an additional question, WHEN does this (story) happen?
Stuart changed his original story template to include the “when” question:
As a WHO, WHEN something happens, I want WHAT to happen, so that WHY.
For example, the department heads in the stories above delegate the CRM activities to their staff. The stories below describe these activities, including when they happen:
As a marketing manager, when I run a campaign, I want to attract an unaware prospect, so he or she becomes a qualified lead for sales.
As a sales representative, when I get a qualified lead, I want to convert the lead into a customer, so that the company will increase revenue.
As a service representative, when a customer calls for support, I’ll do everything authorized to make the customer happy, so that the customer remains loyal to the company.
The process diagram below shows who does what, when, and why. It connects the marketing story’s “why” with the sales story’s “when” - a new qualified lead. Showing stories connected with their “whys” and “whens” clarifies the process flow for stakeholders and can identify gaps.
HOW to Make Sense of it All
The activity box template includes an important question:
HOW: drill down for more detail
Each story above summarizes a process to execute the story. For example, the business leader’s “Execute CRM process” breaks down into three stories where marketing, sales, and service coordinate to win more customers and keep them committed to the company.
A story can link to another process diagram showing how the story works. This process diagram shows the steps for a sales representative converting a qualified lead to a customer (step 2 in the diagram above):
Each step of the process is a story that can break down into another process diagram for more detail. For example, here is the process diagram for “Submit proposal” (step 5):
A hierarchy of process diagrams like this forms a process map. It enables a business analyst or architect to show story details by drilling down from one process diagram to another, progressively showing more detail at each drill-down level.
Stakeholders review the process map one diagram at a time, drilling down as need to learn more about how a story works. Limiting a process diagram to ten or fewer stories makes it easier to review.
Find a Story With a Process Map
A process map enables stakeholders to quickly find one story out of hundreds by navigating the hierarchy of process diagrams. For example, a stakeholder wants to find the “Draft proposal” story on the process map with the diagrams above. Starting at the top level, they would follow these stories:
Business leader executes a CRM process
Head of sales converts qualified leads
Sales representative converts a qualified lead into a customer
Sales representative submits a proposal
Sales representative drafts a proposal
The map could have hundreds of marketing, sales, and service stories on ten levels, yet it takes only five steps from the highest level story to get to “Draft proposal.”
Stuart touched on a couple of other ways to organize stories, such as themes with epics containing stories and user story mapping. Neither approach considers how the benefit of one story (the “why”) motivates the next story, as shown in a process diagram. A business analyst or architect creating a process diagram thinks through the connection between stories, correcting “why/when” mismatches and filling story gaps. This gives stakeholders a clear and accurate picture of each process.
When a business analyst or architect creates a process map, he or she decides which stories need more detail and creates process diagrams for them. He or she can continue creating process diagrams until all of the details have been captured in user stories. Stakeholders can easily review the map, one process diagram at a time. They can quickly find a specific story through the hierarchy of diagrams. Stakeholders become more engaged in developing a process model, resulting in a solution that better meets their needs.
Showing a process as a series of stories in a process diagram gives stakeholders a clear view of the process flow. Organizing diagrams into a process map makes it easy to find one story out of hundreds.
You can watch Stuart’s presentation and many more related to business analysis with an All Access Pass to the Spring 2021 Salesforce Business Analyst Summit.