1127131620a_1When they are initially developed, user stories tend to come in many shapes and sizes.  Some stories are too big to be completed in a single sprint.  In order to facilitate the effective and efficient delivery of value user stories need to be sized small enough for some number of stories to be delivered within a single sprint’s time box.  Getting stories small enough generally requires splitting larger stories into smaller stories.  As discussed in Splitting User Stories: Deciding When, the size and testability of a story are both critical indicators for deciding when to split stories.  After deciding that splitting a story makes sense, the ugly question of how to split a story raises its head.  There are several patterns that can be used as splitting strategies.  But, before we split any story, there is only one rule that must be followed: each story must deliver functionality that is potentially implementable.  Where needed, the story should describe functionality that cuts across a full architectural slice of the application.  Think of a thin slice of on an onion starting at the outer layer cutting to the core.  The thinner the slice, the smaller the story.  Immature Agile teams generally take a different approach, in which they split stories by architectural layer or deliverable: one story for the UI, another for the database, another for testing and perhaps a story for design documentation. Small, yes, but the result is not independent or functionally valuable.

Here are the patterns I use to split user stories:

  • Slicing workflows: Workflows can generally be broken into a number of separate valuable stories.  For instance, a time accounting workflow might include stories for data entry, data correction, review and approval.  Each story represents a complete functional transaction that would be potentially deployable.
  • Business rule variants:  Transactions can require different rules, different processing logic, depending on business needs.  For example from the time account example we have been using, the approval rules for an employee’s time will probably be different from the approval rules for a contractor.  The story for approving time could be split into one for employees and one for contractors.
  • Data variations: Data variations are similar to business rule variants noted above.  Data variations occur when when there are nuances in the groups of data needed to describe an object (for example retail customer and wholesale customer are similar but probably have some data differences).  Because the objects only have minor differences they can easlity be implemented incrementally therefore represent an opportunity for splitting stories.  Using the contractor / employee dichotomy started above, you can easily imagine that the user set up for an employee and contractor would include differences in data.
  • Data entry pattern: How the data enters the application represents another potential for splitting stories.  For example, splitting stories for time entry from an iPhone or a web interfaces would be an easy line to split stories (note that the difference in acceptance criteria would also suggest this as a split).

There are numerous patterns that can be used to help team identify how to split stories.  The goal is to help a team deliver effectively and efficiently.  Small stories flow through the development process easier.  If one gets stuck, it won’t gum up the whole process.  Getting stories done gets functionality to a point that it can be demonstrated and exercised by stakeholders so that the team gets feedback.  Feedback ensures that what gets delivered has the maximum value.