The goal of story writing is to describe and create increments of user value that can be implemented by a development team in a short amount of time, typically on the order of hours or, at most, a few days.
Many small stories add up to a releasable feature. This allows the product owner and the team to get quick feedback on the larger feature being built, with the expectation that this will steer the ultimate direction of the feature, and maximize user value.
Two obvious, yet completely incorrect, ways to break down a large feature is by functional decomposition and architectural components. Doing either means you are no longer delivering user value with the completion of each work unit. Rather, you are creating parts of a larger system that cannot provide value until these are combined with other function points, or components.
There are many good techniques to break down features into small stories, some of which are summarized below. But these techniques often fail to get the stories small enough, even when used together. I find a technique I call hyper-fine story splitting, to be useful for continuing the breakdown process, once the other techniques have been exhausted.
Story granularity: Bundle to build value
At every level of granularity, the question you have to keep asking is “Does this deliver value to the user?” Breaking up features into smaller bits is an iterative process—much like turning boulders into gravel. You aren’t going to get the desired end result with one swing of the pickaxe.
Delivering value doesn’t mean that a story has to be so valuable that it can be released by itself. This is an important distinction that can stymie even experienced story writers. As stories get smaller, many of them may need to be bundled together before there is enough value to release. That’s okay.
The INVEST concept
Before I get into the specifics of story splitting, let’s quickly review what makes a high quality story. One set of quality criteria is embodied in the INVEST acronym, created by Bill Wake in his article INVEST in Good Stories, and SMART Tasks.
Here is my interpretation of INVEST:
- Independent – Each story is a potentially releasable unit of work.
- Negotiable – The product owner is open to negotiating the scope and contents of the story with the development team. This allows good ideas from all team members to surface .
- Valuable – Each story provides user value on its own.
- Estimable – Each story is concrete enough that the delivery team can give an approximate estimate, either relative or absolute, as to how big the story is.
- Small – The story can be completed in a short amount of time, so that the team can receive quick feedback.
- Testable – The story can be tested. In the agile world, tested means that a set of automated tests, including unit, integration and acceptance tests are delivered with the production code.
As you continue to split your stories into smaller and smaller stories, you need to ensure that each one still meets the above criteria.
Story splitting techniques
There are many techniques for splitting stories. Here are some of the more useful ones.
Split by capabilities offered
This is the most obvious way to split a large feature. Look at the different capabilities being offered and split each into its own story. For example, the capabilities “sort and search” may each be their own story. Splitting further, each way of sorting or searching may be its own story.
Split by user roles
Administrators interact with a system differently from normal users. Teachers interact with instructional software differently than do students. By defining the different roles in your system, you can split features and stories to address the unique needs of each role.
Split by user personas
Even in the same role, different people interact with software in different ways. A power user wants lots of keyboard shortcuts. A casual user may want a lot of intuitive, hold-your-hand forms of help. Handicapped users may need very different ways of interacting with the system, even though they are doing the same tasks as other users.
Split by target device
In today’s IoT environment, you can’t assume that users are interacting with your system using a standard computer. More and more, apps must work in the mobile world. Splitting stories by device provides a more natural experience for your users.
Hyper-fine story splitting
Once you use these techniques, and others, to identify high quality stories and split them as much as possible, you may find yourself with stories that are still too big. In this situation, I find it helpful for the team to use a “zero/one/many” rule to trigger the creative process, and continue to break down stories into vertical slices.
With the zero/one/many approach, you ask these three questions:
- What happens if we are dealing with nothing?
- What happens if we are dealing with one thing?
- What happens if we are dealing with many things?
A zero/one/many example
The zero/one/many approach allows for hyper-fine story splitting, as illustrated in the following example.
Assume you are building an online digital library system. You’ve looked at your user roles. You have borrowers, librarians, and administrators. In order to narrow down functionality, you have decided that your highest business value lies in serving our borrowers.
But serving all borrowers is still too big. You know from your library expertise that borrowers generally break down into children, teenagers, adults, and people with physical impairments, such as blindness or deafness. Since you anticipate that the majority of your borrowers will be teenagers, you focus on them first.
Eventually, you want your borrowers to be able to borrow many different kinds of media, such as eBooks, movies, graphic novels, and music. As product owner, you decide to start with music. A daring choice, to be sure, for a library to offer music before books, but it suits your target users. Plus, you know that this is just for the first set of stories. You can always hold your first release until you also support other media and functionality.
The first story
You know that your first story is going to be about lending digital music to teenagers, so you attempt to write your first story:
As a teen-ager, I want to borrow digital music so that I can enjoy music that would otherwise be unavailable to me.
That sounds great! So let’s put some acceptance criteria to it.
Given the digital library is online
When I browse for a song
And I choose to play that song
Then the song plays
Grinning, you proudly show your work to your software developers. Their response?
“Whoa! Hold the phone. This is huge, at least a couple of months of work. Probably more. There’s so much to do here. We have to create the digital library server and get it into production, which we’ve never done before. We need to be able to register and authenticate users. We must create a mechanism to select a song, presumably by having a catalog, with various ways to browse and search.
We have to load the catalog of songs into the system, so we have to figure out how we are going to store and retrieve all that data. And we have to figure out how to stream the chosen song to the user. Oh, and unless you want users to steal our entire catalog, we are going to have to find a way to stream and play securely.”
That is a lot, you think to yourself. For some of these things it's obvious how to break them into their own stories, such as implementing appropriate digital rights protection. But even focusing on the core functionality of being able to check out and play a song, you realize that there’s too much there for a single story.
Zero/one/many to the rescue
So let’s apply the zero/one/many rule. The first step is to think about how to apply it. In this case, it’s pretty easy to recognize that you can apply it to the songs. In other words, how should the system behave when there are no songs in it, when there is one song, and when there are many songs?
We also realize that the rule can apply to the number of borrowers on your system. In other words, what happens when there are no borrowers, one borrower, and many borrowers—and that, in itself, can be applied to total borrowers and concurrent borrowers.
Now you're getting somewhere. To keep things hyper-finely focused, you need to write a story that assumes that you have an empty library, with one borrower total, and that borrower is online. Note that, in this example, I’m skipping the case of an empty library with no borrowers only because I don’t know how that provides user value. (If I think of it, I’ll add it later.)
The first story—revised
Let’s rewrite the story and acceptance criteria:
Story: A single user views an empty library and sees a meaningful message.
As a teen-ager, I want to know that the library is empty, so that I don’t waste my time trying to borrow songs that are not available.
Acceptance criteria:
Given the digital library is online
And it has no content
And I am the only registered borrower
When I view the library offerings
Then a message is displayed informing me that there are no offerings
You show this story to the development team, and they like it. They say it gives them a chance to set up the server and go round trip to the user without having to worry, yet, about how to stream a song or implement digital rights security.
They are concerned that they will also have to implement user authentication as part of the story, but you say that can come later. For now, anyone who gets to the app is allowed access. You quickly make a note to write stories around user registration and authentication, and everyone is happy. So you go on to the next story.
The second story
Having covered the case with no songs are in the library and one user, you can either increase the number of songs, or the number of users. The former lets you start streaming music. The latter will teach you about handling concurrent users. You decide to move to one song being available, still with a single user, since this is deemed by your product owner to provide more user value.
Story: A single user that views a library with one song can stream that song.
As a teen-ager, I want to be able to play the song in the digital library so that I can enjoy it.
Given the digital library is online
And it has 1 song to offer
And I am the only registered borrower
When I view the single song that the library offers
And I choose to play that song
Then the song plays
When you show this small story to the development team, they point out that once they implement this story, they can split off into parallel initiatives: one to continue enhancing the song offerings, and another to figure out how to implement digital streaming rights.
The third story
Story: Library with many songs
As a teen-ager, I want to borrow from a bounty of digital music so that I can enjoy music that would otherwise be unavailable to me.
Given that the digital library is online
And it has many songs to offer
And I am the only registered borrower
When I view the alphabetized list of songs that the library offers
And I choose to play one of those songs
Then the song plays
The development team agrees that they can implement this simply and quickly. Requiring the sort order is a choice. Since the team says it’s only a few minutes to alphabetize a list, you keep it in.
Now that you've built up a base capability using small stories, it's much easier to add small bits of functionality to sort, search, improve the user interface, and so on.
More ways to apply the zero/one/many rule
The above example is just one case where hyper-fine story splitting with the “zero/one/many” rule comes into play. There’s no limit other than your imagination. Here are some different ways the rule could be applied.
Messaging
- What happens when no messages have passed through? When the first message passes through? When many messages have passed through?
- What happens with no subscribers to those messages? With one subscriber or many?
Shopping cart
- What if there is nothing in it, one thing, or many things?
- To implement pricing, start with an initial story where everything is free so you can concentrate on other things. Then everything has the same price. Then the system supports many prices. (Don’t release until you have your pricing right!)
Games
- Single player or multi-player?
- How would a system that supports no player be useful? A little brainstorming leads to the idea of a demonstration mode.
Audio
- What happens when the app is not playing audio? Do you still show audio controls? Do you need a visual cue to let users know that their sound is not broken?
- If the app is playing one audio stream, what functionality needs to be added? Where do audio controls appear? What visual cue do you use to indicate that the user should be hearing sound?
- If the app is playing many audio streams simultaneously, what’s the behavior? Is one dominant? Do you mix them? What happens to the audio controls?
But how is this independent?
Hyper-fine story splitting is a simple exercise you can use to brainstorm different ways to look at how to build up a large system.
One question people often ask about this technique is how it appears to violate the “Independent” part of the INVEST principles Is that OK? For example, your story “to serve up multiple songs” is dependent on the two stories before it getting done.
Yes, the story is obviously dependent on the previous two, but in fact it does not violate INVEST. An independent story does not have to be independent of every story that comes before it; it simply must be independent of every story that comes after it.
In other words, to deliver the value of that story, it should not require a next story. Whether the story in question provides enough capability to be released is a decision for the product owner. In the digital library example, the product owner might decide that it is valuable to release the digital library with just one song, which happens to be the song at the top of the charts.
Moving forward with hyper-fine splitting
With normal story splitting, you think in terms of splitting the capabilities of the system, users, roles, capabilities, etc. With hyper-fine story splitting, you are often adding a temporal dimension to how you mature the capability over a very short period of time, and not necessarily for more rapid releases (although that is a side benefit).
Use this approach to give your team time to observe the incremental improvements, learn from them, and release better capability than they could have imagined at the outset.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
