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.

Shared understanding - Why we size work

I think one area I get the greatest satisfaction as an agile coach is when I see a team really start to understand why we size things (rather than traditional estimating) in agile environments.  When I see the “ah ha” moment and the light bulb goes on it’s always a huge step in both their team formation as well as their understanding of some of the advantages of agile principles and practices.  They really start to understand the agile principle of communication over process.

It’s the discussion that allows us to come to a common size that really counts, not so much the number that we arrive at.  It’s the shared understanding of the business need and, from a lean perspective, what is enough to satisfy the business need and what is overkill.  Sure, having each of these items slotted into like sized piles is helpful for sprint planning, release planning, etc, but to me they are almost side benefits, and not the core benefit.

My favorite example.  Our product owner has asked us to provide a way to get across a waterway.  As team members, you might initially vote this as a 40, believing that we need to build the Golden Gate Bridge over the bay in San Francisco.

But I may vote it as a 2, because I think all we need is a log over a creek.

After we discuss the real business need with our PO, we settle on an 8 since we form a shared idea of building a simple bridge that still meets the business need.   The discussion required to arrive at this number brought out what the business really valued (provide a way for foot traffic to cross the creek) and the constraints involved (make it simple, yet attractive)  We now have a good idea of what done looks like (able to walk across the creek) and how to test it (allow up to 10 people at a time on the bridge)

It’s the power of these discussions that really brings the team into a unified vision of what business problems we are trying to solve, and a shared understanding of how we might solve those problems.  These discussions are what allows us to become more effective and efficient at saying if meeting this business value is bigger than a breadbox.

The All Too Missed reason for Scrum Standups

There is a non-stop parade of blogs and other instructional material on stand-ups.  What makes them effective?  And what are they REALLY for anyway?

Why do we have stand-ups?

The real reason for the Scrum Stand-up is to re-plan for the next business day what we need to do to achieve our sprint goals.  We come together to find out how far we got since the last stand-up (but not a status update!), what we learned from doing those activities, and what our direction and plan should be until the next stand-up.

What I did, what I’m going to do…

The three guidelines of the stand-up (what I did yesterday, what I will do today, any impediments) are in place to help us get to the right information as to what to re-plan.  What I did yesterday is only important to the rest of the team so as to illustrate what is completed and no longer an issue for us to meet our sprint goals, and to provide anything learned from those activities to get closer to or better at attaining those goals.  That's why it's not important that I only got one thing done yesterday because I had a ton of meetings (that will come in the impediments part); from a "How did I help move the team toward its goals" perspective, this is unimportant.  The fact that I was able to get a new test harness in place or confirmed the accuracy of a business rule we are building will really help the team in its re-planning efforts.  Sharing progress simply so that the other team members know what I accomplished (status update) is wasteful of the full groups time, since the team should be able to see actual progress from sprint boards and the like.  "What I plan to do today" is stated to share with the team what I think my role is in meeting the teams goals (till the next standup) should be.  However, as we re-plan, the team may elect to change my intended direction based on other impediments or changed direction.

Remember this diagram from Scrum training?  The "24 Hours" loop is the point at which we assess what we have completed, and what we should do next to keep moving towards the sprint goal.  This is the opportunity to apply the knowledge gained from the “what I got done” part to help the “what I will do” part.

The Impediment Factor

So now let’s talk about impediments.  Why should everyone else on the scrum team care that I have 3 meetings taking up my time, or am struggling with rebuilding that test harness?  They care because we are all pushing towards the same goals, and need everybody effectively pushing in the same direction to attain those goals.  Perhaps someone else that has bandwidth can take one of those meetings so that I can focus on the test harness.  Perhaps someone else has more experience and can help me with it, but then needs to offload what they had planned to another team member.  Maybe that test harness is no longer high priority and should be returned to the backlog?  Sharing impediments in a standup is a way of saying “I have these issues, what should we as a team do about them?”  The re-planning comes in to help us shuffle priorities for each team member, and possibly even for the sprint goals.

Why do we re-plan every day?

From the Scrum Guide from Scrum.org

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

We just spent 24 hours working towards a goal, the knowledge we gained during that time should help us re-plan, right?  This is the learning part of the do/learn/plan cycle that we go through each day in our effort to inspect and adapt.  We don’t wait until the sprint demos or the retrospective to adjust our direction; we do this on a daily basis.  Addressing impediments, re-planning based on what we learned, and adjusting the tasks involved in reaching that goal are all part of this re-planning process.

It’s the evolution of the ceremony

Scrum, as per the Scrum Guide, is

·         Lightweight

·         Simple to understand

·         Difficult to master

Advancing the Standup along its intended course of improvement from just answering the three questions to an evolved re-planning session is part of that “Simple to understand, Difficult to master” evolution.

Spikes – The Value of Information Gathering

User Stories have become the defacto standard in agile development to convey business needs to agile development teams.  There are countless posts and informative books and articles on how to write great user stories, but the essential statement of what a user story encompasses is to provide a short snippet of information that stimulates a conversation about adding value to the product.  Good user stories employ other attributes, such as valid acceptance criteria and following guidelines such as INVEST (Independent – Negotiable – Valuable – Estimatable – Small – Testable).

However, there is another type of story that is very useful: the Spike story.  A spike story is essentially a learning opportunity that we have discovered and want to explore.  The main difference between a spike and a user story is that where a user story adds value, a spike story answers a question.  Spikes allow us to do valuable work without necessarily adding direct (immediate) value to the product.  Spikes give us the ability to do research and knowledge gathering while including the needed constraints that a story framework provides. 

When to use Spikes?

Spikes are very useful in situations like the following:

Scenario I:  A user story has a well-defined business value, but we are unsure how to approach it.  For example, the user story calls for a particular grid capability on the user screen, but the team is unsure what the best technology is to accomplish this, and the outcome will influence the product owners view of the feature.  The team can create a spike story to create a working prototype for the PO to review to help define the feature and its acceptance criteria.  We can provide knowledge to the PO to help her/him see what is possible in creating business value, to be able to answer questions like “Is it realistic to have acceptance criteria that requires the ability to mix different data elements? “

Scenario 2:  The story is too complex, and we can’t find a way to break it into smaller business value chunks.  Can we solve some of the technical issues behind the story to reduce the complexity?  Can we do research on possible solutions to help reduce some of the uncertainty?  Let’s take our grid example from above, but what if the complexity comes from unknowns on how the new grid will perform with the current database technology.  Perhaps we can do a Spike on how the grid can consume the data in a performant way?

Scenario 3:  What if the PO has specified some business value, but the team has no clear idea on how to implement it?  This is another good usage of a spike, and can use techniques like A/B testing or beta tester feedback loops to determine the best way to move forward.  The team can use information from the PO on the vision of the feature, and experiment with different options to help further define that vision.

Keep it focused on value

One caution on using spikes: do not abandon the guidelines and constraints we apply to user stories.   Just because we are gathering information does not mean we can toss out the focus on business value.  Make sure that spikes still have a good title and description that define the conversation to take place.  Ensure that you are using the proper voicing in the story so that you maintain focus on who will be helped by this information.  Hint: it is common and acceptable to use the PO or team as the role needing the information, but avoid a specific role on the team, such as developer.  The entire team should be able to consume and learn from the knowledge gained.  Above all, make sure that you define and agree upon what “done” looks like in the form of good acceptance criteria.

By Example

Going back to our grid example, let’s see what a spike story might look like. 

Business Value: Give the user the best experience when merging their media files in their library.

Spike Story: As a product owner I want to learn about different ways to allow the user to merge media files in their library.

Acceptance Criteria: Verify I can review 2-3 options for merging the data.  Ensure that I can accurately compare the pros and cons between the different options. 

Note that the acceptance criteria does not specify being able to actually merge the data, since we are not trying to solve the user story, only the spike.  The important part is that we provide the knowledge in a consumable format.

Quest for Knowledge

One of my favorite facets of agile development is the importance of acquiring knowledge, and applying it to reach our goals.  This is evident in the agreement with our stakeholders to invest in this knowledge acquisition.  Spikes are the contracts we use to justify these explorations and discoveries. 
Donald Reinertsen discussed in his excellent book "The Principles of Product Development Flow" the principle of buying information.  "Information reduces uncertainty.  When we reduce the uncertainty of an economic outcome, we create economic value."  Columbus and crew went looking for a short cut to Asian spices (perceived economic value), but came back with the (re)discovery of a new world (unexpected, but far greater economic benefit).  Sometimes those investments return value we never saw coming.

The advantages of One Week sprints

2 week sprints are boring.  Been there, done that.  So many teams starting out an agile project, especially in a team new to agile, select the default 2 week sprints without really knowing why.  Not that I’m against 2 week sprints, but the biggest part of selecting a sprint time box is knowing why you are selecting that, e.g. What is the value?  (BTW, I try at all costs to avoid 3, 4, 6 week sprints)

One of the big advantages of the practice of time boxing feature work (sprints) is to have a clear end point that is not very far out, so that we can see the finish line often (small batch sizes), and when we reach it determine if we are still going the right direction (inspect and adapt).   Determining what this end point should look like and how often we should inspect/adapt is a difficult skill to obtain.  We as humans are really, really bad at predicting the future, and the farther out we go the worse we get at it.  Especially for a team new to this practice.

My MO when coaching new agile teams is to encourage the team to start with one week sprints.  There is often a lot of concern and push back from this, with the usual arguments “we can’t get anything done in a week” or “it takes too long to deploy to do it once a week”.  The answer to those concerns is that if you can’t do this in one week you won’t be any better at in two weeks.  These objections are always symptoms of underlying problems, such as the deployment capability is not utilizing continuous delivery practices.  Getting a team to work in smaller time boxes will force them to learn to work in smaller increments, which is a core skill they need to obtain.  Learning how to break up a story into the smallest business value they can will strengthen the team’s ability to deploy business value more often, striving towards a daily (or more frequent) change to production. 

In doing initial training I have sometimes put teams in a one day sprint pattern.  Start the day out with deciding what we need to accomplish by COB that day, and set about doing it.  It becomes glaringly obvious where the issues are in the code base, deployment, and product vision/understanding as the team struggles to break down the features into something tangible and deployable in one day.  Sticking with this results in, at a minimum, a team that understands how granular we want to work, and usually provides a pretty good list of spikes to resolve to improve the deployment process.

My motto has long been: if you can’t succeed with one week sprints, you will be terrible at two week sprints.  The problem is, the larger the time box the more the weaknesses in the team and the process will be masked.  Agile is very much about constantly inspecting what we have done and adapting for what we still need to do.  The larger the time box the less agile we become.  Try to succeed with one week (or smaller!) sprints before moving on.   And, as always, if you want to change this practice make sure you understand what problem you are trying to solve by making the change.