User story slicing is a key agile practice, yet many teams my colleagues and I work with struggle with it. The stories they create often are too complex, unclear or without a clear value attached to them.
There are many ways to deal with this situation: workshop, coaching, learn by trying or reading various materials on the topic. We know however that there are two best ways to learn such a technique: practice in the form of a “User Story Slicing Kata” and see examples from other people.
Not many examples of slicing exist, so I decided to detail one. I asked for the help of my colleague Claudia Rosu and we worked together on a scenario.
Disclaimer
Like any agile practice, story slicing depends a lot on context. Therefore, you should not take this example as being the best way for slicing the stories. This is merely one way, based on our current understanding of the problem and on how we imagine the context. Specifically, we will consider the scenario is built from scratch, in a small company where the Product Owner can make all the product decisions.
Why is this important? Since the user story is a communication tool that bridges various roles from the development team and the stakeholders, the stories can turn out to be very different in a corporate environment with 5 layers of management and 10 different stakeholders.
Therefore, we encourage you to repeat the exercise and tell us in the comments how were your stories different from ours.
The Scenario
The scenario we picked is extracted from meetup.com, the platform used to organize the agile meetups:
Organizer creates community -> Member joins community -> Organizer schedules meetup -> Member RSVPs to meetup
One thing that might strike you is that we decided to start with a scenario instead of a list of epics, like traditionally advised by Scrum books. The reason is that our experience and other people’s (such as David Hussman, Jeff Patton) shows that users want a complete scenario that works. User stories make sense when they group in a usable product increment; it’s harder to select such an increment from a long list of stories than by starting from the desired result (in this case, a meetup is organized and people attend). This technique is called “story mapping” and you can find out more about it in Jeff Patton’s blog post.
The second thing that’s interesting is that the scenario is vague. Details are missing. What type of community can one create? What details are necessary for a community? What details are important for a member? What types of RSVPs do we accept? Most developers hate this type of uncertainty. They sometimes tell us: “it’s the job of the product owner to give all the details”. That is true. It is however, the job of the agile developer to figure out what is known, what is not known and to separate the two. This is actually one of the user story slicing patterns: separate the known from the unknown.
We will assume that the organizer and the members already have user accounts on the platform. User management is a very common scenario in applications, so we think the value of slicing it is low.
We like this scenario because it’s realistic. Most of you will probably agree that rarely does the product owner come with a set of perfect, crystal-clear stories. Let’s see what resulted from our exercise.
The Stories
Here is the result:
1. Initial increment – Basic Meetup Organization
2. Second Increment: Find Meetup Groups by Name
3. Third increment: Find Meetup Group by City
How We Did It
We started the count down for 30 minutes.
We then discussed how to proceed: should we go in-depth on each step or should we focus on a complete scenario first? We decided on the second alternative. Both have advantages and disadvantages: going in-depth helps identifying more potential increments while going for a complete scenario allows finding out increments faster.
We quickly identified the first increment, without labelling it. To simplify, we decided to have zero communication between the system and the participants; all communication is the responsibility of the organizer. This allowed us to focus on the part we thought was most important: organizing the first meetup. In a real scenario, the priorities need to be discussed with the Product Owner. During our conversations, we realized we were confused about how the system will work, so we decided to draw UI mockups. They only took a few minutes and they helped us understand much more about the proposed solution. Again, in production, the mockups should be validated with the PO or provided by him.
We then discussed briefly what would be the next increment. Should the product grow with more fields related to the meetup group, or something else? Claudia proposed to continue with the “search meetup by partial name” feature, and I agreed it would make sense. In a production environment, I would ask the PO if it’s a good continuation. If the PO is not sure, we would define this increment and then decide its priority compared to the rest. It’s easy to move it up and down the priorities once you know what it’s supposed to do.
For the last increment, we realized it would be useful to find meetups by location. The best way would be to see all meetups in a radius of (for example) 10 kms from my location. However, this seems complicated. How about searching by city first? We decided that was good enough for now. The organizer will need to add a city to the meetup group and the participants should have the ability to search for a city. We decided to drop the UI mockups for this increment, since they seemed very clear to us.
We had only two minutes left and decided to label the increments.
Conclusion
We tried in this blog post to show an example of how to do user story slicing. We don’t mean that this is the perfect way of slicing stories, since this practice is very context-dependent. We encourage you to repeat the exercise in your teams and let us know in the comments how your results were different. We hope you draw your learnings from our experience and now you feel like you want to share your own experience in the comments below.
