Why Split Big User Stories?
As many teams learn the Agile Mindset, they struggle having too many large stories. Some linger on the board and spill over from one sprint to the next, in Scrum. I’ve seen Kanban teams with big stories in the ‘In Process’ column for literally months. For some teams, it’s easy to just ignore these big stories because the people working on them seem productive or are making progress. But what are they missing? Why does it even matter that you break down your big stories?
Why break down big stories?
You might even ask, “Why be agile at all?” because they’re similar questions to me. The point of being agile is to be nimble and to be able to change your mind. But in order to do that, we need feedback loops. We need to be iterative. The trick to being iterative is being OK with getting to the first possible feedback point quickly, even if the product is imperfect, in order to assess how it’s going. That means deliberately trying to NOT write “perfect stories” where the product feature (for example) is exactly as you think it needs to be before moving on.
Being iterative, as shown below, keeps the big picture in mind while slowly making it better over time. It’s tempting to perfect one small piece of the puzzle and call it done before moving on, but in the end if no one likes your Mona Lisa, it was all a waste of time. The key is to create the opportunity to find out sooner.
It is this creating of the opportunity for feedback that makes it work, whether you ask the PO, the team takes the work to the customer, or you ask stakeholders in a Sprint Review. Then the team and the PO can decide what to do next. Maybe it stinks and you scrap the whole feature! Think of the time you might save! Or maybe what you’ve built is good enough and you don’t need to do the other handful of things you thought were necessary. Or the feedback you get helps you do something different that the customer wants or needs more. These things are possible only if you pause to get feedback.
Remember, another way to think about being agile is that you can say this one very powerful thing: “We guarantee we are always working on the most important things and will deliver demonstrable value every sprint.” And that statement is how we avoid irrational deadlines, maintain a sustainable pace, and how we delight the customer.
How do we break down big stories?
This is definitely easy to say and hard to do. It’s tricky to think iteratively, with the end product in mind, while pausing at a meaningful place to get feedback. Especially because the best approach is to build working products that slice through all layers of the software architecture. That means, for example, creating a clickable working product that’s been tested, using your standard libraries, APIs, and components and is not just a throw-away prototype. (There are definitely times to use low or high fidelity prototypes, even crayon on paper, but that work is upstream in the design thinking process, as you are still exploring what to build in the first place.)
So, what are some questions you might ask yourself as you consider breaking down a big user story?
Are there any big unknowns to our implementation approach? The shared understanding a team has for a story that is truly ready for work includes a more-or-less common approach to how the work will get done. If there are big gaps like “we don’t even know which data source we’re going to get the customer data from” then, that’s a pretty big unknown you should figure out first. Or “we haven’t decided which 3rd party API to use.” To resolve obvious gaps that are small research tasks that answer a simple question, use a Spike. A spike is a time-boxed user story that is designed to answer a question, often a yes or no or simple answer, usually using half a day or one day at most. The work conducted (even any code that may be produced) during the spike is intended to be throw away, so the most common practice is to not put an estimate or story points on a spike. It’s just stuff you need to do to be able to better describe the real story that needs the answer.
Other gotchas to look out for in big stories include the use of “vague verbs” like manage or administer. How big is a story that says “Manage the password reset requests”? Who knows! Digging into the verb manage might help you realize that you need multiple stories to do all the things you need to do with those password reset requests, for example.
While these two approaches can help, they really just help to mitigate some risks. The most effective way to slice stories is unfortunately dealing with the business details of how the story is delivering value to the customer. So you might ask yourself “What’s the smallest amount of work we can do to deliver value to the customer so we can get feedback?” And if you’re not thinking hard enough, you might ask that question again. “Can it be even smaller?” Remember, it doesn’t need to be the full end product, it can be just a portion of a web page, or one function that serves a purpose, etc. Or, it can purposefully cut some corners like not quite getting the finer polish of UX. And if you’re very clever you might even have some infrastructure that serves up fake-but-real data from a backend source so that you can stub in backend services in an earlier version of the product before doing all of the data related work in order to get feedback sooner. As long as your work is iterative and you can imagine writing the subsequent user stories to build the next iteration to improve the product based on your feedback, it’s bound to be a helpful approach.
What if you can’t break down the story?
While it is possible that some work is just so big that it can’t be broken down in ways I’ve described above, I’ve found it’s usually the case you’ve just not discovered the right technique to be clever about breaking the work up into meaningful chunks. Some non-technical work, for example, seems to be challenging. Conducting a survey of 100 users? Maybe just survey the first 5 and review results to see if it’s producing meaningful results. Cutting over from one big system to another? Can you direct only a small percentage of traffic to the new system as a beta test first?
An important reminder: do not default to waterfall ways of splitting up a story into design, development, and test work as separate stories. This does not help you get feedback any sooner or solve the agile iterative feedback loop concept.
However, if you do happen to have a large story that simply cannot be broken into reasonable parts for the sake of gathering feedback and possibly learning something that will help you change direction, save time, or solve the customer’s problem differently, then just don’t. Arbitrary, incomplete items generally do not help gather meaningful feedback.
But the longer you work at slicing big stories, the more clever you will get at finding ways to break them down.
If you enjoyed this, please clap and share. It means a lot to know my work on this blog is read and used by agilists out there in the world.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
