The Art of Splitting User Stories

When Bigger Isn’t Better

Image by Author

TL;DR Small user stories reduce the risk of not achieving sprint goals and enable faster, more frequent, and consistent iterative development. Splitting user stories to the smallest reasonable size enables faster flow through the software development lifecycle by becoming easier to understand, estimate, develop, test, and deploy. Split vertically, not horizontally, to deliver thin slices of value.

Where exactly does the mentality “the bigger, the better” come from? It’s a common phrase that has been played out in American culture time and time again throughout history:

• Fast food portion sizes have grown out of control over the last 30 years as burger chains across the country seemingly race the most artery-clogging chunk of meat award.
• Superstores such as Walmart, Target, Costco, etc. have become shrines to American consumerism and are significantly larger than similar big-box retailers around the world.
• American cars are notably larger than their European shoebox counterparts, especially SUV’s and trucks.
• American home sizes have risen significantly since 1970, giving rise to enormous mass-produced McMansions that popped up across the U.S. throughout the 90’s and early 00's.
• The state of Texas even hangs their hat on it with an unofficial motto of “Everything’s bigger in Texas”.

The list goes on and on, but this begs the question — is bigger really always better? In the world of Agile software development, this couldn’t be further from the truth! Consider the following:

• Large teams are fraught with communication inefficiencies so we organize around small, multi-disciplinary, autonomous teams to tackle our work.
• Huge specification documents created up-front, before development begins are a complete waste of time because we recognize that markets shift, consumer preferences change, etc. so we create ever-evolving product backlogs and continuously refine work in the immediate future while providing some high-level insight into work further out so the business knows where we think we’re heading and can plan accordingly.
• Large development cycles present an enormous amount of risk that what we’re building won’t meet user needs by the time its deployed so we break our work into short 2-week sprint cycles to shrink feedback loops and enable faster iterative development.
• Finally, large work items (epics, user stories, etc.) are a killer of team efficiency, so we consciously split them into small, manageable chunks to deliver work more frequently and lower the risk of failing sprint goals.

Lean Agile & The Principle of Flow

The primary goal of a lean Agile organization is to enable the highly efficient flow of the right value from ideation through implementation and ultimately into the hands of end-users. Its focus must be on optimizing the speed, frequency, and consistency of value delivery over time while remaining nimble in the face of ever-changing and evolving requirements.

Traditionally, Lean organizational principles emphasized the optimization of flow through continuous improvement of fairly predictable processes. In our world of Agile software development, the work we do is anything but predictable; however, in practice, teams can blend the two philosophies of Lean and Agile together while maintaining their ability to adapt to customer needs. Specifically, lean Agile principles call upon Lean concepts of visualizing and limiting work in progress (WIP), managing queue lengths, and reducing batch-sizes to help accomplish this. While the first two are important (and the topic of future discussion), reducing batch-sizes is the primary driver to unlocking a truly Agile enterprise built on short feedback loops and rapid experimentation whereby small increments of value are developed, deployed, and iterated on to achieve high product-market fit.

Specifically, smaller work items (user stories, bugs, and tasks in Scrum lingo) not only enable highly efficient flow of work through a team’s software development lifecycle, but when split correctly they help maximize the value of the work delivered by a Scrum team to their users each sprint and can significantly reduce the risk of missing sprint goals.

Impact on Estimation Accuracy

Most Scrum teams estimate user stories from their product backlog in story points using the fibonacci sequence of [1, 2, 3, 5, 8, etc]. This pattern works for a few reasons:

• It’s Not That Accurate: Too often teams get hung up on trying to achieve perfect estimates. In reality, highly accurate estimates provide little value when calculating the team’s velocity. It’s very unlikely that you’ll provide perfect estimates and the errors tend to average out over time to the team’s good enough velocity anyway. The fibonacci sequence encourages rough order of magnitude (ROM) estimates by limiting the values that teams can pick from. For example, if a user story is bigger than 3 story points but smaller than 8, the team must select 5 — estimates of 4, 6, or 7 story points are not allowed.
• Uncertainty is Built In: The fibonacci sequence is extremely popular in Scrum due to the increasing delta between adjacent values as the estimate grows(1, 1, 2, 3, etc.). This provides a nice representation of the inherent uncertainty present in larger user stories. Numerous factors affect user story estimates — technical complexity, the developer’s familiarity with the technology and/or system architecture, the number of people required to complete the work (and handoffs, communication, steps involved, etc.), and much more. Scrum teams also don’t typically have all of the information they need to provide a highly accurate estimate — instead, information is learned as development on the user story progresses. This uncertainty is built into larger estimates on the scale.

People are notoriously very bad at estimating effort. It’s extremely common for teams to dramatically underestimate larger work items (epics, large user stories, etc.). After going through a refinement exercise, the resultant sum of user stories is almost always greater than the original estimate and even then it’s likely still an underestimate of the actual effort that will be required.

This happens most often because of the unforeseen effort not originally accounted for — roadblocks that inevitably arise, additional work as part of the team’s Definition of Done not being accounted for (ex. — testing and deployment efforts), greater technical complexity than initially anticipated, etc. Software development is extremely complex — the larger the epic or user story, the greater the chance that these estimation killers will arise mid-sprint. By limiting their scope, smaller work items become easier to estimate more confidently and accurately.

Impact on Value Delivery

Splitting user stories allows for incremental development and faster feedback loops. Because small user stories are able to move through the software development lifecycle faster, they significantly reduce the risk of missing sprint goals and increase value delivery by improving the likelihood that at least a portion of the committed work is completed by the end of a given sprint. Consider the following sample sprint backlog:

Image by Author

In this example, a team of 3 developers has committed to a total of 24 story points (8 story points per developer). Assume that each story is completed in the priority order shown and, for whatever reason, each person is only able to complete 75% of their commitments within the sprint (6 story points each). The results for each developer would be as follows:

• Developer 1: Completes Story 1 and Story 4, but does not start Story 7.
• Developer 2: Completes Story 2, but leaves Story 5 partially completed and does not start Story 6.
• Developer 3: Does not complete any user stories and leaves Story 3 partially completed.

In this scenario, the team only delivers 11 story points, or 45.8% of their original commitment. Now assume that the team spent time splitting larger user stories as follows:

Image by Author

Under this new scenario, the results for each developer are as follows:

• Developer #1: Completes Story 1 and Story 4, but does not start Story 7.
• Developer #2: Completes Story 2 and Story 5a, but leaves Story 5b partially completed and does not start Story 6.
• Developer #3: Completes Story 3a and 3b, but leaves story 3c partially completed.

Under this new scenario, the team delivers 17 story points, or 70.8% of their original commitment — 25% higher than the previous scenario, representing a 54.5% jump in delivered story points!

While splitting user stories doesn’t guarantee teams accomplish sprint goals, it significantly reduces the risk of not doing so and increases the likelihood that at least a portion of the originally planned work is completed each sprint.

Vertical vs. Horizontal Splitting

When splitting user stories, a common trap teams fall into is splitting horizontally, or along different development functions such as back-end vs. front-end vs. API integration vs. testing work. Consider the following image:

Image from Google Images

Teams often split this way because of how they are organized — historically around development functions and specialties. It’s still not uncommon to see teams split DBA’s from front-end developers from back-end developers as “experts” within the group and have QA/testing be a separate department altogether. Naturally, team members gravitate toward splitting user stories along the lines of the type of work that they’re most comfortable performing.

The most efficient organizations, however, have learned to build their Scrum teams around multidisciplinary individuals who all bear the responsibility of each of these roles in some capacity. This helps to not only reduce the number of handoffs required to complete the work but also focus the team on delivering holistic product increments rather than piecemeal, disparate bits of functionality that don’t add value to the end-user until all are completed.

To learn more efficient methods of splitting user stories, consider the following two methods:

Splitting Method #1 — SPIDR

Coined by Mike Cohn of Mountain Goat software, this easy to remember acronym dramatically simplifies the art of story splitting into 5 simple steps:

Image by Mountain Goat Software

• Spike: Are portions of the work unclear regarding architecture/design, technical knowledge, etc? Create a discovery spike to address the uncertainty, then circle back on development work when the picture isn’t as muddy and the team can more confidently plan the work. Be sure to make it clear what questions need to be answered and time-box the spike accordingly (several spikes are perfectly OK to iterate on the unknown elements of the user story).
• Paths: Are different user experiences involved? For example, when creating a login page for a website you may have username/password, e-mail/password, Facebook login, G-mail login, and LinkedIn login options. Each of these represent different user flows in the login process that can be split into separate user stories.
• Interfaces: Are different user panes involved such as web vs. iOS vs. Android, browser types and versions, etc. or is the interface particularly complex? Try splitting these out as separate user stories or make a shitty-first-draft (i.e. — MVP) to capture primary functionality first, then circle back to pretty-ify the UI at a later date.
• Data: Is the data capture or manipulation particularly complex? Try a partial implementation based on data subsets first, then build out remaining data integrations incrementally. For example, when building a checkout form you may want to capture required information such as the name and address first while leaving non-required fields such as a phone number or message to the recipient for a later date.
• Rules: Is there a large number of rules that must be adhered to? These can include business logic, performance and reliability requirements, other non-functional requirements, etc. Try incrementally adding these over time, focusing on the most critical ones first. Just like a Product Owner defines an MVP for the product, the Scrum team can define an MVP for larger, more complex epics and user stories in the name of building incrementally to get faster feedback and iterate more quickly.

Note that you don’t need to use or consider all of these methods on each and every split. Start with whichever is the most promising and stop when you find a split that works well for your team in the context of the work you’re doing.

Download the SPIDR poster here.

Splitting Method #2 — Story Splitting Flow Chart

Still struggling to find a good split for your user story? Try this popular story splitting flowchart, made popular by the team at Agile For All, to help nudge you in the right direction:

Image by AgileForAll

When Does Small = Small-enough?

How do you know when you’ve achieved the right split and user stories are the right size? Keep it simple by following this simple 3-question test:

• Can the user story be completed in less than 1 sprint?
• Must all components of the user story be completed together? Perhaps some portions are more or less important than others that can be split into different phases.
• Does the user story still pass the INVEST principle and the team’s Definition of Ready (if applicable)?

If your answer is yes to each of these questions, then you’re done! Avoid spending too much time splitting user stories to their smallest conceivable size — your time is likely better spent getting started on the stories themselves.

User Story Splitting Anti-patterns

Avoid these traps when splitting your user stories:

• Horizontal Splitting: Each user story should deliver value to an end-user. Horizontal splitting (by front-end vs. back-end vs. API layer, testing, etc.), while they may make progress toward a larger project- or initiative-level set of objectives, ultimately fails to do this. Instead, vertical slices of value allow teams to continuously validate assumptions and iterate on the solution to better tailor it to their users needs.
• End-of-Sprint Splitting: Avoid splitting user stories at the end of a sprint for sake of padding the team’s velocity. Anything that does not meet the team’s definition of done (DoD) and is not in a releasable state should be rolled over to the following sprint.
• Splitting by Owner: Either team or person, splits should be based on value delivery, not who owns the work.
• Spending Too Much Time Splitting: Splitting is important, but not at the expense of getting started on the work itself. Work with your team to understand what a good target user story size is and work toward that in your backlog refinement sessions — once you’ve achieved it, move on.

Measuring Average Story Size

A great way to gauge a team’s splitting efficiency over time is to measure the average user story size pulled into each sprint (and potentially plot it against story point delivery and completion percentage to verify it’s having the intended consequence). Try targeting an average story size of less than 3.0 — this can help teams focus on reducing the size of large user stories while refraining from micro-splitting all work to 1’s and 2’s when it may not be necessary.

Try these techniques out during your next Backlog Refinement or Sprint Planning ceremony and let me know what you think — I’d love to hear your experiences (good or bad)!