A couple weeks ago we were lucky enough to have the incredible Joel Tosi here delivering training on agile project design. I’ve known Joel for a long time. He’s one my go to guys when struggling on process related issues or if I just want to make fun of Sharepoint. Joel does a lot of work with David Hussman, aka The Agile Dude, through DevJam. I have high regard for David and his approach to software development. It was through he and Jeff Patton I first heard about Story Mapping. That was 2008. Unfortunately I don’t see very much of it these days. I was attempting to use it on a recent project and realized I could use a refresher on the technique, so we at Tandem offered to host DevJam’s Agile Project Design course with Joel as the instructor.
It’s very hard for me to cover two days of rich training into a post you’ll consume in five minutes, but I’d like to recap some of the insights from each section of the training course.
Narrowing
The above picture roughly represents the outline for the course. There’s more to it, but this picture gives us context for this post.
What you have on the left are all product ideas. The destination is your product. The intent of this process is to narrow the focus of your idea into something that’s producible. It’s important to keep these steps in order. Why before who. What after who. How after what. How becomes less complicated when you firmly understand what because you know which corners to cut. Also important is how to back up. If you’re questioning what, rewind to who before you blow it all the way back to why.
Chartering
This ain’t your enterprise architect’s project charter. This is the charter for a fictitious airline industry that we used for all of our group examples. There are only a few important components of a charter, but it’s important to get it right.
Why?
The primary question a charter addresses is why. Why are we about to embark on this project? What are the reasons we’re going to continue spending time to solve this problem? What’s the pitch? It’s important to remember this because if we at any point have to pivot and ask our way back up the order of this process and the charter doesn’t address why, you’re screwed.
Before you know what you’re doing, you should know why you’re doing it.
Goals and success measures.
It’s far too common to see success goals based on glamorous statistics. We get 1,000 subscribers. We get 200 repeat customers. We get an offer from Facebook to be acquired for $16b. While these may ultimately be measures of success they are not something you can control. Keep your goals something you have control over. In this example, we have “Easy to book trip” as the goal, with “new trip in five clicks, repeat trip in two” as the success measure. That’s something we can work towards.
Through this amazing experience we hope to get 100,000 subscribers and a buyout offer for $25b but that’s not the goal. It’s the effect of reaching your goal.
Don’t make vanity metrics your goal! Regardless of what your CFO says.
When and team
A charter should also mention a timeframe for achieving these goals, as well as who’s on the team. This is pretty straightforward but worth a mention.
Personas
Personas are so fun aren’t they? Oh boy! Let’s invent all these personalities! We’ll draw sick figures or Google search for a sweet image. Draft all these imaginary traits. Don them with an alliterative name. Donny the dork. Peggy the propeller head. Oh and since we want a very wide user base let’s create a whole bunch of them.
Stop it! You’ve gone to far!!!
Don’t fall into the gimmicky trap of personas. Keep them simple. Remember their purpose. Don’t let them become the enigmatic “they” of the project. You know. “The business”. Be cautious to ensure they’re not based on the actual Carol from accounting or someone on the team as well. There are a lot of smells that come about from the misuse of personas. If it feels wrong it probably is. But they’re still incredibly valuable, and here’s why.
Who?
The value add of a persona is to narrow the focus of who you are building your app for. We’ve already established why in the charter, now we need to a vehicle to drive discussion around who we are targeting. But they’re no more than that. A vehicle for discussion. Use your persona to determine what value you are delivering to this person. Why would they use this product? What value they are getting. How does it make their life easier? Is there a financial benefit?
What I really took away from the training was how to best leverage personas. That would be when you’re struggling with what to build when story writing, you may need to return to your personas to remind yourself who you’re building this for. So it’s best to just create a few and move on. Don’t over think this step.
How many?
If you’re building your application for everybody, you’re building it for nobody. Focus on 2-3 personas. Four raises an eyebrow. Five should scare you back to chartering.
Story Mapping
Ah, the bread and butter. Story mapping. There’s so much to say I won’t attempt to explain them here. For that, go to the source. But I want to touch on why they’re important and some of my takeaways from the training.
What?
Let’s look at a traditional kanban board:
What you see are a bunch of unrelated things to do. There’s no telling how Task X relates to Task B, let alone how it connects to what your persona is attempting to accomplish. I’m not saying this board isn’t valuable, but it’s limited in that it only accounts for the tasks of the week. The context of how they are related has been lost. At one point it was in somebody’s head, then it got split up and dumped into “Iteration 12”. We’ve lost the user journey.
Story maps on the other hand look like this:
What you have here are stories organized by goal, with the tasks to accomplish that goal laid out horizontally. The depth of a single column indicates derivations on that step. For instance, a step may be different if you are logged in or not and you want to capture that. Here you can go deep to show there’s more than one way to do that task.
Go Wide.
Depth can be a big problem. It’s incredibly important to ensure you don’t spend too much of your time in a single column. You want to get wide. Joel was very careful to express this, but it’s easy to see how someone would crave tackling the complexity of deep column. That doesn’t help you move forward (to the right).
The depth will come. Focus your attention on getting through one path end to end.
Slicing
Now that we have a map of what, organized by who, derived of why, the only thing left is how. When is now and where doesn’t matter. But how are we going to get started. This is where the planning is fundamentally different. Let’s not think about traditional estimates but rather, what is the ideal path through this map? That’s all part of slicing a journey from the map. It starts at step 1 and ends with user satisfaction. You can go deep if the cost is worth it for the first slice. You can also skip entire tasks if they aren’t fully necessary, but it ends with the goal being achieved.
Let’s cut a slice
Here’s the story map my group worked on. Keep in mind this was a training example we spent 15 minutes on. It is a bad product. Choosing a bad product made the training more valuable because it brought up a lot of tough discussion.
We had two different personas. One was an individual flyer booking for themselves. The other was Ali, an admin who books travel for people within the company. The goal “book flight for registered flyers” is a goal for Ali.
We used the advanced technology of colored markers to define our slices. The first slice is denoted by a red X. It starts with select flyers, skips narrowing by group, and ends with confirm. The second slice is marked in blue, where we start with booking a group of fliers for an event. Because the event has a date and destination we skip straight to review search results. It’s interesting to note that review search results is still in the slice even though it should already be implemented. We’re not talking about work. We’re talking about the journey. We can’t leave it out. Time estimates or how it breaks down into developer tasks are not yet a factor.
What about our first persona? Where does she fit in? Not under this goal. She doesn’t book flights for registered fliers, but she will still need the functionality of entering dates/destinations in the context of her experience. Those may or may not use the same interface, but that also doesn’t matter yet. It’s not necessary to get into that detail. Just duplicate those steps over there. It’s also possible to use more technology like a green marker or even a sticker on the card to denote it’s described elsewhere.
Testing
Once you have a slice, how do you know you’re right? Have you challenged yourself as to whether or not it actually meets their criteria? Have you challenged the negative scenarios? In our testing of the “book by event ” slice, we started asking, what if one of the flyers wasn’t registered in the flight system? We realized we needed to detour to the “Add a flyer” goal before we could head back to viewing search results. Then we thought what if there were no destination? Add the destination? Now how is selecting an event helpful if you’ll have to augment it so heavily. So we did what helps in every situation. We talked about it.
We determined that select event was dependent on defining exactly where this list of events came from. We just threw it in there in the mapping session, prior to slicing. So we were able to say this is what we want, consider where it fits in a journey, then we discovered we had never talked about what getting events into the system looks like. So what we needed to do was rewind to how, meaning we have a dependent goal of populating events in the system. This takes us back to what that looks like. Is it push? Is it pull? Well who’s going to be doing this? We only have two flyer personas. Maybe we need to rewind to who and create a persona for the person taking care of these back end tasks. It’s not fully necessary but if it helps, it might not be bad.
I feel testing to be the hardest to summarize because it’s really all about the discussion that arises when challenging the map. Our group included the awesome Angelique Rickoff and this matter of dealing with incomplete events drove a really solid discussion in which no kittens were killed. But it’s easy to see attachment to a journey let emotions fly. The map is the only thing being judged here. Remember that people. Stay objective.
Tools
Some quotes from the crowd:
- Don’t you dare put that into a wiki.
- JIRA/Version One/Rally are where stories go to die.
I don’t mean to pick on these products. It’s mostly the way people use them. But they sure are ripe for misuse. Maybe they target too many personas?
Be very cautious of the tools you choose. Start with none. Especially if all this is new to you and things are changing. One of two things will happen. You’ll be bending the tools to accommodate your process or much worse, bending your process to accommodate the tool. The first one is overhead, the second has catastrophic consequences.
All of the aforementioned processes are designed to promote dialog and visibility. Tools suck at this. All of them. Wait until your process is down before you consider using them, and then be cautious about using all of it.
That said, the folks over at DevJam put together an online mapping tool called cardboardit. It’s an intentionally lightweight tool that’s great for story boarding and slicing releases. It’s designed for one persona, the story mapper, as opposed to the junk drawer feature set JIRA provides. It’s worth a look, especially if you have a distributed team.
Conclusion
Apologies for the run on. I could gush over this stuff all day. While the class all gravitated towards technology projects, it’s important to note this is not tied to software at all. Nobody said the stories are programming tasks. If you can solve them without code, that’s fine. As long as you complete your journey.
Going to end it here but I’m happy to expound on any of the topics if there’s interest. If you’re interested in the training, contact me or JC. We’re looking to repeat this in May/June but are happy to discuss special arrangements.
