Agile story-mapping techniques can help project managers when they’re working on developing their product roadmap. In this training video, scrum master Devin Deen shows you how.
Here’s a shot of the whiteboard for your reference!
In Review: Story Mapping
Devin talked about the importance of effective story mapping, an Agile product development and planning technique used to break down top-level concepts in to individual product features and tasks. This process can also be applied in more traditional Waterfall projects, and in hybrid methodologies, as well.
The method of developing a user story incorporates strategic vision and end user goals through the accomplishing of individual tasks through sprints. It’s important to understand the framework of the whole user story for the product or the project at the outset of a project. This helps the project manager remain cognizant of the end user needs and maintain a certain amount of empathy for them, as well.
By starting at the high-level and breaking down your story map into smaller and smaller pieces, you develop a granular knowledge of the project and a deeper ability of how to manage and guide it through completion.
For another Agile training video with Devin, check out Building Your Project Backlog.
Thanks for watching!
Hi, thank you for joining me. I’m Devin, and today I’m going to talk about story mapping.
Now story mapping is an Agile technique that’s used in decomposing our top level vision down into the individual bits of sand that our sprint teams can actually work on. It’s also relevant to our traditional project management methodologies in terms of decomposing scope or features and functionality into small bits the project team can understand and then further decompose into the tasks needed to deliver on that functionality.
So let’s take an example together so that you can understand how this technique works. First off, it’s important to understand the framework of the whole user story. In an Agile approach, we talk about mountains, boulders, rocks, gravel, and sand. That aligns to our vision for our overall product. Where do we want to be at the end once the software has been developed, or the project’s delivered?
The themes involved in getting us to that vision further decompose into the smaller epics related to those themes, which then get broken down into individual user stories, which then can be assembled into the tasks by the sprint team based on how many points they think they can achieve in that particular sprint.
Now user stories are very important, and the method of developing a user story applies at every level of the Agile approach, from vision down to the individual sort of tasks in the sand phase here. How you break an item or a piece of functional code or what you want delivered into a user story is very simple to do.
Start out with defining who is going to be the actor or the user of that piece of functionality. What do they want out of it? And explain why. I use a statement like this. “As a . . .,” and then name the persona. “I want . . .,” and then define what you actually want, “so that I can do . . .” whatever it is that you want.
Let’s take an example that everyone is familiar with, which is leaving the house in the morning. Okay, so my high-level vision for leaving the house in the morning is as a commuting parent I want to be Zen when I get to work so that I can be proactive when I start my day. That’s my top-level vision. That’s what I want to achieve when I actually get to work, being Zen and then also because I’m a commuting parent.
Now the themes involved in that high level vision are commuting, parenting, community, and being an employee. So in those themes I can further break up those themes into leaving the house and driving to work. So as you can see, your boulders might relate to all these rocks here. One boulder and these rocks, and one rock will relate to the various bits of gravel which comprise these user stories.
As I’m leaving the house, let’s focus on this one. There’s a variety of user stories that comprise the types of things I want to achieve in that particular epic. So let’s say that as a commuting parent I want to have fresh breath so that I don’t deter my workmates when I get to work. I want to make sure I’m kind to animals if I have animals in the house, make sure my kids are ready to go and get to school, have their lunch for example, make sure the house is suitably tidy, tidy enough, and being informed on going to work.
So if I break these user stories into further user stories about these individual items, I might think about that as a dog, I want to be fed so that I’m not hungry during the day. Right? So put my dog and there’s a user story. What are the types of things, the tasks necessary, to make sure that my dog achieves that user story? I look at these different items and I figure out what are the highest priority items, right? And what are the ones I may not need to do.
So for example, just looking at these little individual user stories which will then go comprise the sprint that I need to do. Yeah, I could read my email, but it’s not really that relative. Sure, I could look at the news, but probably don’t need to look at the news as I’m leaving the house. Perhaps I can listen to the news on the radio on the way in. Lunch and breaky, feeding the animals . . . Look, maybe that’s things that I can delegate to the kids. Maybe they can participate as part of that sprint team in achieving the objective.
So let’s look at the whole epic of leaving the house. Breaking these different user stories into smaller tasks, I can then assemble my storyboard. And let’s say that this sprint is from 7:00 to 7:15 in the morning, so it’s a quarter of an hour. By the end of that quarter hour, I want to make sure that our animals are fed, the kids have been fed and have some lunch ready, and that I am aware of what the traffic is.
So user story one, for example, might be, as a group of animals, we want to be fed so that we don’t go hungry during the day. Okay. So that’s my animals. From those animals I can list out a whole bunch of different tasks required to be done. So they need to be fed. They need water. Probably a little bit of petting to make sure they are happy.
As kids being ready, there’s a couple of things that may need to happen. So breakfast needs to be made. Lunch can be done. And a variety of people can do these, so it just doesn’t have to be me as parent that makes their breakfast. They can make their own breakfast. And likewise if somebody has finished early eating their breakfast, they can get on to making lunches for themselves and their brother or sister.
The third thing that I want to focus on for this particular sprint is being informed. So as a commuter, of course I want to be informed so that I know which route to take to school or to work. So understanding traffic is something again that the whole team can do. Sure, I could look at the traffic website, or my kids who are taking devices to school now are probably better informed in figuring out what’s the best way to get to school. So as a team we can achieve these objectives.
And on your storyboard as you put in your to-do list as you complete those tasks you, of course, moved them into doing. Make sure they’ve been QA’d, and then lastly if they’re done, you check them off as done.
This is how you assemble a storyboard starting at the high-level vision and breaking it down into smaller and smaller chunks using our use case technique of stating, “As an actor, I want . . .” and then you talk about the feature that you want, “so that . . .” and you talk about your endgame.
So remember when story mapping, you want to keep breaking your user stories down from mountains into true grit.
Thank you for joining me. For more project management tips and techniques, come see us at ProjectManager.com.