The benefits of breaking down user stories
Breaking down problems into smaller, more consumable pieces can improve predictability and feedback cycles while reducing risk.
Before anything else, we need to address the real definition of a user story, as originally coined by XP:
I’ll try to go over the benefits of properly slicing user stories. To be clear, when I say small, I’m referring to the size of the problem, not the solution (even a little story can take a while to implement in some cases). Therefore, splitting user stories means recursively splitting the problem, not the solution. Beware that splitting by vertical slices of value is only effective if you have autonomous and multi-disciplinary teams — comprised of people who, together, have the necessary skills and empowerment to deliver user value. It’s way harder to achieve this when you have backend and frontend teams.
This approach has several noteworthy benefits. Let’s go over them.
Reducing delivery anxiety
When users have to wait a lot to see something new, anxiety and risk accumulate, and clients start asking for dates and hard commitments to upfront plans (which is harmful because we are discovering as we go). The solution is to release often and team up with the customer.
Imagine you need to develop a dashboard with a few metrics and some nice-looking charts. The typical approach is some PO/PM that “knows what the users want” proposing a big idea, a designer draws some fancy-looking mockups full of bells and whistles and shows them to everyone; people get excited (customers included); the team sets a goal for the following months based on a master plan — just as in waterfall.
This dashboard initiative happened to my team, but our approach was doing a little user research, developing a screen with a single number, having some nice chats with some users, adjusting, and repeating — customer collaboration over contract negotiation. Had we done the upfront design and developed it, we would have ended up with a beautiful but useless dashboard — responding to change over following a plan. We would also have trouble managing client expectations after they saw the beautiful mockups and got excited. It’s much better to make the customer part of the process. This divide-to-conquer strategy is how agile embraces uncertainty. It’s also one of the extreme programming practices called flow:
The principle of flow suggests that for improvement, deploy smaller increments of value ever more frequently. Extreme Programming Explained
More frequent feedback cycles
Feedback is at the heart of agile and lean development. Without feedback, we develop software blindly. With smaller cycles, we adjust often. We promote customer engagement through fruitful conversations and act accordingly. You only learn what to build next as you get feedback.
With small stories, you can test assumptions, learn from users, act on feedback, pivot, abort, fail early, etc. This aligns with the continuous integration/delivery paradigm, where we aim to increase early defect discovery and productivity and provide faster release cycles.
Great software today is often preferable to perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution. The Pragmatic Programmer
With small stories, value is in users’ hands sooner and more frequently rather than making promises of delivery on some date far ahead. This is one of the principles of lean software development: to deliver as soon as possible.
Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software. […] Working software is the primary measure of progress. Principles behind the Agile Manifesto
It follows from the definition of ‘user story’ that backlogs should not be “to-do” lists; they are instead “to-learn” lists. If you don’t deploy frequently, you’re not learning and adapting as much as possible; you’re creating waste.
Reducing internal silos
When you split into layers, you don’t have user stories. All you have are technical tasks. This division strengthens the wrong internal silos like the frontend vs. backend vs. database. These require coordination, back and forth, and hand-offs. Real user stories are vertical, by definition. The backend and frontend are implementation details. I prefer to think vertically.
Tackling complexity
Developing software is different from building a bridge. In software, you can add value in baby steps and collect feedback early on. Small stories are easier to consume, more manageable, and less overwhelming; conversations are quick and focused; design, implementation, and testing are simpler (e.g., code reviews are more approachable); there’s less handover burden.
Small stories should be your team’s units of work. Every user story is a potential small iteration and an increment of value. Story splitting is key to managing complexity. It encourages us to think about the present needs and continuously adapt instead of doing upfront planning (which would be waterfall thinking). It doesn’t rely on people who have the big picture in their minds because everything is small and self-contained. It encourages modularity. Feature flagging (and other mechanisms) is barely needed.
Smaller pieces of functionality are easier to design, implement, and test. This also means fewer bugs and faster development. “Design first, then build”: let’s bury this myth forevermore
Predictability
In queueing theory, small batches reduce the cycle time. You don’t have to wait too long to see something useful, even tiny. Suppose all stories are as small as they can be. In that case, it’s easier to achieve a constant pace of delivery, which contributes to managing users'/clients' expectations as it reduces delivery anxiety. This is especially relevant if you adhere to the #NoEstimates movement.
Slicing stories is like taking small steps instead of one big jump. It helps us handle uncertainty and unknowns because we can tackle them little by little, like turning on a flashlight in a dark room to see where we’re going. There are never big letdowns because there are no big surprises.
Less risk
Why risk working on big things that can be wrong? Besides, the sunk cost fallacy is more likely if there's a build-up: it’s harder to let go if there is a big investment. With small stories, we reduce the likelihood of surprises. The blast radius is always narrow. We can proactively predict risks and reactively trace back issues.
Working iteratively in small steps works better than not. Organizing our work into a series of small informal experiments and gathering feedback to inform our learning allows us to proceed more deliberately and to explore the problem and solution spaces that we inhabit. Compartmentalizing our work so that each part is focused, clear, and understandable allows us to evolve our systems safely and deliberately even when we don’t understand the destination before we begin. […] We can work in small steps so that we can understand the impact of each step. Modern Software Engineering
Small and frequent victories superseded a big possible victory. With small stories, we go far, steadily.
Less waste
With small stories, we learn about possible technical (and other) limitations as early as possible. We make fewer technical and functional commitments, which makes it easier to revert the experiment if needed, reducing waste.
When you work on big stories for long periods, more things will change in the meantime. There’s more buildup and upfront work. There’s more data in our minds. Context-switching is way more expensive. Also, you’re likelier to leave things unfinished (e.g., dead code, pointless database tables) because big endeavors will surely be halted when new priorities arrive.
Easier prioritization
With big stories, you commit to doing a big chunk of work for a long time — you’re forcing a set of user stories into one to abide by the same priority. With small stories, there are plenty more opportunities for prioritization.
Additionally, it’s easier to determine whether story A is more important than story B if both are small. You end up with a more granular work management.
Constant discovery
If you were commanding a ship, you’d like to be able to steer it as often as possible. With small stories, you have more opportunities to prioritize and discard. You can pick the next most important thing to work on more often. You can pivot anytime — if you need to compromise on the scope side and cut it short, there’s already value on the table. In short, you develop a product in a state of constant discovery, where you only learn what you will do next after delivering the story and getting feedback.
Culture of experimentation
Often, the best way to learn about the problem space is through experiments. Every time you put your hands on and deliver, your perspective of the domain changes. Therefore, you want to deliver as often as possible.
Every small story is a small assumption; delivering it is like running a small experiment. If you think about user stories as low-risk experiments, you don’t even need to slice them, to begin with, because experiments are supposed to be small.
Small stories promote a culture of experimentation: it’s easier to control the experiment variables and lower the cost of being wrong (hence, people are less afraid of being wrong).
Testing assumptions early implicates keeping stories small. We should be humble to recognize we can always be wrong. If you have to pivot or fail, you better know it sooner.
Team motivation
Seeing things being used as a source of happiness. As a team member, you achieve almost daily accomplishments as you can watch a steady stream of value delivered and impacting lives. You hear back from customers and users that you are solving their problems more often, assuming you adjust to feedback. You may end up in a virtuous feedback loop where one thing feeds the other.
