Ep. 7: Jeff Patton - User Story Maps and discovering great products

Stories Connecting Dots with Markus Andrezak

Episode 7 - Jeff Patton - User Story Maps and the discovery of great products

Another one of the greats. I follow his work since years, I integrate lots of what he does in my work. Everyone knowing me or having had a training with me, knows what he does with Story Maps. But having come up with Story Maps and having written the first book around is „this little thing“ to Jeff Patton.

Jeff is really deep into product work and he has lots of thoughts to offer on Agile and especially on everything around stories and story thinking. And one of the reasons he knows all about that is because he was already there when it happened. He was in the same building with Kent Beck when Extreme Programming happened and Stories came up. He was coached by Rob Mee of Pivotal Tracker fame.

So, this is not just a deep dive on stories and the Story Mapping technique that emerged form it but also some oral history on how and where it all started to happen.

Nowadays, Jeff more and more dives into the discovery phase and at the end of the podcast we will hear lots about this and where this might clash with Agile or how it is taught in most cases.

But what is so relaxing is that we really don’t talk much process. And I think the reason is that product is much less process than it is orthogonal to process and it is about thinking of quality, what quality means to whom, for whom we’re building things and having empathy for them.

Speaking of empathy: Enjoy a nice conversation with a humble, humorous and relaxed Jeff Patton!

Chapters

1. 0:02:04 (User) Stories - the base of all
2. 0:13:19 Documents are like vacation stories
3. 0:31:43 Story Maps - what it is, how i emerged
4. 0:43:10 How to teach Story Maps
5. 0:55:34 Struggling with the backlog as a prioritised list
6. 0:57:54 Products we like: A BMW 335 convertible, Netflix and Spotify, an EV 320 Microphone and a Sonos speaker
7. 1:04:34 Why have (Agile) things gotta be so complicated?
8. 1:11:44 Is software harder than software and: First off, no process is going to help you

Chapter Notes 2:04 (User) Stories - the base of it all

Going down memory lane, meeting lots of now famous people, e.g. Kent Beck

"People have gotten User Stories wrong from the beginning"

"When I first heard the term "Stories" I thought it was stupid - what we’re doing is important stuff. Stories … that sounds like fantasy or fiction … it doesn’t sound serious at all"

"What Kent meant with stories was really stories. We should be talking with each other and telling stories about the products"

"The goal is building shared understanding"

"What we are talking about isn’t what to build. What we’re talking about with each other is: who’s using this product and why and what benefit they get. and understanding that we can then talk about together about what to build."

"Where things go horribly wrong is when people use stories and try to do what they used to do."

"So, people try to use stories as an alternative to other specification algorithms, when that’s not what they were meant to be"

How stories are not precise and complete

8:22 Comparing stories and UML The promise with UML was that you had to learn UML and then you had to talk to someone who knew UML. Stories fix all this.

"Stories fix all kind of crappy documentation. Because know we have humans to talk to to explain things"

"I keep telling people that if you’re using stories, you have to change your process"

"The problem stories don’t solve is the way you specify. … If you’re using stories, you still have to figure out ways to specify."

"I think people write documents because they don’t like to talk to each other."

11:15 Documents are like vacation photos

„The minute you write stories and hand them over without having a conversation, that’s the moment when things start to go wrong.“

17:14 How Kent Beck never called "stories" "user stories"

Rumors and misconceptions on stories and sizes and templates

How somehow people and many Scrum Master are spreading the rumor of „we have to use (User) Stories all the way

"The way Agile works is we build little things, and we work in short cycles. … But the problem is that when we build a product that is supposed to go to the market and create value it is not something we build in days."

"Those things we can build in a few days hardly have value and it becomes hard to tell a story about those things"

"I learned these things around 2000 and we called them stories and not user stories, and we didn’t use the term epic and you know, the user story template - we certainly didn’t use that."

23:14 How the founder of Pivotal Tracker, Rob Mee, was Jeff’s XP coach, refused using the template in his tool and now it does anyway: "I’m never gonna put that stupid template inside of Tracker … well, it’s in there now. And I’m sure not because Rob thinks it’s a good idea."

"But the template falls apart super easy. … The conversations we need to have are far more sophisticated than that."

"As a user I want just dumbs down all the rich conversations we need to have …"

The three (or five?) C’s of stories

Ron Jeffries 3 C’s: Card Conversation, Confirmation

"The conversation is not about the acceptance criteria but about Who, What and Why! … It’s meant to be a bit of a back and forth."

"What I see people doing these days is: Card -> Conformation"

Documents are contracts and with stories "we finally recognise that documents are never gonna be good enough, they’re never gonna be precise enough and what matters is understanding and the only way we get it is by talking to each other."

"Shared documents aren’t shared understanding" and that will make a lot of people uncomfortable.

31:43 Story Maps - what it is, how it emerged

A solution for breaking big things down that take weeks and weeks to build into little things we can build in days.

The metaphor of rocks that when you break them, remain rocks … just: little rocks. Just like big stories (no matter if you call them epics or not) that when you break them down just remain … stories.

"Story mapping is the thing that I used to do to get from a big idea to break it down into small parts." How story maps emerged from the technique called "User Task Model" over "Span Plan" (influenced by the Poppendiecks) to Story Maps (which name came up in a discussion with Alistair Cockbourn).

How Jeff wanted to write a huge book on everything outside of Agile, but then Story Maps took off and then the small book on story Maps got bigger and bigger.

A next book is planned. Jeff is not afraid, and still has lots to say. It’ll be easy. Ha!

Jeff’s book has three forewords. It reflects the mantra of product work, being credited to Marty Cagan, that it’s all about the intersection between valuable, usable and feasible. The three forewords represent that by having representatives from UX - Alan Cooper, development - Martin Fowler and finally product itself - Marty Cagan. That trinity is called a Core Team and is still widely used.

43:10 How to teach Story Maps

Two good ways:

1. Simply mapping something live and lead discussions, conversations.
2. Mapping a morning from waking up to getting to work, then let a group mix the individual morning stories and change it, because some strange event happened, like: Getting up too late.

These are ways that lets people focus on writing down activities rather than things or functionalities. Also, it makes obvious that different people behave differently. Further it teaches how to slice and cut things away, e.g. because there is less time than usual. some things can not be sliced out (morning hygiene) but need to be thinned out.

Maps are useful for still seeing the whole while we flesh out the small things.

"We need details when we go into the next sprint, but we still need to be able to see the whole. Because it’s the whole that has value. That’s the real value of a map."

An application in a workshop: Planning the first release of a wine shop.

55:34 Struggling with the backlog as a prioritised list

"There’s a lot of things I disagree with on how Agile gets taught and used and abused. One of the things I struggle with is the way it is taught that a backlog needs to be a prioritised list."

"If you think of a new product … it would be completely impossible to understand what it is … based on a prioritised list of features."

"It is so valuable to see the whole. And you don’t get that in a flat backlog."

"When you talk about parts of a thing, you normally need all of them."

57:54 Products we like: A BMW 335 convertible, Netflix and Spotify, an EV 320 Microphone and a Sonos speaker

Trying to find out why we like them.

For starters, the BMW is super impractible for where Jeff lives, as they have lots of snow. He still loves it.

Netflix now works for Jeff as a traveler, because downloads are possible.

"Why we encourage people to talk about why they like a product is because why you like a product has a lot to do with who you are."

"The toughest choices are not what features your product has, the toughest choice is who your product is for and the really hard choice is who your product is not for."

"If people really love a product, I always ask: "What did you use before?"."

"When you’re using a good product, you can sorta smell the thought and care that went into creating the product."

"That’s what I really worry about when we talk all about Agile and breaking things into little pieces … that we lose sight of who its for and that we lose sight of all the little things that matter so much … and start working about acceptance criteria."

1:04:34 Why have (Agile) things gotta be so complicated?

While teaching discovery (e.g. in 5 day immersion workshops), Jeff realises that people no longer know, see and have empathy with their clients, users, etc.

"We have to come with a lot of process junk and waste to help us manage what we’re doing when a little bit of empathy and understanding of who you’re building for goes a long way."

"In a lot of contexts it’s not easy to get to the customers. And to what you say, even if we could get to them, we don’t want to. It’s not comfortable talking to those people - and it’s unnerving sometimes."

1:11:44 Is software harder than software and: First off, no process is going to help you

When Apple had a problem with a new carrier, it was normal for a developer to linger around at the carrier. "At Apple it was not not unusual, no one was asking: why aren’t you at your desk? Why aren’t you writing code? It was absolutely rational to do that."

At a different spot:

Q: "If you think of Apple, on a range from 1 to 10 where would you put the quality they ship at Apple?"

A: "I’d put it at 9."

Q: "Where would you put what you ship here?"

A: "About a six."

Q: "If you were at Apple and you would ship a six, what do you think would happen to you? You ship 6 here all the time."

A: "We celebrate that we ship all the time."

Conclusion: "Something has to change around here that is not process"

"Everything is becoming more blurred all the time."

"The hardware isn’t even the hardware. It’s the software that’s changing it."

"More and more you buy a piece of hardware and it’s not like it’s in the box and the partnership with the manufacturer is done. There’s an ownership lifecycle that supports it."

"I was at a conference in Australia and the speaker right before was a designer at Lego. and he came up with that idea that they came up with that perfect Lego model that was really testing well but it was too expensive to build. And he said „you know how it is when the perfect solution is too expensive to build and we have to figure out something different.“ And the audience was quiet and the audience was „no, I don’t know what you’re talking about."

"I see so many people in the software world arguing for what’s best and not for what’s feasible and not understanding that it’s not about best …"

We have to learn again to prototype.

"And at times a prototype is more expensive than the real thing."

"What’s interesting is that Agile Development has gotten totally effed up when it comes to this prototyping thing. There is all this emphasis on potentially shippable software, there is this emphasis on software being built and tested, but look: we’ve lost our ability to use code to build rough stuff to see if we’re building the right thing."

"More and more I talk about learning velocity vs. building velocity."

"If you’re trying to learn something the most expensive way is to build production quality software."

"Building the wrong thing at high quality is waste."

„If there is gonna be a contemporary agile way of building things t’s gonna be this mix of product thinking and customer centric thinking and Agile thinking and I’ll be honest: It’ll break the Agile Manifesto."

Great final words

"What makes a product better is not more stuff, it’s good stuff."

Links

• Jeff Patton Associates
• Jeff Patton: User Story Mapping
• Kent Beck: Extreme Programming Explained
• Pivotal Tracker
• Pivotal CEO Rob Mee
• Alistair Cockburn