Story / Epic cutting

Recently I came into a role where I need to act as a Product Owner as part of my Engineering Manager responsibilities. Therefore I put some of my learning efforts on product related topics. One learning out of this experiences I like to share now: it’s about story / epic cutting.

What is a story / epic?

A story is a package of work that generates some user value / business value. An epic is comparable with a big project, which contains several stories. Often an epic is a feature within a product.

Why do I need to cut?

I can think of several reasons why it’s important to cut an epic or story in smaller pieces. A few of them are:

• Splitting the work within a team (with smaller packages)
• Get better estimations (because smaller packages are more accurate to estimate)
• Track the progress of an epic / story (because we have several checkpoints how far the feature is developed e.g. 5 of 7 tasks / stories are done)
• Reduce risk because we think about the implementation during the cutting and can adjust the plan (work on the most uncertain topics first, to fail early)

How do I cut?

Everything we do should provider value! This is the basic idea behind my approach. A value could be:

• business value
• user value
• information value (reducing risk with learning critical things in the beginning)
• technical debt reduction (e.g. to increase development speed or quality)

One mistake I did, in the beginning, was to cut stories only on business value. The result were quite big stories. As soon as I started to appreciate information value as something important, it got a lot easier to cut stories into smaller pieces.

In this situation, a story could also be completely hidden in backend code. No visible user impact would be measurable because we just generated information value. But a story should always provide user or business value even if the main focus is to collect information. So one new constraint needed to be introduced:
The story need to have a visible impact.

In other words, each story needs to contain a section that answers the question: How to Demo a user that the story is finished.

Usually, a user is using the frontend to interact with our product. This indicates that you can only demo a story to a user on the frontend. No backend calls or green tests are allowed.

As I’m currently working in a real backend centric environment, it’s quite hard to come up with a demos on the frontend for each story. But in the end, our backend changes should also change something on the frontend. To workaround this issue I use a little trick: the first story or task is a HelloWorld ticket. Within this ticket, we are creating a dummy object of the feature we like to build. There is nothing dynamic. Everything we display is a hard coded mock. And this dummy is hidden on a feature switch. Within this HelloWorld ticket, we reduced the risk we could have with displaying this feature in the frontend.

On top of this HelloWorld, we can change piece by piece to use real data instead of the hard coded mock data. One story could be to implement the behavior of a link. In the dummy this link point to any random web page. After the implementation of the link, this link is pointing to a dynamical generated URL. Easy to demo: user can click the link and see the expected web page.

As soon as the HelloWorld ticket is created, it’s also super easy to come up with further stories because you just need to remove the mocked data. One after another.

What’s the benefit of this cutting technic?

It's two main advantages:

First: you can cut a story in smaller pieces, and you are still providing value. It’s most like not possible to roll this out to your users, but you are adding value with each ticket you close. And after the epic is done you can roll out to your users.

Second: acceptance criteria are super clear. As soon as you have defined the "how to demo“ section, everyone knows how this story should look like for the happy path. Depending on the edge cases it would make sense to list them in the ticket or split the edge case handling in several tickets to add one edge case with each ticket.