Best-Kept Secrets of Product Development Part 4: Shared Understanding

Image from https://akvo.org/blog/the-key-to-users-happiness-story-mapping/

Here are some of my notes from the amazing “User Story Mapping” book by: Jeff Patton!

Most of these when you read them sound like just common sense but at the same time, super hard to keep in mind while developing products:

The whole theme is:

Shared Understanding

There are a lot of book, talks, processes and standards to show you “How to write the perfect story?” but the reality is doesn’t matter how good you write the stories, if you don’t have meaningful conversations about them and come to shared understanding.

So here we go, the magical best-kept secrets of product development all with focusing on “Shared Understanding”

User tasks are the basic building blocks of a story map. Use the goal-level concept to help you aggregate small tasks or decompose large tasks.

Maps are organized left-to-right using a narrative flow: the order in which you’d tell the story.

Details, alternatives, variations, and exceptions fill in the body of a map.

Activities aggregate tasks directed at a common goal.Activities and high-level tasks form the backbone of a story map.

Use slices to identify all the tasks and details relevant to a specific outcome.

Six Simple Steps to Story Mapping:

Frame the problem.
Map the big picture.
Explore.
Slice out a release strategy.
Slice out a learning strategy.
Slice out a development strategy.

Use storytelling with words and pictures to build shared understanding.

Don’t just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome.

When we get into the thick of developing software — or even later than that, after it’s delivered — that we realize we weren’t thinking of the same things. Lots of people call this lack of shared understanding “bad requirements.”

The document writer feels bad — as if he should have written more, or less, or used some cool requirements technique.

Those who signed off feel bad at first, and then indignant. “Surely you didn’t expect I’d read every detail!

After all, we talked about this for days. I just expected you’d understood what I said. I can’t understand your silly requirements document anyway.”

And the people building the software feel blindsided. They muddled their way through those cryptic documents and what they built was still wrong.

Everyone hates the document in the end. Yet we still keep trying to write a better one. We can both read the same document, but have a different understanding of it.

But misunderstanding the document is only half the problem. We waste lots of time and money building what the document describes, only to find out later that what actually solves the intended problem is something very different.

Those documents often accurately describe the wrong thing. Documents usually describe what we need, but not why we need it.

The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.

To stop working so hard on writing the perfect document, and to get together to tell stories. Stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used.

Let me repeat that with more emotion. Right now you should stop whatever you’re doing and say this out loud: Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.

The best solutions come from collaboration between the people with the problems to solve and the people who can solve them.

Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.

A while back I began to notice that this entire story thing had gone a bit sideways; that is, lots of the people writing books, teaching, and using them focused on the activity of writing stories.

If I had a dime for every time I’ve been asked how to write good stories, I’d have even more dimes than I collected a few chapters ago.

I think that was the example that triggered the idea. If you can tell stories about what the software does and generate interest and vision in the listener’s mind, then why not tell stories before the software does it?

So the idea is telling, and you know you’re doing it right if you’re generating energy, interest, and vision in the listener’s mind. That’s big. And it sounds a lot more fun than reading a typical requirements document.

If you’re not getting together to have rich discussions about your stories, then you’re not really using stories.

Card: Write what you’d like to see in the software on a bunch of index cards. Conversation: Get together and have a rich conversation about what software to build.Confirmation: Together agree on how you’ll confirm that the software is done. Just remember, simple isn’t easy.

I hate that term backlog. We haven’t even started to build software, and it already sounds like we’re behind!

Story conversations are about working together to arrive at a best solution to a problem we both understand.

If we build what we agree to, what will we check to see that we’re done?

All these above “secrets” are from the amazing “User Story Mapping” book by: Jeff Patton!

If you enjoyed these little secrets, I recommend getting his book so you don’t miss out on all the great stuff he talks about in the book:

User Story Mapping by: Jeff Patton

If you liked this article, click the👏 below so other people will see it here on Medium.

Let’s be friends on Twitter. Happy Coding :)

Cheer!