When grooming a Backlog Item, we frequently need to reduce the size and complexity of the BI in order to simplify it and make it more manageable during the Sprint. This is called “slicing the story.” Story slicing can be rather difficult to learn how to do. Essentially, when slicing a story, you need to focus on two things:

  • What’s the simplest thing the user could possibly do?
  • How can I cut across all layers of my application (UI, business logic, architecture, database)?

When you add these two together, we’re talking about slicing a story such that we create a number of stories that create a “backbone” capability that we can then enhance with additional stories. By cutting across all (or as many as possible) layers of the application as we can, our backbone stories help to ensure that the application feature is up and running and it reduces the likelihood of unwanted surprises later on. For example, let’s pretend we’re writing a story that allows a user to search for flights between two cities. What’s the simplest thing a user could possibly do?

Well, the simplest thing is to write a function that hard codes the origin and destination, searches only for one-way flights, doesn’t give you any choice with dates, seats, or times. Sounds ugly, but we’re not trying to satisfy the user with this story — we’re trying to create a backbone capability. When we build this story, we’ll build the user interface, the business logic that validates the user input, possibly the architecture as needed, and certainly our ability to access the database(s) that contain the flight information. Another advantage provided by this approach is that you’ll know in a few days if there are any significant obstacles that need to be addressed.

And this story may slice into smaller stories; so we’ll build the backbone capability in small pieces. But once that’s done, we can add some more stories, like these:

  • Allow the user to select the date and time of the flight.
  • Allow the user to specify the origin city.
  • Allow the user to specify the origin airport.
  • Allow the user to specify the destination city.
  • Allow the user to specify the destination airport.
  • Allow the user to search for return flights too (round trip).
  • Allow the user to select meal preference.
  • Allow the user to select seat preference.