This is the piece of the puzzle I couldn’t figure out by myself. I needed to see it in action, implemented well, to understand what I was missing.

I’ve seen a lot of stories sliced wrong, and some sliced well. Slicing stories properly can be the difference between a high performance team, and one floundering.

A story – a task or ticket – is a slice of work that is defined by a product owner. It is supposed to provide business value. These stories are collected on the SCRUM board – a version of a Kanban board. Developers pick up stories and work through them.

There is a lot of material to be found online about how to write a SCRUM story, so I will not go into too much depth here. The purpose of this post is to provide an overview, and focus on what I’ve found to be most effective.

The Anatomy of a Story

We call them “stories,” and you “play” them… Wouldn’t you rather play a story, than close a ticket?

A good story has (at least) three main parts: Context, Goal, and Acceptance Criteria.

The Context

The context gives context to the story. Any background information, why this is important for the business, does anything hinge on the completion of this.

The Goal

This is what you are trying to achieve with the story. I like using the MadLibs version: “As A [noun] I Want [action/feature] So That [some business outcome].”

I find that writing this helps me clarify and communicate the goal of the story and the acceptance criteria.

Acceptance Criteria

This is a checklist of the features needed. When the Product Owner or a peer is reviewing the story they can go down this list and see that the story was accomplished to its completion.

Slicing Stories

You can have a collection of stories, they all have the same pieces, outlined above, but some are clearly better than others. So what’s the difference?

How they are sliced, or broken down.

You wouldn’t have a story requesting to “build the entire app.” That’s ridiculous, but you also wouldn’t have a ten stories each to add another bullet point to a list.

Go Atomic

What I found has the greatest impact on the performance of the teams I was working with are stories that are small enough that if you sliced it any smaller, it would no longer provide business value.

What this accomplishes is twofold:

1. The Project Owner is forced to define specifically what needs to be done.
2. Developers can focus on specific tasks, and not have distractions around vague goals, that need to be re-worked constantly.

What it comes down to is, without proper planning, your development team will waste time figuring out what has to get done, when they should be focusing on getting it done.

Spikes

“But how does the PO know how to get it done?”

That’s where “spikes” come in. A spike is a story where a developer is assigned the task of figuring out how to accomplish something.

This is NOT production ready code. It’s just the narrowest path of what success looks like.

Think MVP. If you wen’t live with this story as-is, imagine to yourself W declaring “mission accomplished.”

The next step is to take the outcome of their solution and slice it out into stories, taking everything you need into account to make something “production ready” — tests, performance, security, maintainability, architecture.

Sprint Curation

This is different from Sprint Planning. Sprint Planning is when the Project Owner gets together with the rest of the team and they select what they will accomplish over the next sprint. It often includes reviewing and pointing stories.

Sprint Curation is the step before that. It involves pairing a developer with the Project Owner to review the stories the Project Owner has already sliced out, and making sure that they make sense from a developer’s perspective.

Depending on the workload of the Project Owner, and their understanding of the technology, this can be done as often as daily, or just once a sprint.

You might think it’s the Project Owner’s job to do this, but without a proper bridge to the development team, their stories will leave the developers floundering.

Planning

There are many things that the more you invest in them, the more you get out of them. Story planning is one of those things.

The more clear and concise your stories, the more your team will be able to focus on playing the stories, the more they will get done.