SPIDR: 5 Ways to Split User Stories & Bring Any Story Down to Size.

In the next eight short minutes, I'm going to show you how you can split any user or job story you come across. Once you know the five approaches I'll share in this video, you'll know all you need to know to split stories. From there, you'll just get better with practice. A few years ago, I was creating the Better User Stories course. Because this course would cover everything someone needs to know to work effectively with stories. I knew it needed a module on splitting. To create that module, I printed out over a thousand user stories I'd collected over 15 years. For each story, I had the original story and the substories it had been split into. I taped each story onto a wall, grouping them based on how they'd been split. I was looking for the common approaches used in splitting all these stories. I went through a variety of groupings, trying to find the smallest set of approaches possible. I knew it would be easier to remember five splitting techniques rather than 20. The five I ended up with form the acronym SPIDER, S, P, I, D and R. So SPIDER without an E. Let's take a look at each technique in the SPIDER acronym and see how you can use it to split stories. The S stands for spike. A spike is an activity a team undertakes to learn more about some backlog items. Think of it as a research activity, but it may include prototyping or some experimental coding. During a spike, a team isn't trying to develop new functionality. Instead, they're developing new knowledge that will help them develop the functionality later. We're here on YouTube, so let's use YouTube as an example. Let's go back in time to when YouTube added automatic captioning. The team doing that might have faced a build versus buy decision. Do they use some commercially available software to generate the captions? Or are their needs so unique that they need to develop something from scratch? The way to settle that would be a spike to test out one or more commercially available captioning products. Extracting a spike makes the original story smaller because some or all of the research included in the original story is removed. This is absolutely an essential way to split stories, and so extracting a spike is one of the five splitting techniques you should use. But normally it won't be the first technique you'll reach for. Our second splitting technique is paths, which is the P in spider. To split a story by paths, look for alternate paths through the story. Sticking with YouTube, let's use this story. I can share a video with my friends when I click the share button in YouTube. Today, I'm shown four 14 buttons I can click to share directly to various social networks. I'm also shown a link I can copy, and I'm given the option to customize that link to start playback of the shared video at a specific time within the video. That's 16 different paths through the I can share a video story. I don't know that this story needs to be split into that many smaller sub stories. That's for the team to decide based on the effort involved. But with the path technique alone, we've identified 16 paths through the original story. The I in SPIDER is for interface, which refers to splitting a story by its interface. The most trivial example would be on a mobile app, you can split the story into an iOS and an Android version. In other cases, splitting by interface can be done by having a simple version of the interface and and a more involved version as separate stories. This usually applies to a user interface. Applying this to our YouTube video sharing example as an alternative to splitting the story by paths, we could have split out a basic sharing story like As a video viewer, I can get a URL I can share. This could be implemented with no user interface other than a share button on the video page. The popup with the 16 different ways of sharing with wouldn't be needed if the only way to share is with a URL. A subsequent story could then be As a viewer, I can share a video to various social media sites. This could be done with a very simple user interface at first, no fancy scrolling through a list of logos. Maybe just a dropdown list of text with the names of the social networks. The final story could then be something like As a viewer, I can choose the social network to share to by scrolling through a list showing the logos of each. Splitting by interface works because the ultimately desired feature can be built up to by progressively more detailed and better interfaces. Let's move on to the fourth of the five techniques you can use to split any user story, and that is splitting the story by data, which is the D in the spider acronym. To split a story by data, do an initial version of a story that processes only a subset of the data that will ultimately need to be supported. For example, YouTube allows you to upload a video in any of 16 different file formats. If we're building a YouTube competitor, screw 16 file formats. Let's start with one. We're going to support one type of data. All uploads need to be an MP4 format for now. We'll add all the other formats later as separate stories. Splitting by data is an effective approach Often there are a few types of data that add a lot of complexity. Well, do an initial implementation that ignores the more complex data, get that implementation working, then add support for the more complex data. You probably can't release the simpler version, but you can still build it in that order. I worked on a human resources system that did exactly this. The system tracked who the manager was for each employee and would do things like route time off requests to to that manager. Most employees have one manager, but some employees had multiple managers. We needed to support having multiple managers, but some stories were simplified initially by assuming each employee had exactly one manager. Let's take a look at Splitting Stories by rules, which is the R in our spider acronym. Splitting using this technique involves relaxing some of the rules that a story will ultimately need to support. Sticking with YouTube as an example, YouTube has some strict rules around including copyrighted music and videos. If we're building a competitor to YouTube, our team's first story will be I can upload a video so that others can watch it. That story probably sounds simple, but there's a lot to it. So in the first iteration, let's ignore the rule that videos can't contain copyrighted music. We're not announcing our new YouTube competitor to the world after only one iteration anyway. We'll have plenty of time after this first sprint to comply with our internal rule about not allowing videos with copyrighted music. As another YouTube related example, suppose we want to prevent certain text from appearing in comments that could be swearing or maybe SQL commands. That could be hacking attempts. Great idea. Let's protect our users and our system from this type of text and comments. But an initial story of As a user, I can enter a comment on a video can ignore that rule. Doing so makes the story smaller so that it can fit within an iteration, and support for the rule can be added a couple of iterations later. Getting good at splitting user and job stories is an important skill. With the short iterations used in Agile, it's helpful to have small units of work. The five techniques we've covered here, splitting by spikes, paths, interfaces, data, and rules should allow you to split any story in the comments. Let me know what challenges your team has faced with splitting stories and share any other techniques you use to split. If this video has been useful, click the like button and if you're new to the channel, click subscribe so you don't miss out on future tips to help you succeed with Agile. Thank you for watching and I'll see you next time.