MAAAAAAAAN, he said shave 5 years off your learning journey; This was freaking GOLD! im so excited to change the landscape (and get heartbroken with the resistance), but this gives me a light of hope that we can do solutions better to “change the world”. Lets get that bread!
10:37 The problem: Documents don't work. The solution: Tell me your story. 11:50 Stories get their name from how they're meant to be used, not how we write them! 12:58 Scrum backlog grooming meeting. This is how they normally go :( 13:50 Something special is going on during an effective conversation 14:20 Not until you feedback. Explain or, better, show what you understand. Then we start to really get it 15:35 Shared documents aren't shared understanding 16:40 It's the conversations on the left that yielded the acceptance criteria on the right 23:05 Effective story conversations are meant to build shared understanding. The best documents use words and pictures to help recall our conversation, they don't replace conversations 23:18 Stories are meant to solve 2 problems (neither of which is 'Need better requirements'). Problem 1: Documents don't work. Solution: Tell stories. They don't replace documents they build on top of them. Problem 2: Too much to build... 24:00 Change The World (Model of Thinking) Output explained Outcomes explained Impact explained 32:00 Build Less: Minimize output and maximize outcomes 33:45 'Requirements' means 'Shutup' 36:25 The word requirement is just plain wrong 37:10 Origin of stories: "If you can tell stories about what the software does and generate energy and interest and a vision in your listener's mind, then why not tell stories before the software does it? 39:40 Problem 2 (again): There's always too much to build. Solution: We need to be focusing our conversations on building things that matter. Minimize output. Understand who, what, why. 40:05 That's why we're doing this. If you're not talking with each other they're not stories they're just crappy documentation. AND If you don't talk about what you can take out and make the value as high as possible then they're not stories they're just communicating requirements. 40:41 Stories Create Another Problem... 43:18 When we talk about a story early on we should be discussing if we should be doing it or not, NOT about how big is it? what's the acceptance criteria? etc 44:43 A Story Card Template. This card is used to start a conversation early on. Doesn't always work in a sprint where we try to force fit it sometimes 48:20 This is discovery work. Discovery is about learning fast. 49:06 Case Study: Mad Mimi 51:38 Framing. The first conversation to have 56:04 Case Study: Globo.com 59:36 Case Study: Globo.com (again) 1:04:00 Slicing up the User Story Map. Target Market + Outcome + MVP. Minimum VIABLE Product. VIABLE = SUCCESS 1:04:45 Oh! We're not supposed to prioritize these stories. We're supposed to prioritize these outcomes. Think about users and customers. 1:05:05 Outcome-centric-roadmap. Start thinking of the roadmap NOT in terms of 'what features?when?' but 'who?when?' 'what markets?when?' or 'what groups of people? when?' 1:05:54 How do you know if your hypothesis is correct? You don't. That's why you test early and get feedback on MVPs like "skateboards" before you try build a "car". You don't build a wheel then a steering wheel. You build the whole thing. 1:09:58 Crossing the Chasm Curve. The Chasm is between early adopters and early majority. Innovators and Early Adopters are Customer Development Partners. Show them first. Nail it. Before you scale it. 1:13:21 Incremental and iterative thinking 1:15:06 In the software world this is called bad requirements or scope creep. In the real world this is just called learning and that's okay. What it means is you write stories that make changes to what you did before 1:16:06 It's not iteration if you only do it once. Many organisations consider revising the same functionality as failure. iteration is not tolerated 1:18:55 (SUMMARY SLIDE) What stories are about? We need to change the way you work, not the way you write down information 1:22:00 (Q&A TIME) Requirements are now disguised as 'Stories'. 1:23:50 The heart of business decisions is not what to do but who to pay attention to. How do you convince business owners of this? Read this HBR article: "The Big Lie of Strategic Planning" 1:27:50 Stories are too big. What to do? 1:33:35 Get a Dev and Tester (not just a PO or a UX person) to break down a user story into the acceptance criteria 1:35:56 What about regulations? 1:39:36 How do you do this in a distributed team? (Side-note: amazing to see the tools that have appeared to assist with Shared Understanding for distributed work since this talk was given/uploaded in 2015) 1:45:20 How does this scale? 1:54:55 You wouldn't do discovery and validation with the User Story Map? No. Use paper prototype etc 1:55:10 How to you do time management? Coz if you invalidate then your whole schedule is at risk. Answer: You've gotta do it ahead of the sprint. "You can't do discovery work just-in-time" It's not a discovery phase if you need to be able to predict. Then it's design not discovery. It doesn't work that way.
Thanks Jeff! Presentation was really great. I loved how you focused on why, how and by whom user stories should be used, also all the great examples. You are able to understand very fast what to take into consideration when adapting this in your own organization
Wonderful video - this is useful even after reading his book as it highlights the key ideas. He summarizes a lot of ideas from different disciplines especially around startup thinking and learning fast.
What I miss a bit in this video is a small worked out example of a complete mapping. I see people doing it on the photo's he presents but I don't really get how the user steps on the 'x-axis', resulting in these vertical columns, are determined. Nevertheless, interesting lecture.
MAAAAAAAAN, he said shave 5 years off your learning journey; This was freaking GOLD! im so excited to change the landscape (and get heartbroken with the resistance), but this gives me a light of hope that we can do solutions better to “change the world”. Lets get that bread!
10:37 The problem: Documents don't work. The solution: Tell me your story.
11:50 Stories get their name from how they're meant to be used, not how we write them!
12:58 Scrum backlog grooming meeting. This is how they normally go :(
13:50 Something special is going on during an effective conversation
14:20 Not until you feedback. Explain or, better, show what you understand. Then we start to really get it
15:35 Shared documents aren't shared understanding
16:40 It's the conversations on the left that yielded the acceptance criteria on the right
23:05 Effective story conversations are meant to build shared understanding. The best documents use words and pictures to help recall our conversation, they don't replace conversations
23:18 Stories are meant to solve 2 problems (neither of which is 'Need better requirements'). Problem 1: Documents don't work. Solution: Tell stories. They don't replace documents they build on top of them. Problem 2: Too much to build...
24:00 Change The World (Model of Thinking)
Output explained
Outcomes explained
Impact explained
32:00 Build Less: Minimize output and maximize outcomes
33:45 'Requirements' means 'Shutup'
36:25 The word requirement is just plain wrong
37:10 Origin of stories: "If you can tell stories about what the software does and generate energy and interest and a vision in your listener's mind, then why not tell stories before the software does it?
39:40 Problem 2 (again): There's always too much to build. Solution: We need to be focusing our conversations on building things that matter. Minimize output. Understand who, what, why.
40:05 That's why we're doing this. If you're not talking with each other they're not stories they're just crappy documentation. AND If you don't talk about what you can take out and make the value as high as possible then they're not stories they're just communicating requirements.
40:41 Stories Create Another Problem...
43:18 When we talk about a story early on we should be discussing if we should be doing it or not, NOT about how big is it? what's the acceptance criteria? etc
44:43 A Story Card Template. This card is used to start a conversation early on. Doesn't always work in a sprint where we try to force fit it sometimes
48:20 This is discovery work. Discovery is about learning fast.
49:06 Case Study: Mad Mimi
51:38 Framing. The first conversation to have
56:04 Case Study: Globo.com
59:36 Case Study: Globo.com (again)
1:04:00 Slicing up the User Story Map. Target Market + Outcome + MVP. Minimum VIABLE Product. VIABLE = SUCCESS
1:04:45 Oh! We're not supposed to prioritize these stories. We're supposed to prioritize these outcomes. Think about users and customers.
1:05:05 Outcome-centric-roadmap. Start thinking of the roadmap NOT in terms of 'what features?when?' but 'who?when?' 'what markets?when?' or 'what groups of people? when?'
1:05:54 How do you know if your hypothesis is correct? You don't. That's why you test early and get feedback on MVPs like "skateboards" before you try build a "car". You don't build a wheel then a steering wheel. You build the whole thing.
1:09:58 Crossing the Chasm Curve. The Chasm is between early adopters and early majority. Innovators and Early Adopters are Customer Development Partners. Show them first. Nail it. Before you scale it.
1:13:21 Incremental and iterative thinking
1:15:06 In the software world this is called bad requirements or scope creep. In the real world this is just called learning and that's okay. What it means is you write stories that make changes to what you did before
1:16:06 It's not iteration if you only do it once. Many organisations consider revising the same functionality as failure. iteration is not tolerated
1:18:55 (SUMMARY SLIDE) What stories are about? We need to change the way you work, not the way you write down information
1:22:00 (Q&A TIME) Requirements are now disguised as 'Stories'.
1:23:50 The heart of business decisions is not what to do but who to pay attention to. How do you convince business owners of this? Read this HBR article: "The Big Lie of Strategic Planning"
1:27:50 Stories are too big. What to do?
1:33:35 Get a Dev and Tester (not just a PO or a UX person) to break down a user story into the acceptance criteria
1:35:56 What about regulations?
1:39:36 How do you do this in a distributed team? (Side-note: amazing to see the tools that have appeared to assist with Shared Understanding for distributed work since this talk was given/uploaded in 2015)
1:45:20 How does this scale?
1:54:55 You wouldn't do discovery and validation with the User Story Map? No. Use paper prototype etc
1:55:10 How to you do time management? Coz if you invalidate then your whole schedule is at risk. Answer: You've gotta do it ahead of the sprint. "You can't do discovery work just-in-time" It's not a discovery phase if you need to be able to predict. Then it's design not discovery. It doesn't work that way.
Thank you for this, Appreciate it!
This content is gold. Thanks Jeff!
Thanks Jeff!
Presentation was really great.
I loved how you focused on why, how and by whom user stories should be used, also all the great examples.
You are able to understand very fast what to take into consideration when adapting this in your own organization
One of the best presentations on user stories !
I'm a brazilian and sandly can guarantee that is true what he says about meetings times, lunch duration and deadlines around here.
Wonderful video - this is useful even after reading his book as it highlights the key ideas. He summarizes a lot of ideas from different disciplines especially around startup thinking and learning fast.
A gem of a talk..!! Outstanding!
Fantastic training, lots of insights!
Simply Awesome...
Jeff, thank you so much for such a great & insightful content!
There is so much value in it!
Yes I too thought it was simply awesome.
thanks very much for sharing this, great content!!
Well, i'm Brazilian and i can atest to that
What I miss a bit in this video is a small worked out example of a complete mapping. I see people doing it on the photo's he presents but I don't really get how the user steps on the 'x-axis', resulting in these vertical columns, are determined. Nevertheless, interesting lecture.
Haha! That is the million dollar question! Easy to say, so much harder to do in a real world setting!
Such a session would help our old crusty business analysts to get away from their 1000 pages specifications that nobody reads and understands!!
1:07 you learn from small steps MVP
What is the word he's saying at 1:36:36 ?
"Story template or opportunity canvas". I believe.
the next time. plese set out the clapping one's hands.
a 2 hour talk !? it must be for old people.
just admit you're dumb