Editor's note: Welcome to .NETRocks Conversations, excerpts from the .NET Rocks! weekly Internet audio talk show. This month's excerpt is from show 750, with Steve Rogalsky, an agilist and team member at Protegra, a software development firm in Winnipeg, Canada. Carl and Richard chat with Steve about user story mapping, which, as Steve explains, helps with visualizing beyond a serial list of features into categories of features in a planned software product.
Carl Franklin: Hey, it's Carl and Richard and we're at Prairie DevCon. We're here with Steve Rogalsky. Hi, Steve.
Steve Rogalsky: Hello. How are you doing?
CF: Well, I was interested in your talk on user story mapping, so let's talk about that. I guess we should start with "what's the problem?"
SR: Most teams who are doing agile have a backlog of items, and it's long and linear and one dimensional. So when you try to look at that backlog and prioritize what's in there, figure out what's valuable to the user, which one should we do first, is that backlog complete, does it actually map out our solution, can we see our solution in there. You can't. That backlog is pretty frustrating.
CF: How does the user story mapping help to solve that?
SR: So many years ago, I won't say how many because I don't know, Jeff Patton and others started experimenting with different formats, basically turning it into two-dimensional backlogs. So now you can actually see based on the grouping that's on the second dimension the things people do in the application. So if you're talking about an email system, one of those dimensions would be compose email, read email, create a task, create an appointment, view your appointments, contacts, those kinds of things.
CF: So I'm imagining a two-dimensional graph, is that it?
SR: Basically a grid. With the things people do across the top, and then you take your backlog, your user stories, from top to bottom underneath each column of, so compose email…
CF: Got it.
SR: …your first user story is going to be, create the basic email with the two fields, and a subject, and a body, and a send button, really. Really the basics. Below that one is going to be the next priority, which might be adding HTML support, or RTF support, etc.
Richard Campbell: So is the idea here, because you've gone two-dimensional, that every sort of feature grouping gets some love?
SR: Yes. And especially the way you hear it, the way I've used it, and the way that it has been described to me, one of the successful patterns is you want to build across that first dimension of things people do with a very small slice all along. So you've got the basic compose email, the basic read email, the basic appointment, the basic calendar, the basic content.
RC: And the point being that sort of horizontal slice out of the grid gives it a sort of a full set, even if not every feature is implemented. You don't want to have this awesome compose email ability with 100 different features in it, but you can't read email.
SR: Correct.
RC: But these are still general categories.
SR: Yeah.
RC: I mean when you get down to user stories, it's actually what does it look like when I-the fact that there is a new button for a new mail and what comes up and what the lookup mechanisms look like for different users. I'm just thinking, I mean those get down to the discrete stories, discrete features.
SR: Correct. So that the columns across the top describe the categories of the things that people will do in the application.
RC: Right. Because a basic compose has relatively few features.
SR: That's right.
RC: But you can keep advancing it, and keep advancing, and keep advancing it. So there are many features in that category of composing mail.
SR: Correct. So many people talk about delivering the highest value thing first in an agile project. When you have a flat singular backlog, a single dimension-that is much harder to visualize. Well, what does that mean to deliver first? Now when you're delivering highest-value first, you're delivering across all those features one single or maybe two user story slices, which means now after you finished maybe an iteration or two, [you've delivered] your whole product at a basic level. With email, you could do that. For email, you've now validated your architecture because your messaging system works because you can send and receive. Your user has looked at everything and can test things end to end.
I've heard of enough stories of agile projects where people are doing it for the first time, and QA gets a piece, a user story that's finished. But let's say they get, like you said, the whole compose email first, all those user stories, they can prioritize email, they can do HTML support, they can do RTF, but they can't actually test that they can read the email.
RC: Right.
SR: So this is an approach that allows you to see those things and then prioritize them.
RC: Well, getting back to your point of what's the highest-priority item. Isn't the highest-priority item, at least in version 1.0, is one full horizontal slice?
SR: That's what the user story mapping asks you to consider.
RC: Right.
SR: And it doesn't force you to, but it gives you a visual picture of that, and it's a great practice.
RC: To create a value to that idea that until we've made it across this slice, we really haven't shipped sufficiently.
SR: That's right.
RC: One of the things I'm really thinking about is how I get a larger team in action on a project.
SR: Yes. So one of the common patterns that I've heard for larger teams is that you would not say one team does all the services, another team does all the databases or the UI.
RC: Right.
SR: But you say this team is going to do compose and read and search email, and this team is going to do the contacts because then there are [fewer] dependencies between teams.
RC: Right.
SR: There are still dependencies as far as what the look and feel looks like, and you have to manage that, but there are [fewer] dependencies as far as the code.
RC: Yeah. You still are going to want sort of an overarching plan for design.
SR: Yeah.
CF: So I'm sorry about this, but I'm still trying to-now I'm trying to figure out, OK, you've got one horizontal slice. What would another horizontal slice look like if all the columns are the same for that horizontal slice? Give me some ideas of what the row value…
SR: So again in compose email, if you look at all the user stories in that column, the first one is the basic email with a "to" button, you type in a new address, it doesn't go to the contacts at this point, you type in your own subject body, and you click the send button. So underneath you're going to do the same thing for creating a new appointment. It's where is the appointment, who are you inviting, and a message.
So now you have the basics of composing email and sending appointments, plus you're going to have, you need a read email and a calendar. But the very basics, the calendar might just be a list of appointments at this point. And now you're going to flesh out each one of those, so the second slice will be adding HTML support to the compose or read email, and you're going to add meeting room support to the appointments.
CF: And you want to make sure all those things in the columns work for each story in the rows.
SR: Yes, that's correct.
CF: Yeah. Well, it's a great visualization tool.
SR: Yeah. It's really fun to create your user story map because you can do it in probably, well, depending on the size of the project, between 10 minutes and half an hour. It's a collaborative approach that Jeff taught me when I took one of his workshops several years ago. It's using silent brainstorming and silent grouping, and it speeds it up. If you have an idea for a project, I can get the main map out of your head in at least in about half an hour or less that shows everything you expect it to do, and then you can scope it down right away, too.
So OK, here's all the categories we created, now we can't do all those in the first release because you don't have a million dollars to build it, so let's see what do you actually want on the first release, and then we can scope some of those major categories out. For example, our company built a payroll product. I don't know what the tax situation is in the US... but [in Canada] we have T4's that get printed off every year. One of the categories in the user story map for payroll would be creating T4's, but we scope that whole T4 out because we have to build the payroll system and be successful and deliver it before it's even important to do T4's. So we did T4's after and in time for the tax season.
RC: Right. Well, there's an interesting discussion there about how you prioritize each one of those feature sets.
SR: Right.
RC: And what different folks need. I think there's this great battle of-you said a very casual thing there, that you're going to get all of this information from the domain expert, but he doesn't know. He knows some things. But I struggle often with folks who, they know they want an application, but they don't necessarily know everything that is going to be in it. What are the features that will be important in compose?
CF: They won't find those things out until later in the process for some.
SR: For a user story map, I'm not talking the whole user story map. I'm talking about the first two rows, which is compose email, that level and above. There's a higher-level grouping for compose email as well, like manage email, which is compose, read, search, file. But I can get those first two rows out of your head just by asking you "what do you want the system to do?" What are people going to do in that system? Which is the phrasing that-Jeff may have changed it by now, but that's the phrase I wrote down when he taught it to me.
RC: And I guess that's what people understand, it's just the things they want to do.
SR: That's right.
RC: It's really more your job as an architect to sort of think about the broader picture around these things once you have the collection of things people want to do.
SR: Right. And then of course there's administration of that. So they're not going to think of, well, I need to administer the security. So there's probably going to be some columns that we'll add afterwards. But I can understand from you what you want the application to do.
RC: Right. Do you map in real time as these things are being gathered, or do you gather them all first and then...?
SR: So there's the first two rows of the map, you start with the second row, which is at the compose email or post recipe level. Basically it's silent brainstorming. I gave you 10 stickies or 20, you write them all down. If you have a team, there's probably three or four of you, you each write down all these different ideas, and then you compare them, you read them out loud, you get rid of duplicates. Then you do this silent grouping exercise, which is you've got all these stickies, or Post-it notes on your table, maybe 50 of them, maybe 20 depending on your project, and you just start moving things that are similar close to each other.
RC: Right.
SR: And things that are dissimilar, farther apart.
RC: Right.
SR: And it's only because it's faster. When you do prioritizing out loud, you have people hesitating. "Well, I think this should go there, but maybe not. I don't want to impose on your idea." When you do it silent, it's fast.
RC: I'm challenged at being silent.
There's much more! You can find the full interview at dotnetrocks.com/default.aspx?showNum=750.
Richard Campbell and Carl Franklin are the voices and brains behind .NET Rocks!. They interview experts to bring you insights into .NET technology and the state of software development.
- Email: Richard
- Website: http://www.dotnetrocks.com/
