The benefits of breaking down user stories
Breaking down problems into smaller, more consumable pieces can improve predictability and feedback cycles while reducing risk.
⚠️ A human wrote this article.
Before anything else, we need to address the actual definition of a user story, as originally coined by XP:
I’ll try to go over the benefits of adequately 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 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 teams by technology (backend and frontend).
Anything worth doing is worth doing badly — at first. ~ Dick Karpinski
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 frequently and collaborate closely with the customer.
Imagine you need to develop a dashboard with a few metrics and some nice-looking charts. The typical approach is that some PO/PM that “knows what the users want” proposes 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 involve the customer in the process. This divide-and-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
Software that has not been released has no value, in fact, it’s a liability. So why are businesses so keen on waiting for release dates? ~ Steve Bishop
Increasing feedback cycles
Feedback is at the heart of agile and lean development. Without feedback, we develop software blindly. We only learn what to build next as we get feedback. With feedback, we promote customer engagement.
The biggest risk to any software effort is that you end up building something that isn’t useful. The earlier and more frequently you get working software in front of real users, the quicker you get feedback to find out how valuable it really is. Continuous Delivery
With smaller cycles, we can digest feedback in a steady stream of small chunks. In addition to the user feedback, consider feedback from peers, automated testing, the overall system design (e.g., does the change fit the architecture?), etc. You also get earlier SEO indexing if you're building a website. In a nutshell, we are facing reality sooner with a smaller experiment.
With constant feedback, we have plenty of opportunities to test assumptions, learn from users, adjust, pivot, and abort. 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, we put value in users’ hands sooner rather than design mockups, plans, and other promises. This is one of the principles of lean software development: to deliver as early as possible. Beware that listening to feedback doesn’t mean we’ll do all that customers ask; reality is way more nuanced.
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 deliver value frequently, you’re not learning and adapting as much as possible (which means you may be creating waste).
Instead of “when will this be done,” ask “when can people start using this?” They’re not the same question. You can create a feature in one big-bang (waterfall-style) or you can create it in a number of “value drops” and collect feedback along the way. ~ Tim Ottigner
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, backend, and 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.
The biggest bottleneck in software development is lack of skills needed to vertically slice user stories. It is useless, nay harmful, to strive to increase collaboration if the user stories are not vertically sliced. Horizontally sliced stories always lead to hardening of silos. ~ Alex Bunardzic
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 daunting; conversations are quick and focused; design, implementation, and testing are simpler (e.g., code reviews are more approachable); there’s less handover burden.
The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and starting on the first one. ~ Mark Twain
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 (recursive) is crucial in 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 if it’s something minimal. If all stories are as small as they can be, it’s easier to achieve a constant pace of delivery. This, in turn, contributes to managing users’ expectations by reducing delivery anxiety. This is especially relevant if you adhere to the #NoEstimates movement.
Get Luís Soares’s stories in your inbox
Join Medium for free to get updates from this writer.
Slicing stories is taking small steps instead of one big jump. It helps us handle uncertainty and unknowns because we can tackle them one step at a time, 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.
If you report progress through a status meeting and/or documents instead of working software, you most likely failed at slicing. ~ Dragan Stepanović
De-risking
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 significant 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. We can revert without sorrow.
Less wrong, not more fast. By “less wrong” I mean “wrong for less time”. You can’t make your ignorant or uninformed decisions better, not until you learn. Optimize for being wrong for the shortest possible time. ~ Kent Beck
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
Delivering many small things smoothly is way better than a big, risky deliverable. With small stories, we go far, steadily.
The larger the batch size, the riskier the result. If you want to manage risk, start there first. “What’s the simplest possible thing that could work and we could get feedback from”? ~ Steve Bishop
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 to the experiment if needed, reducing waste. Interruptions are less expensive because you’re always doing small, meaningful things.
Big stories almost always hide unnecessary (low value) work. When you split big ones up into many narrowly scoped small stories, you find that many of those small stories aren’t worth implementing. ~ Allen Holub
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, long-lived feature flags) because significant endeavors will be halted when new priorities arrive.
Easier prioritization
With big stories, you commit to doing a large chunk of work for a long time—you’re forcing a set of user stories into one to adhere to the same priority. With small stories:
- There are plenty more opportunities for prioritization (do it daily).
- If both are small, it’s easier to determine whether story A is more important than story B. Thus, you end up with improved and more fine-grained work management.
- The price of making a prioritization mistake is low; if you implement a less critical story today by mistake, you will only postpone the others for a few days.
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.
To some it might seem that there is value to users in adding lots of features, but there is, in fact, more value in adding a simple, small piece of technology with evolvable value. Patterns of Software
Culture of experimentation
All life is an experiment. The more experiments you make the better. ~ Ralph Waldo Emerson
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 value as often as possible.
Small stories promote a culture of experimentation. It’s easier to control the experiment variables and reduce the cost of being wrong (hence, people are less afraid of making mistakes). In other words, when stories are small, delivering them feels like running small, low-risk experiments. Since experiments are supposed to be concrete and controlled, stories are, by definition, small.
Testing assumptions early implies keeping stories small. We should be humble and recognize that we can always be wrong. If you have to pivot or fail, you'd better know it sooner.
Try Again. Fail Again. Fail Better. ~ Samuel Beckett
Team motivation
Observing our software being used is a source of happiness. As a team member, you experience daily accomplishment and fulfillment as you witness a steady stream of value being delivered and positively impacting lives. Customers and users hear 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.
Research has shown that of all forms of human motivation the most effective one is progress. Essentialism
