Attendees in Kitchener Waterloo – collaborating on building their Story Maps.

Story Mapping is a simple tool to help you visualize your Product Backlog. The traditional Product Backlog in Scrum is a real improvement over traditional methods for tracking and understanding the work ahead. However its still a long To Do List which has some issues:

• It’s hard to see the forest for the trees.
• It’s easy to miss important items in the morass of detail.
• It’s hard to prioritize well since we can’t see the big picture.
• It’s not explicitly focused on the user needs.

In other words, flat lists become confusing as the Product grows in size and complexity.

Story Mapping is a tool to help overcome these issues by helping the team visualize the needs of the end-users. Along the top we write out all the “User Needs”. On the Y-axis we create the Stories for each “Need” or task. Some “User Needs” aren’t of interest in the current release – so they might get no Stories. Other needs have a number of things that need to be done for them – so they get many Stories. In addition, each user gets their own map.

The key here is that the map acts as a tool to help organize the Stories. The map helps us spot gaps in our product and helps us discover the priorities. However, most importantly Story Maps help start conversations among team members about what we’re building.

The files below are from a series of Story Mapping workshops that I’ve facilitated in Montreal, Toronto and Kitchener-Waterloo this past year. If you would like to bring Mark into your company to facilitate a Story Mapping Workshop or teach a Product Owner course please email: courses@agilepainrelief.com

The files make the most sense if you’ve attended the workshop

• StoryMappingWalkThrough - the keynote presentation I run in the background.
• Story Mapping Basics - the basic introductory handout that all attendees get. It outlines some of the basic ideas behind Story Mapping and provides the core scenario for the exercises
• Julia Persona and Rob Persona - the personas that the audience gets to use for their exercises.

Be Sociable, Share!

• 

Last year I created a short session – Learning Scrum Through Games – to help people explore the basics of Scrum in a one hour format. This year I rewrote it and took it to both Agile Tour Toronto and Ottawa.

We learned a number of interesting things from both sessions:

• Even with a poor quality Product Backlog (the Backlog I gave attendees has many issues) the team was still able to create a pretty good product.
• I don’t give the best instructions to start the exercise and yet attendees manage to create some great comics. When a real Scrum team start it’s chaotic at first. I would prefer attendees get a sense of this during the exercise so I give deliberately vague instructions. Read More…

Be Sociable, Share!

• 

We’re starting to organize an Agile Tour 2012 event for the Ottawa Gatineau region. We need a kickass logo and you want some advertising. Create an amazing logo and we will make you famous – at least in the region :-)  I’m not going to limit your creativity by

Details for logo submissions:

• 1 square – 175 x 175 pixels
• 1 rectangular – 350 x 182 pixels
• We are looking to have the words "agile tour" and "Gatineau-Ottawa" in the logos
• Deadline end of day July 11th

Send logos to logos@GOAgileTour.ca

BTW I’ve not included any samples because I don’t want to create a “Priming Effect”

Be Sociable, Share!

• 

While this is the session I ran in 2011 it has been replaced by: Learning Scrum Through Games – Goldilocks Iterations II.

Last week at Agile Tour Toronto I had the privilege of working with my friend Paul Heidema to help introduce the basic concepts of Scrum in 60 minutes. This is a really interesting challenge, what’s the minimum amount you can teach people and still give them a taste of Scrum. In end we opted for about ~10 minutes of talking heads (spread throughout), ~30 minutes of simulation time and 15 minutes of debrief.

We invited our teams to create Children’s Books of the Goldilocks story. Along with the basic Story participants were asked to offer advertising, public service announcements etc.

Comments from participants:

• A number said it was surprising how well teams of complete strangers came together after two sprints.
• Several didn’t like the way I set them up for a mini “failure” by not playing the Product Owner role poorly and not communicating my needs. This is a fair point however it does simulate life with a real product owner

Feel free to use this simple simulation to help teach the very basic concepts of Scrum.

Be Sociable, Share!

•