Don't Etch your User Story Map in Stone

I was having a chat with Adam Yuret last week about user story maps. A concern that he expressed and others have voiced is that by putting your ideas into a user story map it might discourage you from changing the map as you start delivering the stories and learn more information. He's right - it might and it probably does. Kent Beck recently expressed a similar concern about product roadmaps on twitter.

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review – SmartViewApp
* Story Maps - A Testing Tool After All

So, here is your reminder that your map isn't just a list of features, but is really a list of unvalidated ideas. Whether you are working on a startup or an enterprise project, you begin with a list of questions or assumptions. Here are some examples:

• Will anyone use it?
• Will anyone pay?
• Does anyone care?
• How will we make $?
• Can we build it?
• Do we understand the problem?
• Will this solve the problem?
• Will it perform adequately?
• Will it integrate with other applications successfully?
• Can we build this with the budget & schedule we have?
• What is the best architecture for this project?

When you build and prioritize your map, you should be doing so with these questions in mind. As you resolve each of those questions, your map should change. It is one of the great reasons to put your map on the wall using post-it notes instead of putting the map into a tool - post-it notes are easy (and fun) to move. (Aside: Yes, there are sometimes excellent reasons to put things into a tool.)

Two quick stories to illustrate:

At a recent Agile Winnipeg event a local company (UnionWare) told a story of how they are using story maps. They had an idea for a project and quickly built a story map around that idea. At their customer conference they reviewed their ideas and realized they had missed the mark. They quickly (and easily) adjusted their map to confirm with their customers the new priorities and direction before they had even started building anything. The map itself was enough to help them walk through some of the questions above. As they told this story, their CEO recounted how he thought to himself: "This visualization stuff, it's going to be good."

For a project that I worked on this year we built a large map outlining all of the stories. We spent time going through the map with our customers slicing, scoping, prioritizing, identifying risks and assumptions, etc. We were pretty proud of the result and eagerly started delivering. As we started working on the first small release, we quickly realized that the answer to one of the main questions "Can we build this with the budget & schedule we have?" was "no". At this point, we had conversations with our users and sliced, scoped, and prioritized even more so that we could deliver something that would still meet the goals of our upcoming deadline.

In summary, "You cannot plan the future. Only presumptuous fools plan. The wise man steers." - Terry Pratchet. Don't etch your user story map in stone - build it with paper and expect to change it as you learn.

Subscribe to Winnipeg Agilist by Email

Visualizing Retrospective Priorities

We tried a new retrospective prioritization/voting technique this week that worked really well. After we had generated and discussed all of our ideas for improvement, it was clear to me that there were several excellent ideas and it would be hard to use our regular voting technique to single out one or two. In fact, it seemed clear that there were several ideas that should all be done and were somewhat related. I decided to try a technique in order to visualize the priorities, grouping, and weighting of the ideas.

I drew a line on the whiteboard from the bottom right to the top left and put all the ideas we had generated in the middle of the board. I then asked the team to approach the board and move the items they believed would have the most impact to the top left and the least impact to the bottom right. Yes, I was a little worried about the priming effect of having everyone voting together but I decided to ignore my own advice this time.

After the post-it notes on the board 'settled into position', we held another brief discussion to confirm the position of the ideas. It was clear that there were several high impact ideas on the board that needed to be implemented right away and some interesting clusters formed at the top left. The position of the post-it notes also visibly identified the ideas that the team thought would have a lower impact and could be dealt with another time.

The final confirmation that this visualization of priorities was effective came later that day - the team met and started implementing their ideas.

P.S. Yet again the 'take it to the team' approach resulted in a better solution than the ones I had envisioned prior to the retrospective. #TeamGenius

Subscribe to Winnipeg Agilist by Email

Q: Why Silence? A: Priming.

I'm a big fan of using silent brainstorming in order to generate ideas as individuals before processing those ideas as a group. "Priming" is yet another reason why using silence is important.

System 1 & System 2.
(Not to be confused with Thing 1 and Thing 2)

I'm currently reading Daniel Kahneman's book "Thinking, Fast and Slow" - a behavioural psychology and economics book that describes his research on how our mind thinks. In the book, Kahneman describes the two systems that make up how we think. System one is the unconscious, fast, intuitive, relational thinker. System two is the conscious, slower, lazier, and more logical thinker. For example, when I ask you what 2+2 is, system one jumps in and gives you the answer of 4. When I ask you what 453 * 23 is, system two jumps in to help you calculate the answer.

One of the experiments that Kahneman describes demonstrates how you can 'prime' system one and influence its answers. The experiment asked people to look at one word and then fill in the blank in a subsequent incomplete word. The first word they were shown was either "Eat" or "Wash" and the second incomplete word was "So_p". When shown "Eat", system one's relational thinking kicked in and people more often said "Soup" for the second word. On the other hand, when shown "Wash", system one more often produced the related word "Soap". Showing the first word to the participants 'primed' system one and influenced it to think of a second word that was related to the first.

So, if you start a brainstorming meeting with "What can we do better? My idea is [X].", you have now primed people to think about [X]. However, if you let people generate ideas on their own first you will start with a larger base of ideas to work with. Once people have written down their own ideas [X,Y,Z], saying those ideas out loud will allow system one to find relational words on the whole set rather than just one idea.

Generate ideas in silence, process the ideas out loud.

References:
- Daniel Kahneman's Book: Thinking, Fast and Slow
- Slides and video from my related talk: The Silence of Agile

Subscribe to Winnipeg Agilist by Email

Facilitating a retrospective with 50 people in an hour

As one of the volunteers at Agile 2012 I was honoured to be asked to facilitate the volunteer retrospective.

There were a few constraints that made this retrospective challenging. First, due to our volunteer responsibilities we had just under an hour to eat lunch and complete the retrospective. Second, there are about 50 volunteers - allowing everyone to have a voice in such a short time frame would be a challenge. Third, it was important to all of us to celebrate the things that went well and also give a clear, prioritized list of ideas to future volunteer teams.

After discussing the constraints and various facilitation options with some of you, here is what we did:

1. Instead of building a timeline of our experiences we held the retrospective in our volunteer room. Throughout the week we had plastered the walls with our schedules (including happy/sad faces), guidelines, issues, ideas for improvement, etc which then served as visual provocations for the retrospective.

Picture courtesy of Adam Yuret

2. We used silent brainstorming liberally in order to speed up the retrospective while still including every voice. In general we followed the Rising Patton Fusion retrospective model that combines silent brainstorming, silent grouping, and silent voting.

3. We split into 5 groups of 10. Each group would perform a retrospective step together before sharing their results with the larger group.

4. The two major prompts we used in the retrospective were:

The combined 'greats'

- "It was great because...". Each table wrote these in silence, read them out loud to each other, grouped them in silence and then named the groups. The named groups were then shared with the rest of the tables and consolidated into one larger list.
- "Do differently". Once again, each table wrote these in silence, read them out loud to each other, and then voted in silence. The top 3 items from each table were again shared with the rest of the tables and consolidated into one larger list.

5. Finally, we posted pictures of all the results (yes, every single post-it note) on the Agile Conference Volunteers Facebook page for later reference and comments.

It was a lot of fun and seemed to work well given the constraints. We achieved our goal of giving everyone a voice in a short time period, celebrating what went well, and also producing a nice list of actionable ideas for next year. Anything you would do differently?

Subscribe to Winnipeg Agilist by Email

In pursuit of better, not best

I realize that many of you already scowl when you hear anyone talk about 'best practices'. Instead of adding to that discussion, I'd like to share a short story with you about someone who influenced me to keep looking for better and to never assume that I've reached 'best.'

I can still picture Mr. Loewen leaning on the desk at the front of my grade 9 class and settling in for a speech. The tone of his voice and even his posture indicated that what he was going to say was important. I think I expected a lecture on the importance of the subject, paying attention in class, working hard at the assignments, or being respectful to the teacher. Or maybe he was going to give his 'outstanding student' joke - students who crossed the line would end up 'out standing in the hallway'. Instead, he confessed to us. He confessed that he didn't know it all. Of course I can't remember the exact words, but it went something like this:

"In this course I'm going to teach you what I know to the best of my ability. I'm going to tell you truths as I understand them today. But, someday you will encounter ideas and truths that might make more sense than what I have taught you in this course. You will discover that some of what I have taught you is wrong. When you encounter those ideas, embrace them. And even as you embrace those new truths, remember that you, also, might be wrong again."

Those words sat with me for a long time before I saw the wisdom in them and embraced them. They have served me well and taken me through some challenging times. Thanks Mr. Loewen.

Subscribe to Winnipeg Agilist by Email