Slicing by Workflow Steps
Most anything that we would add to a solution and describe in a User Story is a process that has some sort of workflow. In most cases these workflows can be broken down into individual steps. A large User Story with several workflow steps can be broken down into smaller users stories based on these workflow steps.
Consider the following User Story for an ecommerce website.
As registered customer I want to purchase the items in my shopping cart so that my products can be delivered to an address I specify.
If we assume a fairly standard shopping cart and order entry process, we could identify the following steps:
As a registered customer I want to log in with my account so I don’t have to re-enter my personal information every time;
As a registered customer I want to review and confirm my order, so I can correct mistakes on my order before I pay;
As a registered customer I want to pay for my order with a credit card, so that I can confirm my order;
As a registered customer I want to pay for my order with a wire transfer, so that I can confirm my order;
As a registered customer I want to receive a confirmation e-mail with my order, so I have proof of my purchase;
As you see, there was more to this seemingly simple User Story than was originally apparent. By breaking the User Story down into its individual workflow steps and considering the different options that a user may use to pay we make the customers intentions much clearer to the developer implementing the functionality.
We must keep in mind the reason for creating User Stories in the first place; to engage the customer in conversation about desired functionality and clarify expectations before passing requirements on to the delivery team. The more granular our User Stories, the more specific our discussion of desired functionality and Acceptance Criteria can be.
Knowing the details of the workflow the team can prioritize the functionality based on business value. For example perhaps in the first release we only allow customers to pay with a credit card and we send the order confirmation manually or perhaps customers are required to enter their address information manually until saving addresses is available in release 2.
In any event having more granular user stories allows the delivery team to have detailed discussions about the desired functionality without missing key workflow steps or Acceptance Criteria.
Slice dice and discuss!
Previous Method 1 – Slice by Happy vs Unhappy Flow ****** Next Method 3 – Slice by Test Scenarios
1 thought on “Slicing User Stories Method 2”
Pingback: Slicing User Stories 7 Methods – ProDataMan Blog