Breaking down features into smaller stories that the development team can build quickly is essential to keeping an agile release cadence. But what's the best way to do that? First, you need to understand the best practices for story sizes, and then you need story-splitting techniques to break them down. I'll walk you through industry best practices that include:
- How to decide when your user stories are small enough and when stories need to be bundled together
- Criteria for a good story
- Traditional story-splitting methods
- A technique called “hyper-fine story splitting” that helps break down stories even further when traditional methods aren't enough
How to think about user story writing: Gain speed by thinking small
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, but each story should be releasable by itself. 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 that teams tend to break down large features include:
- Functional decomposition
- 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 functional pieces or architectural components.
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 result with one swing of the pickaxe.
Delivering value doesn’t mean that a story is only valuable when it can be released by itself. This distinction 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. Even though you should develop each story so that it can be released by itself, it doesn't mean you'll always want to release a story by itself.
The INVEST concept
Before we 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, is 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 one into its own story. For example, the capabilities “sort and search” may each be its 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 from 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
You can’t assume that users are interacting with your system using a standard computer. Various smartphones and IoT devices need to be considered in your stories. 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 spur the creative process and continue breaking 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 enables 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 the functionality, you have decided that your highest business value lies in serving your 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 teenager, 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. 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.
What happens when there are no borrowers, one borrower, and many borrowers?
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.
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 teenager, 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 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 teenager, 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 teenager, 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, and improve the user interface.
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 the cart, 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 can have the same price. And finally you can build support for 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 okay? 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 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 subsequent 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.
