The Story Slicing Workshop

Together with my colleague Barry Heins we facilitated a workshop to carve up some large sized Product Backlog items into thinly sliced User Stories. A short, useful hour of learning and fun that resulted in some tasty carpaccio's!

Why Story Slicing?

We started the workshop by explaining why splitting user stories is important. The Elephant Carpaccio facilitation guide by Henrik Kniberg and Alistair Cockburn offered some inspiration. User stories should be vertical, testable, user-valuable and cut across multiple architectural layers. Story slicing is about making thinner stories (but still vertical). We divided the group in smaller teams and let them think of reasons why you should split stories. The result covered most of the reasons Henrik & Alistair brought up themselves:

• Learn faster
• Deliver more often
• Happier stakeholders
• More in-sync with other people & teams
• Better prioritisation's
• Better product earlier
• More business options
• Less risk (less time “underwater”)
• Sense of velocity
• Easier planning

What is the Workshop About?

The story slicing workshop is a session in which we explain what story slicing is and offer some inspiration on how to go about it. We took roughly ten minutes to explain that story slicing is the art of carving up Product Backlog Items into easy, bite-sized items and then asked the team what the advantage would be of applying it. After that we did a quick walkthrough of 10 ways to break up stories as mentioned in Christiaan Verwijs' blogpost "10 useful strategies for breaking down large User Stories (and a cheatsheet)". And finally, you guessed it, we asked the team to practise these strategies in small groups with actual Product Backlog Items.

What are the 10 Useful Strategies?

The 10 useful strategies for breaking down large User Stories are...

1. Breaking down by workflow steps. If user stories involve a workflow of some kind, the item can usually be broken up into individual steps.
2. Breaking down by business rules. User stories often involve a number of explicit or implicit business rules. By studying these business rules you might discover it's possible to break an item into smaller pieces of functionality.
3. Breaking down by happy/unhappy flow. Functionality often involves a happy flow and one or more unhappy flows. The happy flow describes how functionality behaves when everything goes well. If there are deviations, exceptions or other problems, unhappy flows are invoked.
4. Breaking down by input options / platform. Most web applications have to support various input options and/or platforms, like desktops, tablets, mobile phones or touch-screens. It may be beneficial to break down large items by their input options.
5. Breaking down by data types or parameters. Some user stories can be split based on the datatypes they return or the parameters they are supposed to handle.
6. Breaking down by operations. User stories often involve a number of default operations, such as Create, Read, Update or Deleted (commonly abbreviated as CRUD). By identifying the individual operations required for this functionality, you can possibly derive smaller bits of functionality.
7. Breaking down by test scenarios / test cases. This strategy is useful when it is hard to break down large user stories based on functionality alone. In that case, it helps to ask how a piece of functionality is going to be tested. Which scenarios have to be checked in order to know if the functionality works?
8. Breaking down by roles. User stories often involves a number of roles (or groups) that performs parts of that functionality. By considering the various roles that are involved, you can possibly break the functionality down in smaller bits of functionality.
9. Breaking down by 'optimise now' versus 'optimise later'. Often, user stories can be implemented in varying degrees of perfection and optimisation of the functionality described.
10. Breaking down by browser compatibility. In a variation of strategy #4, user stories for web-applications often need to work on a wide variety of browser platforms. Modern browsers tend to be more compliant to standards, and easier to develop for, while older browsers often require hacks and customisations to get everything to work properly. By considering the browser versions, you can possibly break down the work into smaller items.

Please read the original article by Christiaan Verwijs for the full context. It's definitely worth reading! The cheatsheet - visualised below and part of Christiaan Verwijs' article - is also a great companion during backlog refinement.

https://blog.agilistic.nl/10-useful-strategies-for-breaking-down-large-user-stories-and-a-cheatsheet/

What are the Sources?

Inspiration for the workshop was gathered from Christiaan Verwijs' blogpost "10 useful strategies for breaking down large User Stories (and a cheatsheet)". Also the Elephant Carpaccio facilitation guide by Henrik Kniberg and Alistair Cockburn offered some inspiration for discussion the "why" of story slicing.

Duration

+/- 1 hour

What Do You Need?

A team that understands the basics of Scrum. A few proper Product Backlog items preferably from the team's own Product Backlog. And... the Product Owner. The Product Owner wasn't present during this weeks session. However, she could have played an important role by explaining user stories and determining if they're still valuable after some slicing. 

The Result

The story slicing workshop was fun to do and the team gave us the feedback it provided extra insights and ideas on how to break down Product Backlog items. The duration of 1 hour was also a nice time-box. Short enough so it can be easily planned during the day, but long enough to have some good discussions.

If you've tried such a workshop yourself (or the entire Elephant Carpaccio workshop): feel free to share your experiences!