User Story Mapping


(Andy Wootton) #1

It was surprisingly difficult to know how to categorise this. It’s product development rather than code.

When I was Agiling, I kinda used Scrum but found I got lost amongst all the ‘independent’ user-stories and didn’t always understand the relationships between them or know if we had holes we’d fall in later.

I’ve been looking for techniques to help with this problem. My first candidate is User Story Mapping. Has anyone used one of this family of ‘thinking tools’? Did it help? I have some concerns from what I’ve read so far but I think there is something good hidden in there. I like that it’s a hierarchy that you start in the middle rather than the top. That makes far more sense. I like that its main supporter hates the word “epic” because he thinks it sounds daft. Far too hobitty for me too.

Can anyone suggest other possibilities?
Lean Startup Canvas seemed possible but I think that is earlier, hand-wavy stuff.

User Journeys or User Story Journeys from UX make me a bit nervous. I expect brightly covered scatter cushions and people called Crispin or Zen who are only doing this until their Arts Council funding comes through. Let’s face it, it’s imprecise UML.


To Do Lists/Apps
(Marc Cooper) #2

One key approach with agile is to let go of thinking too far in the future and embracing iteration. User Story Mapping is planning with Post-its. Many of these techniques that have been dreamed up are reinventions (and perhaps improvements) of things from the past. Most (all?) aren’t agile.

:slight_smile:

To be honest, I’m not clear what problem you are trying to solve. Why not stop trying to find relationships between user stories and stop worrying about future problems? There! Sorted! :stuck_out_tongue_winking_eye:


(Jim Gumbley) #3

Are you aware of the book? http://www.amazon.co.uk/User-Story-Mapping-Discover-Product/dp/1491904909

I picked up the approach (lol, yeah multidimensional planning with post-its is right :smiley: ) from a colleague who had worked with the guy who wrote the book. Asking “do we have a backlog we all believe in” (to the whole team) is a behaviour I picked up this way. Even after the map has been built it turns out to be a great question to ask, again and again.


(Andy Wootton) #4

@auxbuss Neither did the devs I worked with. They jumped straight from a user-story to a solution in code. My role was mainly at the initiation stage, to ensure the team and the stakeholders shared a single, abstract understanding of the problem we were trying to solve and sense-check that it was the right problem and there was real value to be harvested. People often try to re-engineer their previous wrong system or get rid of a low value annoyance in their procedure.

I did this by UML modeling but if the model could be constructed out of use-stories, it would reduce waste. I think mental models are networks, not linear like a list of user-stories. It’s about all working with the same incomplete living model, not planning too far ahead.

I’ve read a blog entry http://jpattonassociates.com/the-new-backlog/
If an idea needs a book to explain then I think it’s too hard.


(Marc Cooper) #5

I have two wads of post-its under my second monitor. I certainly wasn’t critiquing their usefulness :wink:

:thumbsup:


(Marc Cooper) #6

In a sprint, devs will usually go straight to coding. Once the user-story (most frequently represented on a card [mostly virtual these days in trello or pivotal]) has been groomed, and cleared to be picked (pulled into a sprint), that’s what I’d expect.

The function you describe is what I would call grooming. I wouldn’t expect to see a card being considered for development that does not having business value. Agile tolerates reversing previous decision; either regressing to a previous position or moving to a new one. Again, I consider this completely normal. The key difference with traditional business practices is the absence of blame. An agile environment embraces the opportunity to experiment and accepts that sometimes things don’t work. Failing isn’t waste; it’s education/learning. Failing is a loaded word.

I know UML quite well, and I find it (well, parts of it) a useful communication tool, but a limited design tool. I appreciate our views might differ on that. I have never created UML from a user-story, but I have used (one or two bits of) UML to help clarify a user-story.


(Jim Gumbley) #7

The whole book doesn’t explain the approach, and the approach is not at all complex. The book is a grab bag of resources, I’d recommend it. What a silly and hostile comment, very passive aggressive!

And pretty odd from a UML advocate! That really does require a book to understand.


(Andy Wootton) #8

@jgumbley I sometimes worry that I over-smiley. Maybe I’ve cut back too far. I say a lot that’s silly. I like to have fun.

I felt I’d got enough information to know USM wasn’t quite what I wanted, from the several blog posts I’d read. I didn’t find them difficult to understand, I thought they over-simplified, so I’m looking for variations. I don’t believe that there is only one way to group tasks. I think us humans convert between networks, trees and linear narrative so naturally that we don’t realise we’re doing it but in one direction you have to throw information away and in the other, dream it up. Both are entropy-vectors. I just made that up. I’m being silly again but this time I’m serious.

I read books very slowly and the pile beside my bed in an unread state is a health hazard. There’s no point adding to the backlog. I looked at the reviews on the book link. Some were quite critical of how slow moving it was, though one did say it contained other good ideas.

I didn’t exactly say I advocate UML, only that I (mis)use bits of it. My UML is really sloppy and I’ve only used use-case, activity and class diagrams seriously. I follow Scott W. Ambler’s guidance of ‘as little as I can get away with’. I used boxes with lines between them long before I called them UML.


(Andy Wootton) #9

@auxbuss We groomed but that isn’t what I mean. The blog entry I pointed to explains the problem USM is trying to fix and it does partly.

Agile practitioners often advocate making decisions as late as possible. I’m trying to extend that by delaying feeling that I understand problems for as long as possible too. I can’t hold a lot of ‘so far unrelated’ facts in my head like some people can, so I want to use ‘graphical’ methods to keep relate-able tasks loosely joined. I’m trying to fix intertwingularity: making tasks hierarchical, (multi-)categorisable and sequential. Ted Nelson said it was impossible but I’ve volunteered to give a talk on how to do it in January so it could be embarrassing if I don’t.

I’ve accepted that it’s not possible in the physical world because of stickies being trapped in 2.5 dimensions (2D + piles) but I’ve realised recently that software isn’t constrained by physics, so I’m hopeful. @paulspencerwilliams’ talk on Clojure gave me ambitions to virtually move outside space-time altogether :smile: I’ll let you know if I ever work out what that means.

USMs sequentialise task order horizontally (it should be a tiered network), pick one set of hierarchical classifiers (there may be several), order vertically by priority and split with horizontal lines by iteration. They are ‘nearly there’ but not quite.


(Steve Pitchford) #10

Interesting article. I’m a member of the “ideas quorum” at work - an idea we took away from a Roman Pichler session on his lean product canvas and the p/o side of agile.

Refinement is probably a lot easier when there is more than one of you. For starters, the earlier a idea is released from the clutches of it’s creator, the greater chance it has to become greater than the limits of it’s instigator.

One of the key personal takeaways for me was the need for subtly different processes for features than products, and also the bounds between a feature and a product.

At $work, we have tiers of trello boards which represent the failure of ideas to be implimented. They start off as “suggestions” and if they are found to be original, possible to impliment, and commercially worthwhile, we have “long grass” silos to move ideas in that are good, but not as good as their colleagues.

Only a select few survive to become part of the product backlog - and there tend to be many aggregations and pivots of all but the most nontrivial suggestions before they are deemed ready for development.

Now I’m 100% satisfied that trello isn’t 100% fit for the problem space, but it aids communication and traceability at a sufficiently low cost for us not to look too hard elsewhere.

I think there is a bias for developers to overscrutinise and potentially over-engineer business process, which can have a negative overhead in terms of time to market. That said - others can go too far the other way - failing to put in sufficient process to support function.

I guess, like so many other things, it’s a question of balance and judgement to impliment the appropriate level of process for the given state ( ie size, tacit skill and growth rate ) of the business.


(Andy Wootton) #11

@Steve_Pitchford “the earlier a idea is released from the clutches of it’s creator, the greater chance it has to become greater than the limits of it’s instigator.” and correspondingly, the greater the potential to compromise away the purity of the original vision.

Once you get to “features”, haven’t you already begun the design process? They are features of a thing you are building. How can you design collectively without a shared understanding of the ‘problem’ you are trying to solve? I think ‘a product’ is one of the arbitrary groupings of tasks that I mentioned. There are always other possible ways to chunk tasks.

Some of the USM people seem to like CardboardIt https://cardboardit.com/

I always ask a team that mentions “function” to define precisely what they mean. They tend to all say “it’s obvious”, then they say what they think and a row starts. I go for coffee and when I get back they may have decided or at least understood why I asked. Sometimes they never forgive me for seeing ambiguity where non had previously existed.

I think businesses have ‘processes’ which they ‘do’. They are ‘what’ they do. To embed some of those processes in software, in imperative languages, you have to define ‘procedures’, ‘how’ they do it. I think those are the ‘functions’ too but many will say it’s the HR department or the ‘Board of Directors’. That’s like confusing job titles with roles.


(Steve Pitchford) #12

It’s certainly a difficult problem to balance! Roman Pichler advocated the creation of a “product vision” as an early stage in the process in order to retain the good bits of an idea, but to invite feedback on aspects where improvement can assist.

Incidentally, i’m very sorry if my previous post came across as critical - I was just attempting to share an experience and on re-reading, could have put certain elements better.


(Andy Wootton) #13

@Steve_Pitchford It didn’t but I’m perfectly happy to have ideas criticised. That’s partly why I use social media: to get feedback on ideas that are only half-baked.


(Steve Pitchford) #14

I’m starting to think of different types of building blocks of software ( from a task definition and management technique ). I may be wrong but suspect this is linked to the thought chain you discussed regarding non-hierarchical, non linear task composition.

A current thought I have is that a concept of a Minimal Deployable Unit is of a great deal of use to me ( which should probably be meaningful deployable unit ).

We are working on a project that was well designed and considered in terms of user journies. This one was a bit chicken and egg in terms of the user journey dictating requirements which were then assessed for implementation feasibility giving a feedback loop which added a degree of impediment to progress…

We’ve ended up with a functioning prototype that is sufficient for us to have confidence in the statement that we know what we are doing.

The issue for us is turning this very well formed brief into shippable code - as there are multiple points of enrichment required to enable subtle new features.to accommodate the enhanced user journey, and the all-or-nothing approach is no good for this project.

So it turns out that it’s looking like an appropriate strategy for us to get this new feature out, in this instance, is to consider deploy-ability first, and to decompose the well formed end goal into well formed deployable chunks ( MDUs ) - potentially having two or three ( or more ) milestones on the way to the end goal.

Now to meet these milestones, we may end up with a few detours enroute to the final end-goal, but, by acheiving these milestones, it looks like we get measurable progress towards our end goal, with ( to some degree ) recognizable overhead.

Now it feels to me like these MDU’s are a little bit of a kick back from the current implementation strategy, but also a reasonably pragmatic way of building software. The classical “product increment” then becomes a set of MDU’s which result in meaningful customer proposition, with the tasks being the set of operations required to achieve a MDU.

I’ve deliberately avoided mentioned scrum and iterations as I’m not sure it’s the best fit for every problem, and i’m hoping to avoid focus on coding rather than product development, but I hope this highlights some of the issues I’m having when a perceived well formed incremental gain is substantially non-atomic. I’m also not too sure how this maps onto or relates to the USM - even having re-read the jeffpatton blog.

Is the concept of an MDU as a building block of software helpful or a distraction?


(Andy Wootton) #15

I’ve used the the deliberately self-depricating phrase “What’s the least I could do?” to get customers to make their user-stories smaller. Agility is about delivering value early and getting feedback from experience. I think this is the same as your MDU.

People confuse benefit with value so they ask for big chunks of benefit they want, which they will necessarily get later, so I tried to find tiny pieces of work with high benefit that we could give them faster. There’s nothing in Scrum that says you aren’t allowed to deliver (possibly ‘unofficially’, in a test environment, or looking over the developer’s shoulder) before the end of the Sprint, to get feedback earlier. This is what got me interested in Lean continuous delivery.

I think tasks/activities/procedures are networks, rather than believing they are ‘non-hiearchical’. I think trees/network layers are useful models for simplification of our networks but they are arbitrary. We shouldn’t be tricked into thinking the same tree will be the appropriate model/simplification for all purposes. I want to keep the complexity of the network but hide it behind simple views. It’s the same concept as my decision to regard a book I’m writing as a single path through a network of ideas. Some authors have built entire careers out of different paths through the same network. I wanted to Lean publish so my original book got better over time.

The top row of the USM is a chosen path. The first 2 rows are a chosen hierarchical model. Other possible models have been thrown away, or at least: only survive in the heads of the team members, so may be different. I think the USM model makes sense but may need to be multi-dimensional. You can’t do that with stickies. Have I made sense?

[After writing the above, I got in the shower, where I do my best thinking. I’ve realised that “all I need to do” to fix intertwingularity is to invent a unified model of information. Intertwingling is computational science’s relativity vs quantum mechanics.]