Quote card for Advice on How to Split Reporting User Stories.

Advice on How to Split Reporting User Stories

I've had a handful of emails lately about the difficulty of completing a complex reporting user story in a sprint.

These emails made the claim that perhaps reports were not something well suited for development with agile because some reports are complicated and take more than a sprint to develop.

I'd argue that the opposite is the case. When something will take a long time to develop, that's exactly when I want to use a process that forces me to get early and frequent feedback. This will counter many developers’ tendency (including my own) to retreat into a cave thinking we know what our users want. So in this blog post, I want to look at a few ways that a complicated reporting user story can be split. I think it's a useful example because its lessons can be applied to other types of agile work.

One way to split a complicated report is to completely finish the presentation of the report but to to bring in only a subset of its data sources. This resulting report at the end of this initial sprint will show useless data. But a report built in this way can be useful for gathering feedback on the presentation of the data.

In building a report this way, I'll often select one of the easiest data sources first. There is often a great deal of work just to make that happen independent of any source-specific complexities. So I'll save the complex data sources for second or third sprints once I know the report itself is working properly.

A second approach is the exact opposite: Bring in all data sources but prepare an incomplete report. Perhaps only summary values are shown. Or perhaps the itemized rows are displayed but they are not summarized and totaled (whichever is easier). Or perhaps they are shown in detail and total form but only in one way.

For example, suppose we are creating a report showing information on revenue earned at a movie theater. In the initial sprint, the report may show it split and totaled by movie title. But it may not yet show the detailed by day of week or by the start times each day.

Each of these approaches works because it is true to goal of being done with something at the end of the iteration. The entire user story is not done. (We are assuming this report is too big to be completed in a single iteration.) Yet, even when the full story cannot be delivered, the team delivers some portion of it to a fully working state. They do not content themselves with delivering a full but untested version.

Instead, they deliver a version that works but uses data from only one source. Or that works fully but only fills in one portion of the eventually complete report.

And this is how successful agile teams approach all of the work, not just reporting user stories. Each iteration, the team fully develops some portion of the user story.

Explore Further

200 User Story Examples
Download

200 User Story Examples

Featured

Explore more than 200 user stories from three real product backlogs Mike Cohn created, and use them as practical examples for your own team. See user stories Mike Cohn wrote as part of several real product backlogs.

People collaborating during a Mastering User Stories workshop.
Workshop

Mastering User Stories

Featured

A one-day course where your team improves real backlog items while learning how to write, split, and refine better stories.

Guide

Story Splitting

Featured

Every team has had this sprint review. The team worked hard.

Article artwork for How to Work with Complex User Stories That Cannot Be Split.
Article

How to Work with Complex User Stories That Cannot Be Split

Here’s what to do when facing a complex user story that cannot be split but is too large for one sprint.

A Scrum team sits together, talking, in the background. In front are three calendar pages with key Scrum events circled. The text says Succeeding with Scrum is easier when you know when and why to conduct each meetings.
Article

What Happens When During a Sprint

Succeeding with Scrum is easier when you know when and why to conduct each of the Scrum events during the sprint.

Video

How to Split Any User Story with SPIDR

Need to split a user story that’s too big for a sprint? In this video, Mike Cohn explains SPIDR, a simple and memorable method for splitting user stories into smaller, more manageable pieces of work. SPIDR gives agile teams five practical ways to split large stories, epics, and features so they are easier to estimate, discuss, and deliver.