Contents of this guide
First, why story splitting is important Second, what kind of user story is an appropriate story? 2.1 User story format 2.2 The appropriate story should follow the InvEST principle 2.3 User stories are vertical slices 3 Story splitting flowchart Step 1: Prepare the story/feature to be split Step 2: Apply the split pattern Step 3: 6. Vertical Slicing and Scaling 6.1 Should you have 100+ people to develop a product? 6.2 Baseline for large-scale vertical sectioning
Why is story breaking important
Starting with the highest-priority, low-workload user stories allows the product team to continue to produce high-value products and get high-quality feedback. Many teams are trying to break down large user stories and features into appropriate stories, but instead of breaking them down into vertical slices of the business, they are breaking them down into stories that look more like tasks or components from the perspective of the overall technology architecture. As a result, they don’t experience the value or feedback that a short story deserves.
Fortunately, story breaking is a skill that can be learned in a relatively short period of time. We’ve seen how teams can break away from the struggle and quickly break the story apart with just a few hours of practice and a few simple tools. Later, we’ll show you how to organize this exercise.
Second, what is an appropriate user story?
Before we talk about breaking stories apart, we need to make sure that we have a common understanding of what constitutes an appropriate story and what can be broken down into stories.
First, let’s look at the definition of a user story: A user story describes a change in the behavior of the system from the user’s perspective. It describes the things that users want the system to do, or want the system to do for them, that are not currently in the system.
By the way, notice that user stories are in the solution space, not the problem space. It’s not a description of a person who wants to get a task Done somewhere (like JTBD[Job to be Done]), but a description of a person who wants to get something Done in your system. JTBD resonates well with customers in the problem domain, and user stories do a great job of translating that customer resonance into a series of changes to the software system while maintaining the customer’s perspective throughout the delivery process.
2.1 User Story Format
You’ll often see user stories written in a particular format like this:
- As a role
- I want function or action
- To achieve values or goals
Or there’s something like this:
- For value or purpose
- As a role
- I want function or action
The beauty of this template is that it requires you to answer three questions in the user story:
- Who is it for?
- What do they want to do, or have the system do, that doesn’t exist yet?
- Why do they do this?
The important thing, though, is not the template, but answering these three questions.
In fact, we rarely write a story with a complete template. Whether at the top of a post-it note or in the heading paragraph of an online project management tool, a short heading that says “What” is a good choice. The “WHAT” is provided by the title, while the “WHO” is usually provided by the product vision or release goal, which describes the core target customer. If the story is for that target audience, we don’t repeat it, and we only add the “WHO” when we’re writing a user story for a non-core target audience. Finally, we’ll make sure to write “WHY” in a “detailed description” or similar field in the online tool, or in a lighter type on a sticky note sheet.
Therefore, if we were to make a public library site, and the library’s readers were our default users, we would not write the user story like this:
- As a library reader,
- I want to search for a book by its title.
- So that I can find the book I want without any interference in the search results.
We would write:
- Find out exactly by title
- Because I know the specific book I want, I don’t want to get distracted in the search results
Sometimes we encounter situations where individual development tasks or architectural components are disguised as user stories. Even if you use a fancy description like “As a developer, I want a database diagram so that I can understand the structure of the database,” it’s still just a development task.
2.2 The right story should follow the INVEST principle
A few years ago, Extreme Programming pioneer Bill Wake came up with a great acronym for the six key attributes that a proper user story should have: INVEST. Let’s take a look at each one:
- I stands for INDEPENDENT. This means that a proper story is independent enough that it can be prioritized without regard to technical dependencies. Sometimes this means you need to provide Mock data or interfaces for a while so that you can test the story independently, allowing you to gain value faster or reduce risk early in the project.
- N stands for bartender (NEGOTIABLE). A proper story leaves room for negotiation on the details of what to do and how to do it. Of course, as the negotiation progresses and more details are hammered out, the story becomes less negotiable.
- V is for VALUABLE. Every story should add some visible increment of value to the user. This seems impossible at this stage, because you may have a large number of technical components and infrastructure tasks in your Product Backlog masquerade as user stories that do not directly add value to your users. As you grow in your story-breaking skills, you’ll get better at finding short pieces of functionality that directly provide value.
(Stories alone do not need to provide enough value to be published. You may need to accumulate multiple stories to go from being valuable to being marketable. I like the MMF (Minimum Marketable Features) as a container for stories.
- E stands for ESTIMABLE. A proper story should be defined so that the team can estimate its effort, which is usually a relative estimate made against a base story.
- S is for SMALL. A rule of thumb is that with a sorted Product Backlog, you should be able to rank the top 6 to 10 stories in the next Sprint. This allows you to get constant feedback and manage risk without having to manage too many stories. However, this number of stories is just a suggestion, and it scales with Sprint length, team size, team speed, and other factors.
- T stands for TESTABLE. We should have a way of knowing when we’ve finished a story. It can’t just be a vague expectation, it needs to be a concrete change in the behavior of the system.
Of course, there is a certain mutual exclusion between these properties. For example, as a story gets smaller, it becomes more difficult to make it stand alone and worthwhile; As a story becomes more negotiable, it becomes more difficult to estimate and test.
Fortunately, however, different attributes play a major role at different times. For example, once you get into the Sprint schedule, it’s even more important that the story be short, measurable, and testable. We still need the story to be independent, negotiable, and valuable, but these attributes are less important. In the Product Backlog story, the opposite is true.
2.3 User stories are vertical slices
When talking about a good story, you’ll often hear the word vertical slice. This is the right story in terms of software architecture requirements.
- A vertical slice is “a valuable work item that brings a change in the behavior of a system that may require multiple architectural layers to implement the change”. When you call this slice “done,” the system is clearly more valuable to the user.
- A horizontal slice is the opposite of a vertical slice. It is a “work item that changes a component or architectural layer in combination with other component or architectural level changes in order to deliver perceived value to the user.”
Let’s look at a very simple system architecture with the UI layer, the business logic layer, and the persistence layer. Your system may be more complex than that, but it probably has at least three layers.
(Schematic diagram of system architecture)
To capture most of the attributes of InVEST, the story must involve these three architectural levels. Without some UI change, some logic change, some persistence storage change, we might not be able to deliver value. Thus, the story is a vertical slice of the system.
Sometimes, these vertical slices are very wide. When we break the story apart, we will discuss how to find the thinner vertical slice in the wider vertical slice. But for now, it’s enough to know that stories should provide value across the architectural hierarchy when necessary.
Many fledgling agile teams try to split stories along architectural levels: one story for implementing the UI, another for updating the database, and so on. While the story may also be small, it is a failure in terms of independence and value delivery. When the team splits into vertical slices, they get the following benefits:
- Make the Backlog value clear
- Have more conversations about values
- Helps avoid accidentally building low-value changes
- Get value faster
- Get better quality feedback earlier
- It is easier to see constraints and todos and to respond accordingly
- Become more predictable when delivering value (because working software is the primary measure of progress)
We could go on and on, but this should give you some idea. When we sat down together and wrote down the various habits we had seen in successful agile teams, and how they were related to each other, we found that the vertical slice was related to almost all other habits, or at least some of them.
Look at the stories in the Product Backlog, some of which you have recently completed, and some of which you will work on in the future. Evaluate each story according to the InVEST criteria, identifying the vertical slice and the non-vertical slice. Then, see if you can improve on those stories.
Three, the story split flow chart
To help guide the team, Richard created a story breaking flowchart that outlined the questions we would ask as we helped the team break the story apart.
(Thumbnail of user story splitting process)
Let’s take a look at each of the three steps in Figure 1:
Step 1: Prepare the stories/features to split
(Preparing stories to be split)
The first step is to make sure that the stories/features you are breaking meet the InVEST criteria (except for the Small ones). In most cases, being Valuable is the problem. When people bring us stories that they think are “unbreakable,” they are really development tasks or architectural components disguised as stories. If you don’t start from a value-adding perspective, you can’t break it down and get incremental value. In this case, the next step is to combine the non-story with other horizontal slices so that they collectively represent a value increment. Now, is the slice too big? If so, you can start splitting.
Step 2: Apply the split mode
(Apply split mode)
Pattern 1: Split by workflow step
(Divided by workflow steps)
This is the story of my client building a content management system:
As a content manager, I can post the news to the company website.
It doesn’t sound like a big story — until we delve into the workflow of delivering the news. It turns out that just Posting a few sentences of news on the company’s website requires editorial and legal approval, as well as a final pre-release review on the pre-release site. 6-10 stories like this can’t be done in one iteration.
In such workflows, the greatest value often comes from the beginning and the end. The intermediate steps add incremental value, but they are not independent. So it’s good to build a simple end-to-end case first, and then add intermediate steps and special cases.
New stories include:
- … I can post the news directly to the company website.
- … I can do an editorial review before publishing a story.
- … I can do a legal check before publishing the news.
- … I can check the news on the pre-release site.
… I can post a news story from a pre-release site to the official site.
But sometimes the entire workflow is important, and you can’t just start with the beginning and the end. In these cases, look for a thin slice that runs through the workflow. Maybe it supports the most common case; Perhaps you can hardcode or otherwise simplify the most understandable parts of the workflow, and then you can explore the more complex parts.
Either way, the most obvious split — from beginning to end, step by step, by functional block — is the wrong way to go. Check out this excerpt from my 80/20 product ownership course to learn more about why this split is wrong, and how to use the other two approaches.
Pattern 2: Split by different business rules
(split by different business rules)
Buried in this story are equally complex stories that use different business rules to do the same thing:
As a user, I can search for flights using flexible date rules.
Diving deeper into “flexible date rules” reveals several different business rules, each of which can be a separate story:
- “N days between date X and date Y”.
- “Some weekend in December.”
- “N days before and after date Z”.
Pattern 3: Split by major work
(broken down by main work)
Sometimes, a story can be broken down into several parts, with most of the effort going to the first part. Take this credit card payment story:
As a user, I can pay for air ticket with Visa, MasterCard, Diners Club or American Express.
This story can be further broken down into four stories, one for each credit card. However, the infrastructure for credit card transactions is set up when the first story is handled; Add more credit card types and the work will be relatively small. We can estimate the scale of the first story to be larger than the other three, but we have to remember to change our estimates if the product owner later changes priorities. Instead, we can defer the decision on which card type to implement first, as shown below:
- … I can pay with one type of credit card (VISA, MC, DC, AMEX).
- … I can pay with all four credit card types (VISA, MC, DC, AMEX) (provided that one credit card type has been implemented).
The two new stories will still not be independent, but the dependencies will be much clearer than writing a story for each credit card type.
Pattern 4: Split by Simple/Complex
(Split by Simple/Complex)
When you discuss a story in a planning meeting, the story seems to get bigger and bigger (” What about X?” “, “Have you thought about Y?” ), you should stop and ask people, “What’s the simplest version?” Write this simple version as a user story. You may have to define acceptance criteria on site to keep things simple. Then, break down all the changes and complexities into other stories. Take this story:
As a user, I can search for flights between two destinations.
Keep it simple by splitting the changes like this:
- . Specifies the maximum number of transfers.
- . Including the nearby airport.
- . Use flexible date filtering rules.
- . And so on.
Pattern 5: Split by different types of data
(split by different types of data)
Complexity in a story can come from processing changes in the data. For example, the system I’m currently developing requires modeling the geographic areas served by transportation service providers. We could burn up the entire project budget just by dealing with the complex geography of the service area. When I’m done telling this story:
As a user, I can search for a transportation service provider based on the trip’s place of origin and destination.
Discussions with product owners revealed that while we don’t need a full-fledged GIS, modeling geographic environments is still very complex. We stopped and thought, “What is a ‘good enough’ geomodeling solution so that we can build other high-value features now?” We chose:
As a user, I can search for a transportation service provider by place of origin (city) and destination (city) of the trip.
This was fine for a while, until we collected more data and found that some service providers only served certain counties or even towns. So a new story emerges:
As a user, I can search for a transportation service provider by place of origin (e.g., city, county, township/town, street) and destination (e.g., city, county, township/town, street) of the trip.
When we looked at the new service provider data, we also found that some service providers supported trips that started in a single city but ended in any number of nearby cities. This leads to the following story:
Service providers can provide different geographical areas for the origin and destination of the trip.
All three stories are spin-offs from the original geographic story. The difference here is that we built the simplest version and added the new story in time. But in some cases, you can see the data change early in the project. A typical example is the localization of a system:
As a content administrator, I can create the news in the following languages:
English
Japanese
The Arabic language
And so on…
Mode 6: Split by different interfaces
(split according to different interfaces)
Sometimes the complexity of a story lies in the user interface rather than functionality. In this case, the story breaks down to start with the simplest UI and then build something that is easier to use or more beautiful. Of course, these are not standalone — the second story is essentially the original story if you do it first — but it can still be a useful way to break up the story.
As a user, I can search for flights between two destinations.
. Use simple date input.
. With a nice calendar interface.
Pattern 7: Delayed performance optimization
(Delay performance optimization)
Sometimes, the basic functionality of a story may not be difficult to implement, but it takes a lot of time to optimize performance. If you can learn a lot from the base feature of poor performance, and it has some value to the user (i.e. the user cannot complete the actions in the story without this feature), in this case you can break the story down into “make it work” and “make it work” :
As a user, I can search for flights between two destinations.
. (As long as the function is complete, display a “Searching…” when loading. “.)
. (Load time is limited to 5 seconds).
Pattern 8: Split by different business rules
(split by different business rules)
“Administration” in a user story covers multiple actions of the story. This provides a natural way to break up the story. Such as:
As a user, I can manage my account.
. I can register an account.
. I can edit my account Settings.
. I can close my account.
Pattern 9: Split out a probe
(Split a probe)
A story may be perceived as a lot of work not because its business is complex, but because the development team doesn’t know much about its technical implementation. In this case, no matter how much you clarify the business part of the story, you can’t break it down. After splitting a time-boxed probe story to resolve the uncertainty of development, we can decide whether to implement it directly or split it using the eight patterns described above. If we don’t know how the following story works:
As a user, I can pay by credit card.
So, break it down into:
- Research credit card payments.
- Implement credit card payments.
In the “research” story, the acceptance criteria should be the questions you need to answer. Research is as simple as answering questions. It’s easy to get carried away.
The Probe Split mode is explained last because it should be your last choice. What you already know can be used to build some features, so go ahead and start developing with what you already know. As the project progresses, these problems will most likely be solved. Therefore, make every effort to use one of the previous eight patterns before turning to the probe pattern.
Meta-patterns: Find complexity and reduce change
As we guided the team to more effectively break down the story, we discovered a meta-pattern common to these patterns: focus on complexity and use it to reduce change. You can use a meta-pattern as follows:
- Find the core complexity. What are the parts that are most likely to surprise or problem you? The answer to this question often depends on people’s personal preferences or habits. Sometimes, this is a part that needs to be reintegrated or has external dependencies.
- Identify the changes. What has changed a lot? Business rules, user types, interfaces, data changes, entities, and so on.
- Reduce all the changes to one. Find a single, complete slice in a complex part. It may be a single scenario, or it may be a series of scenarios that vary from a single business rule.
Most story splitting patterns are simply an example of identifying the source of change and reducing it to one.
This approach is especially good for the first slice of a new thing, because it cuts right to the core complexity and avoids anything that might make the work bigger.
Step 3: Evaluate the effect of the split
Evaluate the effect of the split
You may find that sometimes you can use several patterns to break up the same story. So which split should we choose? I usually use two rules of thumb:
Choose a split that allows you to lower your priority or throw away a story. The 80/20 rule states that most of the value of a user story comes from a small number of features. When one split reveals low-value functionality while the other does not, it shows that the latter split hides waste in each little story. Choose a split that lets you throw away low-value features.
Choose a split that will allow you to get more stories of the same size. The split of an 8-point story into four 2-point stories is more useful than producing a 5-point and a 3-point split, because it gives the product owner more freedom to prioritize the split stories separately.
It may take many trials to find the story breaking pattern that works best for you — you may need to experiment to find the right pattern.
Cynefin and story splitting
(Cynefin)
Dave Snowden’s Cynefin model is a useful way to think about the optimal strategy for a problem based on its complexity. We found Cynefin so useful that it was used in almost all of our workshops, either as a prerequisite or as a workshop itself. If you are not familiar with this model, check out our overview.
Each area of Cynefin’s story breakdown looks different. Here’s how to split it:
- Simple – Just build. If the stories are too big, find out all the stories and start with the most valuable ones.
- Complicated — Find out all the stories and make the ones that are most valuable and/or risky first.
- Complex – Don’t try to find all the stories. Find one or two that offer some value and teach you something about the problem and the solution, construct those stories, and then use what you’ve learned to find the rest.
- Chaotic — It may not be important to break up the story now, as you must first address the urgent issues at hand.
- Disordered – Figure out which domain you are in before splitting up so you don’t take the wrong approach.
The most important nuances are in the Complex Domain, where starting work gives you a quick idea of what you’re working on. In this case, there is no point in trying to find all the little stories that make up the original big story. It’s more efficient to find one or two stories that you can start studying right away.
Some people don’t like this method, and they want to list all the stories and size them so that they can log the stories to the Backlog and estimate the time. But if you’re really in the Complex Domain, this only gives you a false sense of predictability — the actual story is likely to change as the work progresses. It is best to be transparent about the uncertainties inherent in complex work.
5. Practice breaking stories
As we have said before, working in thin vertical slices is a key habit of agile software development. A lot of people are trying to find vertical slices, but it’s a very easy skill to learn. With just 2.5 to 3 hours of practice, teams can go from struggling to quickly identifying features and pieces of a big story in their field. Of course, the quality of practice is important. Here’s what I recommend:
- Schedule two or three 1-hour practice sessions over a 1-2 week period. Invite the whole team or at least a combination of business and technical perspectives that works well together.
- To prepare for this first practice, look at your Backlog for the last few months. Choose a few stories or features that you had trouble breaking down but have now successfully implemented.
- In Cynefin terms, these completed features are now ordered (complex or simple) because enough order has emerged to implement them. Future work is likely to be complex and disordered. But it doesn’t matter now. In the first exercise, your goal is to identify what makes the feature larger in your area. Tracing work done is key to exercise effectiveness.
- In the first exercise, take a feature or story of your choice and go through the questions in the story breakdown flowchart. You can also test how much you know about this feature, assuming it’s not already implemented.
- If you find a good split using one of these patterns, don’t stop. Continue to explore other patterns and try to find another possible way to split them.
- If one split doesn’t produce a small enough story, try continuing to split the story after the split.
- Stop after about 50 minutes. After using each of the split modes on the flowchart for the feature or story you are preparing, check the split stories for each mode.
- If you can’t find a way to break it down at this point, take some time to brainstorm with everyone. When these split patterns are applied to your feature or story, is there a consensus?
- If at the end of the first exercise it seems easy to break down the completed features, then you can try to break down the subsequent work. If not, repeat the first exercise. Before the next exercise, find a few suitable features and repeat the process.
- The difficulty with this is that it is an “exercise”. Many people who only want to improve through formal training or learning on the job often don’t want to take the time to do exercises, especially practice breaking down already completed features, because this activity won’t produce new work — for example, it won’t improve an upcoming Backlog. But this practice can quickly improve a team’s story-breaking skills. Don’t skip it.
- After two or three of these exercises, you should get to the point that for each feature in the work, everyone can quickly figure out the appropriate split pattern and quickly break down the story to fit the iteration.
Vertical sectioning and scaling
Can you use vertical slices when you have 100+ people working on the same product?
When you have multiple Agile teams working on the same product, there are two ways to organize: feature teams or component teams.
Feature teams are organized in such a way that each team has enough cross-functional members to provide a complete slice of value (the “vertical slice”) on some or all of the product. Depending on the size of the product, the feature team may focus on certain parts of the product, effectively creating sub-products, or they may work on the most important parts of the overall product.
Component teams are organized in such a way that each team focuses on a particular component, architectural level, or technical direction. Delivering a complete piece of value requires coordinating the work of multiple teams.
Let’s look at a concrete example of large commercial software: Taobao. (Note: I don’t know what the actual organization or technology of Taobao is, but it doesn’t matter, I just need a software product that everyone is familiar with to do the reasoning).
Taobao has an APP. It communicates with a back end written in some language through some communication protocol. At the back end, there are processes to process, such as searching for goods, generating orders, paying orders, and tracking logistics information.
If you have a component team structure, you have APP teams, for example, who can make changes to the APP interface, but they are likely to rely on the back-end team to make changes to parts of their system. Coordination between teams will focus on ensuring that their work moves in sync to ultimately deliver value.
With a feature team structure, you might have one team or group of teams responsible for the search module for the item, another for the order module, a third for the payment module, and so on. Each of these teams has APP and back-end skills. In this case, coordination between teams will focus on ensuring consistent design and architecture across the product.
For the same product, teams organized in two different ways will get two different sets of results and coordination plans.
So the answer to the question of whether vertical slices are related to scale depends on how you organize them. Component teams do not work in vertical slices. However, component teams can coordinate work around larger vertical slices (such as MMFs), but at the specific work item level, component teams cannot perform all the functions required for vertical slices. Building component teams cannot deliver value on their own, but this way of organizing can be optimized for other things (usually easier architectural adjustment or higher R&D staff utilization).
Feature teams are the opposite of the benefits of building a team. They aim to provide vertical slices independently in order to deliver value and get feedback more quickly, at the expense of explicitly coordinating architectural consistency.
Feature teams and component teams are the two main organizational methods. Of course, some organizations may be slightly different or mixed and will change over time. I’ve written about this before, especially in the context of transforming an organization with a large legacy product.
6.1 Should 100+ people develop a product?
Now, the bigger question on our mind is: whether we can use vertical slices for large products/projects (and as we’ve shown, if we’re organized as feature teams, we can), does this mass of people really work?
Adding people or teams to a single product/project incurs some productivity and coordination overhead: if the project has only one person, that person’s productivity is almost 100%; If we add one more person, instead of getting twice as much productivity, we might only get 1.8 times as much productivity (90% per person) because it takes time for the two people to coordinate their work (10% per person); When you increase to 3 people, productivity increases again, this time by a factor of 2.4 (80% productivity per person), and coordination costs rise accordingly (20% productivity per person). Moreover, the cost of such coordination increases exponentially with the number of connections between people.
By setting up a small team, each person only needs to coordinate the work details with a few people, and try to divide the work among the teams to reduce the dependence as much as possible, so as to reduce the cost of coordination to a certain extent. But the more complex the work, the less predictable the dependencies and the greater the likelihood that coordination will be needed between teams.
Therefore, at some point, adding one more person or team to a project/product will not only fail to increase productivity, but will also increase coordination overhead for the entire system and ultimately lead to a decrease in overall productivity.
Relationship between team size, value added, and coordination overhead
Where the tipping point for team size falls depends largely on the project/product context. But the shape of the parabola should at least make us suspicious of large teams and think twice about adding more people or teams.
This is especially true for complex work, as it may take us some time to work on a project/product before we understand the real problems and solutions. In software development, complexity seems to be highly correlated with value. The higher the value of the feature, the more likely it is that the project/product won’t find it early on. If it’s a new project/product, there’s a good chance we’ll learn something new as we go along and improve the value we deliver.
6.2 Baseline for large-scale vertical sectioning
Yes, you can do vertical slices at every level of detail and at all scales of work, and that’s valuable. But on a large scale, you need to organize in a very specific way: as a feature team, or in some hybrid way that emphasizes functional delivery. And, as you use it, you need to consider whether your requirements really need such a large scale.
The little boat brother is quick
Author: adoudou
Disclaimer: The article was forwarded on IDCF public account (devopshub) with the authorization of the author. Quality content to share with the technical partners of the Sifou platform, if the original author has other considerations, please contact Xiaobian to delete, thanks.
Every Thursday in May at 8 p.m., quality and testing special. Public message “quality” can obtain the address
- 0506 Zhu Shaomin “How to Maximize Software Testing Efficiency”
- 0513 Chen Qi “Data Driven Test”
- Chen Ji “yes, to QA is the most effective way to improve quality!”
- Shi Huibin “Continuous Testing of DevOps Practice”