User story slicing is a practice undertaken by agile teams – more specifically those using an iterative and incremental development process.
In order to deliver useful/valuable stuff incrementally in short cycles (e.g. 2 weeks), it is necessary to narrow focus for both:
It is very easy to be drawn into developing solutions in large batches (i.e. only release once everything in scope is done) to cover all bases without considering which bases are most valuable and could be delivered in an incremental fashion. This technique helps you prevent that from happening.
Here are some steps you can apply to any story you want to bring into the delivery cycle to make sure you are setting it up for true iterative/incremental delivery:
Before even asking the question of whether the story will fit in the sprint, you must first make sure the story is defined in a way which makes it slice-able. If it’s not, your only option will be to break down (aka decompose) the implementation work of the story into a set of tasks, all of which we must completed. Decomposition of work is useful, but it is not slicing, and on its own will likely lead to stories spanning multiple sprints.
Decomposition leads to a Rubik’s Cube part, whereas slicing leads to a yummy slice of apple!
Slicing is about creating independently valuable options, and as a byproduct reducing the size and complexity of a story. This makes it easier to find opportunities for quickly achieving something useful and demonstrable to a customer, and deferring other options to consider at a later time.
A slice of apple gives me the value of an apple without needing an entire apple, or even half of an apple. The parts of a Rubik’s Cube are not useful on their own, and indeed a Rubik’s Cube is not useful until it has all of its parts. If it is missing just one part it is not “done” and cannot be used.
Any work item format which includes a human being and a capability will work fine for slicing, such as the Connextra template for user stories (job stories, hypotheses and JTBD are other examples):
As a [customer type] I want [some capability in this domain] So that [some benefit for having that capability]
In the fleet management domain, there might be a fleet manager who wants to be able to adjust the schedule of fleet vehicles she is managing. This is important to her because she is responsible for ensuring vehicles are utilised as optimally as possible, and has a KPI to this effect.