Story splitting

Many Scrum Teams have difficulties with splitting user stories. They will often be convinced that it’s absolutely impossible to split this or that product backlog item. As a result, stories that are really oversized enter the sprint and often need to be carried over during multiple sprints because the team doesn’t manage to burn them down in a single iteration. To solve this issue, I‘ve compiled a number of best practices which will help with the story splitting.

The splitting conundrum

But first, let’s go back to the WHY of story splitting.

Why do story splitting?

The main reasons for story splitting could be summarized as follows:

1. Gain speed by thinking small: work through several small items instead of a single monolithic one. Each story – regardless of its size – should still be delivering business value. So many small stories will add up to a releasable feature, but each story should be releasable by itself. We will thereby be able to manage our sprint planning better with smaller stories while also generating a smoother burndown pattern. Yes, effective swarming on smaller stories is generally still possible.
2. Increase your overall sprint success rate by keeping sprint backlog items to a maximum size of roughly 1/5th to 1/6th of your team’s average velocity. Sticking to this size limit for individual stories will help you decrease the risk of getting stuck with “almost finished” stories by the end of the sprint. Your stakeholders will appreciate seeing some working software instead of hearing you almost made it but can’t show anything yet.
3. Increase estimation accuracy by going for smaller stories. As a rule, the smaller the stories are defined, the easier it will be for the team to evaluate the associated effort and risk and put an estimation on it.
4. Reduce risk. As already hinted above, the fact that we go from one monolithic item to multiple smaller ones is also a way to reduce the risk considerably. We want to fail faster on a small item and learn from it so that we can avoid making the same mistake with the other items. If we would only have a single big item, then failing to deliver it would most likely be a much more serious setback than having a failed small item, which may even have proven to be recoverable during the same iteration.
5. Improve the Product Owner’s planning options. By breaking down large items into smaller stories, the PO will also be able to determine better which parts should be prioritized (thinking of minimum viable product) and which parts are best kept for after an initial sprint review feedback round. So the PO gains some flexibility in the way he/she wishes to maximize the user value.

How NOT to do story splitting

Two obvious, yet completely incorrect, ways that teams tend to break down large features include:

• Functional decomposition
• Architectural components

Doing either means you are no longer delivering user value with the completion of each story. Rather, you are creating parts of a larger system that can’t provide value until these are combined with other functional pieces or architectural components. That’s in direct conflict with the agile vision of delivering user value in every iteration and you will have a hard time showing anything during sprint reviews. This, in turn, will lead to a lack of feedback to improve the product and in the end, your delivery will very likely have become very inflexible instead. Don’t do it.

Hint: ask yourself if your story definition is still clear on what user value will be delivered for which user type to determine whether you are splitting in the right way.

Strategies for effective story splitting

OK, so now we know why splitting big stories into smaller ones is preferable and what pitfalls to avoid, but how do we go about this then? Thankfully, the agile community has produced quite a bit of help on this subject. In fact, there’s a wide variety of patterns one can choose from to do story splitting.

Rather than duplicate all patterns here, I invite you to read this excellent article. You might also want to have a look at this cheat sheet.

Evaluating the split: what makes a high-value story?

It’s not enough to have this boatload of information on how to split stories. We also want some criteria to determine whether we’ve successfully created smaller stories for which the story definition is of high enough quality.

So, what are the characteristics of a good story? The acronym “INVEST” can help to remind you that good stories are:

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable

Independent

Stories are the easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order. We can’t always achieve this; once in a while we may say things like “3 points for the first report, then 1 point for each of the others.”

Negotiable … and Negotiated

A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the story may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories.

Valuable

A story needs to be valuable. We don’t care about the value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these should be framed in a way that makes the customer perceive them as important.

This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often are inclined to work on only one layer at a time (and get it “right”), but a full database layer (for example) has little value to the customer if there’s no presentation layer.

Estimable

A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we don’t understand. It is also a function of size: bigger stories are harder to estimate. Finally, it’s a function of the team: what’s easy to estimate will vary depending on the team’s experience.

That said, sometimes a team may have to split a story into a time-boxed “spike” or “POC story” that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.

Small

Good stories tend to be small. Stories typically represent at most a few person-days worth of work. Above this size, it seems to become too hard to know what’s in the story’s scope. Smaller stories tend to get more accurate estimates. Story descriptions can be small too. Remember, the details can be elaborated through conversations with the customer.

Testable

A good story is testable. Writing a story carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. “Testability” has always been a characteristic of good requirements: actually writing the tests early helps us know whether this goal is met.

If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing. A team can treat non-functional requirements (such as performance and usability) as things that need to be tested. Figuring out how to operationalize these tests will help the team learn the true needs.

For all these attributes, the feedback cycle of proposing, estimating, and implementing stories will help teach the team what it needs to know.

Happy splitting everyone!

Acknowledgements

The following authors all inspired this blog post:

Mark J. Balbes for the advantages of story splitting;

Christiaan Verwijs for his work on splitting patterns and the convenient cheat sheet;

Bill Wake for his work on the INVEST principle.