Jeff Patton’s User Story Mapping technique; first impressions from a real organization.

My first post is about an ongoing experiment on Jeff Patton’s User Story Mapping that we are conducting at our organization. The objective is to find out how helpful/useful this technique would be on our journey to create more visual documentations.

Prerequisites (It is assumed that you have done at least one of the items listed below):

• You have read Jeff Patton’s blog entry; The New User Story Backlog is a Map.
• You have read the book written by Jeff Patton.

Fair Warning! This post is long, I mean long. If you would like a little background on why we are doing this, read from the top. If not, just jump to the On with the Experiment Already! part.

Contents (Jump to sections):

1. A Brief Look Back in our Organization’s History (a.k.a FlashBack)
2. Kaizen Moment
3. On with the Experiment Already!
4. Dissecting the Experience
5. Final Thoughts
6. References

---

A Brief Look Back in our Organization’s History (a.k.a FlashBack)

We have been conducting agile/lean experiments in our organization since 2012 in order to evolve to the next version; Organization v. ƒv_next(n) = n+1 (where n is the current version and > 1).

We decide on what experiments to run after finding weak spots in our process and defining a Kaizen point. We have found out that most waste occurred, or I should say, seeds of waste were planted during the analysis phase of our projects/work items. We have been watering, caring and growing quite a few of these items effectively; in style. Output is ok most of the time but outcome it not so nice and sometimes horrible.

Example; a feature was being built for almost 558 workdays (yes, workdays) and no one noticed that it was completely the wrong thing until the client said; dafuq!

More statistics about this feature;

• Cycle Time was 59 workdays.
• Lead Time was 558 workdays.
• Spent approx. 11 workdays (~83 work hours).

I don’t know what is more scary; Lead Time of 558 workdays (WTF!), or 499 workdays of wait/waste (= Lead – Cycle)^[1] time, or spending 11 work days worth of effort in 59 workdays just to built the wrong feature thing (you might say context switch is a b*tch or ask anyone heard of WIP?), or everyone doing their job responsibly(!) to produce an outcome such as this. I can go on but I won’t.

---

Kaizen Moment

From examples like this, after gathering everyone’s opinion, we thought that this outcome would have been prevented if the client’s story was understood/confirmed and passed on to the development; keeping the context intact. That way unnecessary and incorrect assumptions about how to build the feature would be diminished. Since then we have been experimenting with high level visual documentation techniques; such as mind maps.

If a numeric measurement should be presented; with visual documentation techniques, we have cut back on our documentation efforts by ~8% and improved our output from 30 items/month to 35 items/month in one project. Of course we can not conclude that this increase was solely caused by the documentation technique used. But we know that it has contributed to the increase in the output and teams have embraced it quickly.

Personal Rant

I believe that lengthy written documentation is the enemy of the context that is needed to build what is in need. Most people do not want to read long documentations and people hate to write them, thus, they are absolutely the major source of waste because no one reads them.

By “documentation” I am referring to the internal documentations; the ones that enable meaningful and intelligent conversations between clients ↔ analysts/product owners ↔ dev teams.

I am excluding end user documentations; such as API usage or help documentations, etc. for the time being. But I believe there are cases that these kind of documentations can also benefit from the visual techniques we are experimenting with.

---

On with the Experiment Already!

As soon as I read about Jeff Patton’s User Story Mapping technique, an urge to share this new found treasure with my colleagues started to grow. I believe Jeff Patton’s User Story Mapping technique will help us reduce the waste points mentioned above even further, but first we need to experiment with it.

With this experiment, we are touching at least three core practices of Kanban^[2]; Visualize, Make Policies Explicit, Improve Collaboratively.

A 2-hour session was set up to talk about the technique and discuss how and where should we start the experiment. I started to prepare a presentation mainly based on what I’ve read about the technique at Jeff Patton’s blog; The New User Story Backlog is a Map and How you Slice It (PDF). (Later on I bought the book as well.)

I had to prepare this presentation in a short time and I wanted to give a good understanding of the technique with visuals and examples. I started preparing the presentation by gathering whatever graphical representations I can find on the internet in order to get the point across. After all, we are big on visual side of things; the presentation should contain lots of visual elements and a few text.

But once you start looking for images, nice icons, fonts on the net, you start to divert from the path you want/need to go. Because you are excited and just want to start without planning/seeing where to go. (C’mon, admit it; we all do it this way even though we advise people not to do it. Because planning is boring, or I better say it this way; the way we do planning is boring.)

After 4 hours of internet surfing, I had bunch of cool eye candy graphics and none of them were related to the subject I had in mind. Frustrated with the outcome, I decided to go with the text slides but I was struggling to get the point across in such a short time.

And then it hit me; why not present the technique using the technique itself? #inception

This way, I would be able to convey my colleagues that this technique can be used to visualise and quickly grasp any process oriented approach we may encounter in our work or personal lives.

I started with writing the topics that I needed to talk about on to post-its in random order as they come to mind and “planning” the flow of the presentation by juggling them around physically. I was done in 30 minutes. Not only was I able to see clearly the information that was going to be passed on, but also when to get them delivered. Fantastic! (Visualise: 1st core practice of Kanban)

Above image is the version 1.0 of the presentation that I delivered to my colleagues. It was fast, effective and most importantly fun.

As you can guess, the yellow post-its are activities (the backbone), the pink post-its are tasks (the skeleton) and the orange post-its are the subtasks (the detail that the associated task may or may not include, depending on time; kind of like release planning). The light pink post-its were used to remind me of related topics/examples that I need to talk about while I am on the orange post-it.

Power of visualization, keeps those neurons firing information even after a long time has been passed.

It is amazing that I can still recall the day and remember what went wrong and what I left out. (Example: I had the “Cake Example” orange subtask under the “Story?” pink task, but it should have been placed under the “Release Planning” pink task right under the “How to slice?” orange subtask.)

Power of visualization, keeps those neurons firing information even after a long time has been passed. Even though the post-its have just one word on them, I know what it means and what information it represents in the presentation. That is the kind of ability that we would like to have when we are passing the work to someone else in the chain; not forgetting the important stuff when relinquishing work.

---

Dissecting the Experience

I have never gotten this much questions and feedback during/right after any of my presentations. Usually there would be a few questions at the end of presentations but this time it was quite a few of them. And they were well placed questions; not I-am-asking-you-a-question-out-of-courtesy kind of questions. So I can safely say that the inception worked better than I expected.

I would like to highlight some of the points we currently believe that would help anyone who is going to try this technique;
Disclaimer: The statements below will probably be changed as we experiment with the technique and learn more about it, so be cautious about what you read here. After all, we are conducting an experiment and nothing is taboo.

• Watch out for the detail that will be given in the user story map. Too much detail should not be here. Do NOT think like a developer/QA and add detailed to-do items in tasks. I have done it and my colleagues done it while we were doing the wake-up example. When writing tasks, we ask “is this task meaningful to the end user; the one that will actually use the product?”.
• Do the wake-up example. It just makes it better to do a hands on example. You will probably get stuck at the first activity thinking what to write and how to fill out the tasks. When that happens, just think about the order you would follow/dictate in order to accomplish the activity at hand.
• During the wake-up example try to find out the left out tasks because they felt obvious. It might be obvious to you but not to someone that will do the work. We’ve had situations like these with our clients; client thinking that a step in flow is obvious and neglected to tell us about it. Outcome: we did not include that step in the flow, thus, causing rework. 😛
• Remember, activities build the backbone of the project. You can not leave out activities when release planning. If that happens to your map than the activity in question might not be an activity but a subtask.
• Context is everything, include the story with in your map. Do not just give leafs^[4] to your team and leave out the tree. If you leave out the tree, your client might end up with a bush with the leafs they needed/wanted in a completely different context which is useless.
• If you are going to try this with a client for the first time, make sure both the client and the analyst are in the same room physically.  Otherwise it is no better than just writing it down on a piece of paper and staring at it. It had no effect on our try outs. At least the first meeting should be held in this way.
• Be prepared for resistance from the client. Make them understand what the technique is all about and why it is needed. Do not just tell them “we will be using this technique and we require you to use it from now on”.
• Make sure to include at least one end user from the client side in to this collaboration. Analysts from the client side are not end users.
• This technique enhances your conversations, it does NOT replace them. So, talk but talk effectively and intelligently using the technique.
• For remote teams an online tool can be used. We are playing around with Stories on Board.

---

Final Thoughts

Guess what, this blog was also written by the help of this technique. I would never be able to hold this much information for such a long time without losing bits and pieces of it. I started writing this blog on the 14th of June 2015. It’s been almost a month and since then I have given 2 more presentations about the technique and there are more to come.

The demand is high for this technique in our organization. Not just analysts or dev teams but also our maintenance/help desk groups have requested a session for their department. To be honest, I was not expecting this much attention, but I am excited to see that people actually like using this technique.

The ease of use and physical interaction makes this technique an invaluable tool for any organization when getting right things done effectively.

We are planning to do this with two of our clients in the coming weeks to see their reaction. So, expect more posts about this experiment in the future.

Last but not the least, we would like to thank Jeff Patton for his wonderful work and letting people use it. We will be following his work more closely and give feedback from this blog.

---

References

1. Roock, Stefan. “Kanban: Definition of Lead Time and Cycle Time“. Stefan Roock (Accessed 2015.07.14)
2. Burrows, Mike. “Kanban Values“. Meldstrong (Accessed 2015.07.14)
3. Patton, Jeff. “User Story Mapping (ppt)“. Agile Product Design.
4. Tree and leafs metaphor is used by Jeff Patton in his blog.