Agile Resolutions 2: Cut Epics into Smaller Slices, Grasshopper

Not long ago, I was placed on a handful of engagements with a rough start, in part because I was working with teams that were struggling with getting stories done. The root cause of this struggle was that team members were being pulled off the team at random to do “quick” side tasks. On further investigation, it was revealed that another cause underpinning why these teams weren’t getting enough stories to Done was that some of the stories required multiple sprints to complete. Together, team randomization and epic stories were a brutal combination. I figured I’d offer a new goal for those who may be having a similar struggle.

What’s Wrong With Epics?

Nothing specifically. Epic stories are not bad, in and of themselves; they can even be useful in project planning. However on the sprint level, they just don’t belong. Estimating the size of epic stories is difficult because they generally come with more unknowns as well as vague/fuzzy requirements and assumptions, which greatly increase risk and exposure. Couple that with the fact that people are notoriously bad at estimating, and your Cone of Uncertainty starts to grow quickly. Epic stories tend to end up spanning multiple sprints because the unknowns explode and/or there is just too much work to finish in one sprint. Whenever stories start spanning sprints, you begin to question how you can reliably account for velocity and in which sprint it falls. The latter may seem like small fries, but without a clear discussion of what should be done by when, you’re back in the kind of uncertain territory that made your organization explore Agile work practices in the first place. Visibility into the work remaining for epic stories is also difficult to maintain, unknowns become knowns and take on a life of their own, difficult work drags on, etc.

In my perfect world, epic stories wouldn’t be admitted into the Sprint Backlog. Each epic should be broken down into smaller functional slices, stories that the team can consume to create customer value. The Product Owner has the onus of slicing the work up, so I offer here a possibility.

Sashimi Me

To slice epic stories into smaller Sashimi Mefunctional slices, I recommend the sashimi method. Sashimi slices are small and complete vertical slices through an application. Delivering small complete slices of full functionality allows time for feedback, increased visibility and better work/time estimation. Slicing epic stories in this way can take some practice, but it’s well worth the time and energy to get good at doing.

But how? you ask.

As long as a story can be finished in about half a sprint and can be estimated with confidence, I consider it the right size (i.e., sashimi-sized, a size the team can consume in a sprint). Half a sprint tends to give enough leeway to make bad estimations even out within a sprint. I have also been on teams where stories could be no larger than some metric. For example, one team may decide that a sprint-ready story cannot exceed 8 on the modified Fibonacci scale, while another team may decide that 20 is the number not to exceed. The scale and range are determined by the team: one team’s 8 may be another team’s 20. The numbers are guestimates anyway, serving to provide teams some language about how much work they can complete in a sprint. If, for example, the estimates are often off and the team is generally over or under the total work load they commit to, a coach like myself might recommend rejiggering the numbers or working with the team to achieve their goals. In the end it’s about breaking functionality down to sufficient stories about which the team can say with reasonable confidence, based on experience, what needs to be done and about how long it will take, while delaying most of the design until the actual code is written. You know your sizes are right when the time the team spends meeting and talking about the story is minimized (i.e., doesn’t end up eating up precious hours that could be spent delivering value).

What Now?

About now you might be asking yourself, “How does this discussion help with the team getting work done and not getting distracted?” It’s a funny thing, human nature: when teams work on epic stories that seem to go on forever, they find ways to get distracted. They will do side work, help others with something more shiny and even “gold plate” certain features that are fine as is. A lot of different things can go on between story start and story completion, thus the helpfulness of keeping stories small and increasing visibility. Distractions still happen, but with smaller stories teams are much more inclined to create new stories and document them, because they have seen stories of similar size and completed them. When faced with one huge task with countless unknowns and fuzzy requirements, teams and the members on them tend to think to themselves, “That’s gonna take forever to finish. But I can just slip this one small side project in, and no one’s the wiser.” Then you have a vicious cycle on your hands again, where stories get bigger and bigger (or rather never get cut down to size) and team members are sent looking for more engaging, smaller projects that give them a sense of providing real value and more immediate fulfillment. By breaking epics into sashimi slices, you break that vicious cycle and give teams an avenue to produce small increments of value quickly and frequently.

Raise Your Chopsticks!

In general it is a good idea to keep stories small. Delivering functional vertical slices of functionality allows for feedback, visibility and a sense of accomplishment. Shorter stories also give the flexibility to bring in higher priority work without sacrificing the integrity of other accepted stories. Establishing this good practice can take a little work, but it’s well worth it in the long run.

On engagements like those described above, I work with teams to start breaking epics into smaller stories of no more than half a sprint in estimated time to complete. As a result of implementing this approach and structure, I noticed after a while that the teams were randomized less and started meeting sprint commitments.

Suddenly sushi sounds real good…