Series: Agile Brazil 2010 | Part 2 of 6 > Complete coverage of Brazil’s first national agile conference
Just got back to the hotel — still carrying a few sticky notes on my backpack and a brain spinning with ideas. Today was an eye-opener. David Hussman’s workshop on User Story Mapping wasn’t about filling walls with post-its. It was about building shared understanding, mapping journeys, and delivering value through stories — not just stories written down, but stories told, heard, and felt.
Mapping the User’s Journey
We started by breaking into diverse teams. No comfort zones, no familiar faces. The prompt was simple: build a product from scratch as a fresh new team. Our tool? A story map.
But it wasn’t just a bunch of stickies on a wall. It was a living scene, a user’s perspective first, features second. Every row told a story: a flow of actions a user might take to reach a goal. Every column was a slice of deliverable functionality.
The clarity that emerged was striking. Suddenly, we all spoke the same language. The map forced us to articulate who we were building for, why it mattered, and what was really needed now — and what could wait.
Real Stories Beat Epics
David made it clear from the beginning: “Little stories are better than big epics.” That hit me. Too often, we overdescribe and under-understand. By focusing on real interactions and journeys, we quickly saw how these stories surfaced hidden assumptions and clarified priorities.
One group worked on a fictional medical appointment app. We mapped everything from searching for a doctor to receiving a confirmation SMS. Then we broke it down: what’s critical for a first release? What enhances the core but can come later?
It changed how we saw releases. No longer a flat backlog, but a 3D model of flow, dependencies, and intent. We were building something layered and navigable — not just “a list.”
Lowering Anxiety with Context
One powerful moment came when David told us: “Only deliver the first row of the map.” We froze. What about the rest? What if we never got to it?
But then he reframed the fear: “Reducing scope increases clarity.” Because we’d already mapped everything, we could now prioritize responsibly. We weren’t cutting features blindly — we were focusing deliberately.
And that’s the magic of story mapping: even when you de-scope, you’re not throwing away vision — you’re anchoring it in reality. It shifts conversations from opinions to options. Suddenly, you’re not negotiating features, you’re negotiating flow.
Hands-On: Prototyping with Paper
No decks. No fluff. David had us sketch paper prototypes and simulate flows right on the map. We mocked up screens, role-played interactions, and surfaced friction points. Design, product, tech — all colliding on the wall.
That exercise turned abstract flows into tangible experiences. We saw logic gaps. We spotted redundant steps. We even removed whole features after seeing how little they added. Mapping stories wasn’t just planning. It was refining shared understanding.
Watching other teams present their flows expanded our thinking. No two maps looked the same. Each told a different story. And every one of them worked — because they reflected the people and problems behind them.
Story Mapping is Not a Backlog – It’s a Conversation
David’s biggest insight, one he often repeats in his talks, is this: Story maps aren’t deliverables. They’re conversations. Not documentation. Not rigid plans. They are narratives, visualizations of intent and flow.
He compared traditional backlogs to grocery lists — vertical, contextless. A story map? That’s a movie. A journey. A walk-through. And if it doesn’t tell a story someone wants to hear, it’s not doing its job.
This metaphor stuck with me: “The map is a story worth telling.” Not because it’s comprehensive, but because it’s aligned. It evolves with the product. And more importantly, with the people behind it.
A Maturing Mindset
To close the day, David reminded us that story maps aren’t formulas. They’re framing devices. A way to treat software as a product, not a pile of functionality. And a reminder that teams need to think in terms of purpose, not tasks.
I walked back to the hotel drained, but thrilled. Not from process — but from insight. The kind that shifts how you think, not just what you do. And I knew this wasn’t a one-off. It was a practice I wanted to keep applying, learning, sharing.
Thank you, David Hussman. Thank you, Agile Brazil. What a day.
Agile Brazil 2010 Series Navigation:
- Previous: Part 1 - Hands-On XP Workshop
- Current: Part 2 - Story Mapping with David Hussman
- Next: Part 3 - My First Agile Talk
- Part 4: Retrospectives with Hugo Corbucci and Mariana Bravo
- Final: Part 5 - Guerrilla Coaching with Francisco Trindade