Vertical Slicing - Tips and tricks for breaking up complex user stories

 Some (many) user stories just don’t fit neatly into a sprint, at least in a true state of done (tested, accepted, deployed, consumed).  Trying to provide true business value with each story while still meeting Definition of Done can be difficult to complete in a sprint when the feature has any complexity.  One of the most common is when a story is about adding or replicating chunks of a feature that don’t appear to be separable without losing business value.    I have often seen teams falling into the habit of breaking up user stories into technical components or separating testing from development across sprints because they are unable to complete the original story in one sprint.  The common fall back is to break a story up into database, coding, testing and analysis pieces, all meant to be worked on in different sprints.  This leads to many problems, such as fragmented development efforts, low quality, and inability to demo and deploy working software.

For example, let’s assume that the business value the team needs to deliver is resolving to the window shown being added to the application.  This is a simple window that provides a grid displaying customer data and a set of controls that either affect the displayed customer data or handle user requests (Save/Cancel).  Teams new to agile would look at this screen and deem that they need to complete all the operations in this window in one shot to add any value, which makes it too complex for a single sprint.  However, there are several techniques that can help to break this story down into manageable chunks.  

Spikes

Spikes are a type of user story that answers a question instead of adding direct business value.  For our example, one or more spikes may really help to reduce the complexity of the story by

•  Determining what data grid to use to best meet the user’s needs
• Solving a caching problem that the grid will need to operate correctly
• Doing A/B testing on best filters and control usage for the grid

Spikes still need to add value by answering a question, as well as needing to be testable and follow good acceptance criteria practices.

Vertical Slicing

This is a very powerful practice, but one that is not used as much as it should be as many teams do not understand how to break out individual user value.  Vertical slicing practices state that we try to find the smallest piece of user value in the parent story to break out into a child story.  (note: this also supports the concept of small batch sizes).  For example, if we were to just tackle the grid view first and do all work needed to display data (database, UI, middle tier, testing) we could demo that to the PO (and, potentially, beta testers) to obtain feedback.  Does this provide value to the business?  Yes, since now we can verify that this grid approach is the right approach and gain feedback as to columns, sorting request, display properties, etc.  All of these would be difficult to obtain without having a working application for stakeholders and users to provide feedback against.  The important point is, if we decided to release this as is we would be able to, as we have fully unit/system/integration tested this capability.

Mock Objects

Another way we can break this up and still provide value is to use mock objects to replace real functionality so that we can focus on one part of the screen at a time.  For example, what if we created a mock object for the database response and just stubbed out handlers for each of the radio buttons and check box.  The database object would return a sample dataset (without ever leaving the application module) for display in the grid.  With these stubs in place we could focus one sprint on completing the functionality of the grid, including full testing and acceptance.  How does this add business value?  By showing the PO what the data will look like in the grid and how it interacts with the other controls allows her/him to determine if this is the right approach.  Could this feature be deployed and released to a customer base? Under the right conditions, yes (beta testing, etc), however we are still providing business value by providing information to the PO to confirm or correct the direction.  After all, that’s one of the bedrock principles of agile practices, to quickly collect and react to feedback.

An additional benefit of using mock objects is testability.  These mock objects remain part of the code base and are used in automated testing to isolate the behavior of real world components.  What if we are having a display issue with the grid?  Using the mock object that is guaranteed to return the expected dataset will isolate the problem to either the grid or the database object.

Go from this

To this

Acceptance Criteria

One more tool used in slicing stories is to review the acceptance criteria.  First, make sure the acceptance criteria are in place and the team and PO agree that this is what done looks like.  Now, look at the AC’s.  If there are multiple, can one or more of the AC’s become a story by itself?  Can more complex AC’s be broken up into smaller context so that they can be done in a separate story?  Often times reviewing the AC’s for story slicing helps to improve the criteria for the feature in general.

Reducing Risk

We break down user stories for many reasons, but one of the important ones is to reduce the risk associated with the feature.  How do we know that what we are planning to build will meet customer needs?  How can we be certain that we are using the correct technology?  These and other similar issues are what creates the risk around each user story we are planning to implement.  Decomposing these risks into smaller ones reduces the overall risk on  an exponential scale. (Donald G. Reinertsen, "The Principles of Product Development Flow")

Bottom Line

The Bottom Line is this: the smaller the batch size, the faster the work flows through the process.  Don’t be afraid to be creative with how you slice stories; very often after slicing a story down and doing a few slices we find that we don’t actually need the other slices.  Think lean and doing only what is required to delight the customer.  Think about ways to deliver value in smaller increments, but remember to always provide value with each slice.