When does story mapping help?

Recently, I attended a workshop by David Hussman, and story mapping was one of the topics. Since I had rarely used story mapping, while didn't realize its Indispensability, it made me think of why.


  • Why story mapping?

The introduction of story mapping technique is a response to lack of context for user stories. When you have many small stories, you lose the context and don't see the big picture. Those stories have to be combined to create complete user experience. The complete user experience is also called scenario or customer journey.


  • Use case

However, in my experience of developing telecom systems, i have never encountered this problem. To be honest, we seldom used user story, because telecom systems are not really user oriented and user intensive. We used to think in use case. When I compare story map with use case, the customer journeys in story map are similar to main success scenario and extensions in use case. Then, we simply take those customer journeys as PBIs (Problem Backlog Items) without splitting them into steps-based user stories.


  • The process of writing user stories

When we work on user stories, it's common to brainstorm around user roles. Typically, we derive user stories from user tasks. Then, we find that some user tasks have to be combined in order to complete a journey. Therefore, story mapping becomes very useful, even necessary in order to understand the context and see the big picture.


  • The process of writing use cases

However, if you write use cases, it starts with actors. More precisely, you start with primary actors and its goals. There is use case for each goal, and each variation for achieving the goal becomes main success scenario and extensions. You don't start with supporting actors, while the tasks done by supporting actors are necessary to achieve the goal, thus, they are pulled into the diagram.


  • Change the process of writing user stories

If we apply use case thinking, we can modify the process of writing user stories a bit.


Think about primary users/personas, not every user who is interacting with the system.

Think about goals from primary users/personas, not tasks from them.


By doing this, you get stories to achieve goals, rather than stories to do tasks. In this case, those stories are scenarios and customer journeys.


  • Examples for clarification

For scenarios and customer journeys in products and systems with rich user interaction, it is still beneficial to clarify by examples, where the scenario is clarified by listing all the tasks/steps it goes through. Those tasks could be initiated by primary user, but also from supporting users and systems. However, those tasks may not be, or preferred not, regarded as stories.


  • Story splitting

The other way to look at this is from story splitting. Take scenario based stories, if they are too big for delivery, we figure out how to split them. There are many splitting ways, with splitting from steps as one way, even not the recommended way, since those steps alone don't achieve user goal, thus, not really valuable.


  • Collaboration

So far, we compared story map with use case from its thinking process. Traditionally, use case mainly acts as a way to document the system, while user story and story map are mainly to support the communication. Story map is more visual and often exists in physical space, while use case is often written in document with UML notation. With Agile modeling, it doesn't have to be so, though.


It helped me understand story mapping and its implication by thinking this through, does it help you?

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai