Creating Stories in the System Landscape
How does a business analyst or architect write a user story for a process step initiated by a system? For example, a prospective customer completes a form to download a white paper. Management wants the white paper request to create a lead record with a related task to follow up with the prospect. Who is the “user” in this case? The prospect doesn’t want the lead and task records, a manager does. The user story format needs to expand to accommodate an actor besides the user performing the step.
Management wants notification if no one has followed up on the lead in seven days. Now we have a case where the story executes conditionally. The story format needs to extend another way to express the condition.
Artifacts and the System Landscape introduces the system landscape diagram shown below. It includes external services such as payments and document generation. A user can take an action that causes an external service to perform another action. What’s the story for that?
Mapping the System Landscape
Here is the system landscape diagram from Artifacts and the System Landscape:
Let’s say some business stakeholders ask a business analyst and architect how the payment process works. They could start with a concept map, showing who and what gets involved in the process:
The concept map shows that a customer submits a payment transaction to Order Management connected to a Mulesoft enterprise service bus (ESB) which forwards the transaction to a payment gateway. It shows some technical details of the payment process, but the business stakeholders want to know how the process works from a user perspective.
What’s the Customer Payment Story?
The business analyst starts with a user story:
As a customer, I want to submit payment for my order, so that I can receive what I ordered.
The business stakeholders acknowledge that the story works fine if the payment transaction goes through OK, but what if it fails? The stakeholders collaborate on what could go wrong in the payment process, creating a list of exceptions:
The customer submits incorrect credit card information.
The payment processor declines the credit card.
The payment gateway or processor is unavailable.
The business stakeholders make it clear that the payment process should have as little friction with the customer as possible. If the customer submits incorrect credit card information, they should see which fields with incorrect information to fix.
The Path to Minimal Customer Friction
The business analyst draws a process diagram showing the high-level customer payment steps:
The “Submit Payment” step should validate the credit card number and expiration date before sending them to the payment gateway. The business analyst shows the validation process with another diagram by drilling down the “Submit Payment” step:
The top row steps show the process when all credit card fields validate without errors. If a field fails validation, the red-colored step below adds it to an invalid field list. Step 3 on the top row counts the number of fields in the list. If the list has no invalid fields, the “Submit Payment” process continues with validated payment data. If the list contains any invalid fields, step 6 highlights the field(s) and returns to the start of the “Submit Payment” process for the customer to fix the highlighted fields.
The business stakeholders agree that the credit card field validation looks good. The business analyst summarizes the diagram with a user story in an extended format to include a condition:
As a customer, when I enter incorrect payment information, I want to see which fields are incorrect, so that I can enter the correct information.
This conditional story only applies when the customer has entered incorrect payment information.
The Rest of the Stories
The validation above only checks the format of the credit card number and expiration date. When Order Management sends that information to the payment processor, it could respond with an invalid account number, or the payment amount would exceed the credit limit. The business analyst writes another conditional user story:
As a customer, when my payment does not authorize, I want to provide another payment method, so that I can pay for my order.
In rare cases, the payment gateway or processor is unavailable for transactions. The business stakeholders want the payment process to retry the transaction for a configurable number of iterations and time between each retry. If the payment succeeds in any case, the customer will get a receipt via email. If the payment does not go through, notify customer service to call the customer about his or her order.
In these cases, an extended story specifies that order management act on behalf of the customer:
As a customer, when my payment won’t go through, I want order management to retry the transaction so that I can pay for my order.
The customer service manager wants his group to intervene when order management cannot process a payment for technical reasons:
As a customer service manager, I want order management to create a notification task when a customer payment fails to process, so that a service representative can call the customer and arrange payment.
This extended story format also applies to the happy path:
As a customer, when my payment transaction completes, I want order management to send me a receipt, so that I have a record of the payment.
Flexing Stories Two Ways
A business analyst or architect can extend user stories to specify what should happen when a process veers off the happy path. Stuart Gascoyne introduced a couple of story extensions in his session, “Using Process Maps to Write Effective User Stories,” at the Spring 2021 Salesforce Business Analyst Summit:
As a <role>, when <something happens>, I want <capability> so that <receive benefit>.
This is a conditional story, only applicable when <something happens>. It deals with cases when a process flow takes an alternate path, such as an exception as shown above.
Stuart introduced another story extension, where a system or someone else can act on behalf of a process owner:
As a <process owner>, I want an <external role> to <capability>, so that <receive benefit>
In this case, the <external role> executes the <capability> on behalf of the <process owner>, the user running the process. In the previous section, the last three stories had order management take action on behalf of a process owner.
The conditional and external role extensions combine into a more general story format:
As a <process owner>, when <something happens>, I want an <external role> to <capability>, so that <receive benefit>
For example:
As a marketing director, when someone leaves contact information on our website, I want Marketing Cloud to create a lead, so that my team can qualify it.
The common user story format:
As a <role> I want <capability> so that <receive benefit>
works well on a straight happy path where the user performs the <capability>. Processes often include decisions that deviate from the happy path. Conditional stories cover those deviations, giving developers a clearer picture of the process.
Processes can also have a system perform a function rather than a user. Stories with external roles cover those cases, further clarifying stories for developers.
Adding external roles to stories makes them fit with services in a system landscape. Adding conditions increases the stories’ coverage of different paths a process can take.