Boulders to Gravel: Techniques for Decomposing User Stories
I’d like to open by acknowledging that user stories should be the start of a conversation. At some point that discussion should result in a confirmation of what is to be delivered. Teams and individuals new to agile commonly struggle with breaking large user stories into smaller ones—turning boulders into gravel, to make a cliché analogy.
Too often, teams commit to stories that are simply too large to reliably complete in a Sprint time box; they’re epic user stories. For new agile teams, this is understandable; it’s a new way of working and they’re used to working on larger deliverables. However, agile teams that are established may also frequently struggle with work decomposition.
So, exactly how big should user stories be before they’re pulled into a Sprint? The truthful answer is—I don’t know, it’s situational and relative. My recommendation is that, if you’re going to pull a user story into a Sprint, the team should be able to complete it in one or two days. I suggest this for several reasons:
- Small stories are usually less complex, which helps make them more understandable, leading to a story that’s easier to estimate. More reliable estimates lead to an enhanced collective team confidence in meeting Sprint commitments;
- Small stories usually equate to shorter cycle times, thereby reducing the time it takes to deliver business value to the customer;
- Finally, large user stories hide bottlenecks and impediments.
Below are four techniques that you might not have considered for decomposing user stories that you can use to make gravel out of your own boulders. I learned these from Chris Sims in my Certified ScrumMaster (CSM) class several years ago and I have successfully applied them numerous times; not yet finding a story that can withstand the scrutiny of all four techniques.
In the below examples, I’ve used the widely accepted user story format:
“As a <user persona>, I want <desired functionality> so that <definition of value>.”
I’ll be using a banking system to demonstrate the techniques with easily relatable and practical examples.
Conjunctions and Connecting Words
Examine the user story for connecting words, such as conjunctions that can be used to separate the story. As an example consider this user story:
“As an online banking customer, I want to be able to check my account balance and transfer funds so that I can manage my account properly.”
(1) “As an online banking customer, I want to be able to check my account balance so I can ensure I have enough funds for transactions.”
(2) “As an online banking customer, I want to be able to transfer funds so I can have sufficient funds available in all of my accounts.”
For purposes of this discussion, I’m defining generic words as being those that are vague and/or subjective. Replace these words with one or more words that are specific and descriptive. Consider the following story:
“As an ATM user, I want a user interface that is easy to navigate so I can quickly find what I want to do on the screen.”
What, exactly, does “easy to navigate” mean? It could mean different things to different users.
(1) “As an ATM user, I want an interface that has a home screen containing the three transaction options available so I can perform a transaction.”
(2) “As an ATM user, I want an interface that has a home screen containing an option to cancel a transaction so I can choose to abort if I’ve made a mistake.”
Note also that new story (1) above could be further decomposed into three stories by writing one for each of the three transaction options (deposit, withdraw, transfer).
In addition to conjunctions, connecting words, and generic words you can also examine acceptance criteria to identify potential areas you may be able to split a story. Consider the story outlined below, that encompasses a large part of an online banking system.
“As a banking customer, I want to be able to do my banking online so I can do routine transactions from anywhere.”
Here are example acceptance criteria for this story:
– Members must be able to check balance of each account.
– Members must be able to open a new account.
– Special offers for members are displayed when they open the site.
– Members must be able to transfer funds between accounts.
– Members must be able to communicate with bank staff to have questions answered.
(1) “As an online banking customer, I want to check the balance of my accounts so I can know how much money I have in each account.”
(2) “As an online banking customer, I want to open a new account so I can expand my money management options.”
(3) “As an online banking customer, I want to see offers available to me so I can take advantage of savings I’m eligible for.”
(4) “As an online banking customer, I want to be able to transfer funds between accounts so I can have sufficient funds available in all of my accounts.”
(5) “As an online banking customer, I want the ability to communicate with bank staff so I can have my questions answered.”
By simply examining one user story’s acceptance criteria, five smaller stories have been created that can provide value to members much more quickly than waiting for the entire user story as originally written.
To use timeline analysis, imagine the story has been implemented and delivered. How does the story get used? What is the logical sequence of events that describe its use? Each of these steps may be a valid story that could be implemented independently. Consider this story:
“As an online banking customer, I want to pay bills online so I don’t have to mail a paper check to a creditor.”
At first glance, online bill pay may not seem that large. However, let’s create some user stories based on a process flow that a typical online user performing an online bill pay transaction may need to perform. Doing this exercise may lead to the following sampling of smaller user stories, each comprising a step in the online bill pay functionality. Of course, this is just an example and is certainly not an exhaustive list.
(1) “As an online banking customer, I want to enter creditor information online so I don’t have to re-enter each time I have to pay a creditor.” (Data entry GUI?)
(2) “As an online banking customer, I want to select a creditor I’ve paid in the past so I can pay a bill that is coming due.” (Creditor database?)
(3) “As an online banking customer, I want the ability to schedule automatic bill payment so I can ensure my bills that are due on a specific day each month are never past due.” (Server-side scheduled transaction?)
(4) “As an online banking customer, I want a transaction receipt for a bill that I’ve paid emailed to me so I have proof that I’ve paid.”
Try these techniques at your next backlog grooming session and help your team decompose those large boulders into more achievable gravel-sized stories to help your team achieve focus and improve delivery times.