Story Splitting in Agile: Practice Makes Perfect?

MakeFrom Ron Jeffries' 3C to Mike Cohn's SPIDR, through Bill Wake's INVEST, there are many approaches to story splitting. They can also be complementary.

The technique used in this article is a combination of these approaches, but mostly an outcome of the discussions people looking to split stories had. From a high point of view, we can consider that "P" (Paths) from Mike Cohn's SPIDR, INVEST and user PoV story mapping were used.

What is story splitting?

Before diving into splitting, the team had its training on agility (and agile projects*) but rarely had the opportunity to delve into story splitting because traditionally, it received only the tasks to be done.

(*I am not fond of projects in agile; however, many organizations still do this, so I had to adapt.)

In a slightly more agile context in which their participation in the preparation of the work to be done is more consistent, having to split the stories was a novelty. And as Mike Cohn mentions in many of his articles, splitting is difficult but is mastered by practice over time.

In my approach to enable story splitting within teams, I always show them these two videos, which are short and simple to understand. I recommand you to watch them, too. Many thanks to Mark Shead (the author) for these!

Agile User Story:

Splitting User Stories - Agile practices:

The workshop I did is completed with Bill Wake's approach (INVEST) and Mike Cohn's (SPIDR). I also take the time to discuss Acceptance Criteria. (I cannot stand the term Success Criteria as we are not playing lottery.)

A quick presentation on story mapping is also done to help illustrate the logic behind epics, features, stories, and tasks. 

Story splitting, the example

In the example I am going to use, the team sought to identify the different stories that make up the need it had to fulfill: to allow the sending of an e-mail.

Of course this epic breaks down into several features (the order does not matter):

Feature 1: enable reading of e-mails already present in electronic document management system

Feature 2: enable editing of fields in the emails

Feature 3: enable sending e-mail

Feature 4: enable displaying the information of emails that already exist

Feature 5: show the list of already existing emails

During the discussion, we kept the user's point of view in mind. That is to say that, we were interested in the path the user takes to his sending her email, all while keeping an eye on the tasks that would be done in the background, which the user would never see. Then, the following statements were listed:

• Features 3 and 4 break down into several steps and screens, for which different actions and buttons will have to be made.

• A second team will give templates to the main team so that the epic can be completed. Templates can be delivered by lots. However, one in particular is needed at a critical moment.

• Finally, not all features are required at the same time; a particular order of completion can be established. 

With that in mind, we managed to visualize our epic as follows (yes... it is in french :) ):

and its feature splitting view:

We therefore understand that from a screen (screen 1), some action buttons must be implemented to allow the features to exist. For feature 3, this requires the creation of another screen (screen B) in which new actions are possible and where the addition of a button for writing the email is necessary.

This step causes the user (after having chosen a template predefined in screen B) to be able to edit the body of text. At this time, another button must be created that will both send the email and save it in the electronic management system for traceability purposes.

Although not illustrated, there are operating conditions. For example, if the email does not register, it cannot be sent.

Feature 4 must bring up a new screen (screen A) in which we can see different information about the emails and then allow the user to download the e-mail so he can read it on his computer.

Once these features are defined and pre-split, it is important to prioritize the parts. For instance, if we want to view the emails that are stored in the very first screen, we must ensure that they are registered first. So, feature 3 becomes the critical path. Feature 5 follows, then 2, 1 and finally 4. Of course all of this was discussed with the Product Owner.

We then need to identify the stories that constitute these features. It is not mandatory to have multiple stories for a same feature; one story can be enough. So, in our example, the team managed to identify 11 stories, as follows:

It is important to identify the stories that are prerequisite for others (like our first one "F3-R1" and then "F3-R2", "F3-R5" and "F4-R10"). We have to eliminate dependancies as much as we can, but in some cases, like here, some technical considerations may force us to respect an order.

In reality, theses stories are written in the traditional form:

"As a... I want... Because...".

Here, for the purpose of simplification, I kept a very high level of detail. However, understand that at this stage of splitting, we are not yet speaking about tasks or the "how," which happens in the next step.

But before that, we still need to ask ourselves:

• Do we have all the information needed to confirm this splitting?

• Can each story be tested independently?

Answering these questions brought the team to the following conclusion: Some stories need to be tested together, and it is likely that some "refactoring" will need to be done. So, there are still gray areas, but that's normal.

In orange, we can see the stories that need to be tested together.

Side note: We need to take a quick detour concerning the estimation of these stories. While I am not a big fan of estimations, they can give a team some confidence in the work ahead. You can see the famous T-Shirt size "S", "M" and "C".

This team does not use points and prefers speaking in terms of range. However, as they are new to this practice, they still need to consider "pd, or person day." So, an "S" is considered as between 0 and 3 pd.

In our case, previous work with another project had already affected some features, so there were only a few adjustments left to make.

We will talk about those estimations later.

The last step in our splitting discussion concerns tasks that make up each story. As the team only follows stories on its physical board, you can see here the splitting you would see in a "Preparation Done" column.

However, tasks for these stories will be seen in the digital tool (JIRA), which will allow a more detailed monitoring.

The division of these stories into tasks (the ones that are deemed "ready") was done at another meeting. So, during this second meeting, the "ready" stories are split into tasks as are the acceptance criteria needed for each one -- yes, acceptance criteria stay with the stories.

Stories then gain a "ready to engage" status, and the team can pull them when they have the availability to do so. 

And after the splitting?

Most (if not all) projects must have some form of predictability. In our case, these stories constitute the product backlog and the corresponding estimates give a idea of the investment required to complete this project.* 

*Again, not a fan of projects in agile, but what can you do?

As this team was working with Kanban and with sufficient data to establish a sense of predictability, they were able to provide the Project Manager with a probable window of delivery -- despite having to handle other requests and projects entering their pipeline --thanks to Monte-Carlo simulations. Finally, a delivery plan!

After having participated in the splitting, I now had an engaged team -- yes, really, no BS -- and a Project Manager somewhat at ease because he had the necessary data to support his acountability and feed the organization's indicators. We then needed to do a dashboard with progress indicators showing the investment consumption, the work done and in progress.

Wait, there's more!

When the team gave me feedback on this workshop, they appreciated the fact that they had a say in the work to be done instead of just being handed some nonsense work.

However, this wasn't the only feedback: After many weeks, the project hit a few speed bumps; even though the team was able to identify gray areas that needed research spikes, no one was brave enough to say to the Project Manager, "No, we cannot start these stories; they are not ready enough."

The problem they then encountered was stories blocked for weeks as they waited for business answers regarding the solution they could implement, unnecessary pressure from management to finish a job they couldn't, and a need to go back to the board for some major part of the splitting they did.

Yet, they also all acknowledged that their story splitting learning was tremendous, and from the lessons learned, they now have a better sense of how to better split this project and ones like it in the future.

Further reading

In Sprint Planning, How Do You Prioritize the Requirements in the Backlog?