Stories to Stories

In agile software development, “user stories” acknowledge the importance of the user but how can we know that the needs the stories represents are genuine and valuable? I’ll be looking at how user stories can be improved by using mental models to align them with real behaviour.

On the flipside, I’ll also consider how generative user research can benefit from a lean approach and show that many of the techniques are similar to those used in a typical agile project.

This talk is aimed at anyone who is looking for practical ways to bridge the gaps between traditional research and agile practices by focussing on activities that hold common value for both.

Transcript

1. Stories to Stories @stuartcurran #storiestostories I work ThoughtWorks, an agile software consultancy. I have been with them for just over a year now and this has been my first experience of working in an agile environment. Before, joining ThoughtWorks I had worked in a many different agencies in many different roles and had only observed agile from a distance.
2. Agency to Agile http://www.flickr.com/photos/9778048@N06/5854181266/ What I often saw usually confirmed the many arguments I had read that UX and agile didn't mix well. So what surprised me when I joined ThoughtWorks was how painless I found the transition between the two. Having been focussing on user research for many years, I found that many of the agile techniques I encountered shared similarities with those I was already using.
3. What Do Customers Want? Image by sleepy chan This talk is about the common ground between UX and agile. Because fundamentally we want to answer the same question.
4. Avoid Poor Decision Making And we want to help our clients in the same way. So I am deliberately looking for ideas and ways of working that I believe are already shared between UX and Agile in the hope that this will go some way to demonstrating they are already closer than we think.
5. What Do We Have in Common? http://www.flickr.com/photos/bellatrix6/3773105694/ So what exactly do UX and Agile have in common? • They often use the same language to describe things. • They use similar processes to figure out what we need to do. • They use similar tools to organise ideas and data. • They use similar activities to plan our projects. • They both benefit when they share their best practices.
6. Customer & User Two Kinds of Stories I‘ve focussed this presentation around stories for two reasons: • The first is that the use of the word stories was my own lightbulb moment for starting to think about the something that ux and agile have in common. • The second is that stories are a good place to start as they represent the fundamental building blocks for shaping experiences in both the ux and agile worlds. We break stories down in when doing research then build them up again when designing software.
7. Customer Stories Customer Stories The first kinds of stories are what I'll call "customer stories". I’ve always liked the word customer as it implies a certain deference necessary to avoid arrogance in design. By "customer stories" I mean the sort of first person descriptions of experiences that you hear when doing research. Customer stories are real stories, not made up. Typically, the stories that result from interviewing customers are captured in writing somehow whether it's someone taking notes as they listen or a written transcription from an recording.
8. "The film was incredible but the use of 3D was utterly pointless. Having said that, the massive glasses were useful for disguising my tears during the bit in the furnace. I think 3D technology is a horrible thing. This was confirmed for me during the trailers where literally every movie was an animated movie about an animal overcoming some sort of ridiculously contrived plight, but wait IT'S IN FABULOUS 3D!!! "And, also, when I went abroad in April, there was a Man City game against Arsenal and I wore my shirt to bed because I just thought, “We have to win this game,’ and we won. Arteta scored at 90 seconds, a minute, so that was good for us, but then we lost the next week to a team at the bottom of the division, so I wasn’t impressed either. So, it’s swings and roundabouts. "It was the day of the royal wedding and having been stuck in all day watching the ceremony on TV, I was determined to get outside and join in the party. I called up one of my mates and he was keen to join. As I live in Brixton and he lives in Roehampton we decided to meet on middle turf, Putney - a place we also both know more than anywhere else in London. We found an exclusive pub down by the Thames and drank our next pint of lager with pride.... this one was for the royal couple!" I researched the journey online and via my phone. Thankfully, it was very straightforward and I could memorise it - whenever I give my wife a Google map on my iPhone to navigate with, she presses the wrong button and gets annoyed that she doesn't understand how it works! Customer Stories Football Cinema Holiday Going Out Here are some fairly random excerpts of customer stories from various projects I have worked on. There are a couple of things to note about these examples: • The first is that the language is raw and unfiltered not contrived. There is always a sense of the person behind the story, something that only comes from an extended account of their experience and not something that is so easily captured in a survey or a Q&A. • They are often entertaining too. One of the privileges of doing research is that it's fun listening to people. The empathy you feel comes naturally and isn’t forced. It's important to hold on to this feeling when your role involves representing the customer's point of view throughout the design and development process. I should also point out that I'm not solely interested in researching movies, football and beer despite the content of these quotes.
9. User Stories The second kinds of stories are more formal. "User stories" are the building blocks of any agile project. A user story is a short description of the who, the what and the why for a given bit of functionality to be developed. Usually handwritten on index cards, these stories use everyday language to describe some piece of desired functionality from the perspective of an end user. They need to be easily understood and interpreted by anyone within the business or project team and provide an understanding of what the customer requirements are without any need for formal documentation. If you have ever had to write lengthy specifications as I have, you really appreciate being able to break down functionality into smaller more manageable pieces.
10. User Stories As a... USER I want... GOAL So that... BENEFIT Let's look at the sentence in a user story is constructed you can see the component parts. • The "user" is the subject, a person, a role or customer segment for whom the feature is intended. • The "goal" is what they are trying to achieve in the context of the domain we are considering. • The "benefit" is the value that the user derives from the successful execution of activity in pursuit of that goal. They can be written from day one of an agile project, loosely and often when an understanding of the requirements is still emerging. Often these can take the form of just a few words as a placeholder for a future conversation as it's expected that these will be subject to revision at a later stage and a more detailed description written in this format as and when it is needed. A “placeholder for a conversation” is how agile folks refer to user stories in general, a reminder not to let user stories become documentation by another name.
11. http://www.flickr.com/photos/lwr/1788112624/ Combing & Grooming Analysing & Optimising Stories Analysis is an example of a process that is applied to stories in both UX and Agile. Analysis of customer stories and user stories may differ in execution but the goal is the same, to try to finesse something raw into something more structured. UX and Agile also use similar salon-inspired language to describe the process of analysing stories.
12. Combing for tasks When you analyse the transcripts of interviews with customers in order to find examples of behaviour this is often referred to as “combing”. A story can be broken up in to sentence fragments that represent individual behaviours. These are then carefully rewritten to include verbs necessary in order to turn them into tasks. Once you have combed through an entire transcript you end up with lots of these tasks that you can start to analyse in more detail.
13. Grooming a Backlog Grooming a backlog What is a backlog? A backlog is a collection of all the user stories for a given project. Stories can be added, removed or merged but it always the source for the any story to be “played” in development. When you have a backlog of user stories, it's important to make sure that the descriptions of these stories, the supporting narrative and acceptance criteria are as well written as they can be. This kind of activity is often referred to as "grooming". Grooming stories in a backlog can also involve making sure that the stories are sized correctly, that any new learning has been integrated such as the results of user testing and that the right stories are being considered for any upcoming releases.
14. http://www.flickr.com/photos/vpickering/8050256513/ Grooming stories is typically performed by a product manager or business analyst but increasingly this role is also being filled by a UX person. At ThoughtWorks we are finding that there is a need for a hybrid UX/BA role, people that understand customers needs and business requirements. Given the focus on analytical skills, UX people with a solid grounding in IA are perfectly positioned to fill these roles and thus have much greater influence on the delivery of agile projects.
15. http://www.flickr.com/photos/leehaywood/5047795864/ Modelling & Mapping Organising Stories with Diagrams Let's bring things back to more familiar IA territory and look at the tools we use to organise our stories to look for patterns and meaning.
16. Mental Model example by Indi Young Mental Models I'm a huge fan of mental models as a way of visualising user research. For those of you who are not familiar with mental models I suggest you read Indi Young's brilliant book available in the foyer. Essentially, a mental model is a type of diagram that allows us to look for patterns in the lists of tasks that we derived from our customer stories. Tasks are arranged into groups and those groups are further arranged into higher level mental spaces that represent common groupings of tasks. Once you have this, it's possible to map content and features against the model to identify opportunities and gaps for further evaluation and consolidation into design artefacts such as sitemaps, wireframes, feature descriptions.
17. http://uxdesign.smashingmagazine.com/2012/04/23/mental-model-diagrams-cartoon/ Mental Models - the Comic Some further reading if you are lazy... sorry... pushed for time, go for comic book Indi, a great one page comic strip introduction to Mental Model diagrams.
18. Building a mental model Here is a quick ugly slide on the mechanics of how this works: 1. Analyse transcripts for behaviours 2. Break into individual fragments 3. Turn this into a task by finding the verbs - the most important and difficult step 4. Group similar tasks into groups of tasks 5. Group tasks into higher level mental spaces
19. Story Maps © Jeff Patton, all rights reserved, www.AgileProductDesign.com Another kind of diagram from the agile world is the story map. Story maps are a way to organise user stories in agile project in order to explain the overall goals of a system that is being developed. Although individual user stories allows teams to measure and maintain a constant flow of work, the usefulness of the user story as a way to communicate customer needs diminishes when it is taken out of context.
20. "Arranging user stories in the order you’ll build them doesn’t help me explain to others what the system does." Jeff Patton The story map was first developed by Jeff Patton in order to solve this communication problem inherent in a flat story backlog. The first time a colleague introduced me to a story map on a wall at a client's office, he mentioned how similar they looked to mental model diagrams. In fact, Jeff based the idea of Indi Young’s Mental Models.
21. Seven Samurai management and planning tools Both UX and agile use a common tool to represent information in a visual way so that people can make sense of it, the affinity diagram. An interesting fact about the affinity diagram - it was one of seven management and planning tools developed by the Union of Japanese Scientists and Engineers in 1976 to promote innovation, communicate information and successfully plan projects. There is something of a common heritage here as many of the concepts used in agile also have their roots in Japanese innovations, think of the Toyota Way, Kanban etc.
22. The Affinity Diagram Idea Idea Idea Idea Group Idea Idea Idea Idea Group Idea Idea Idea Idea Idea Idea Idea Idea Idea Idea Group I’m sure I don’t need to tell you that affinity diagrams are just about the most useful tool you have. If you aren’t convinced I have celebrity endorsement for you. I was lucky enough to meet and talk with Dave Gray, co-author of Gamestorming at an event organised by Tim Caynes, Like a true fanboy, I got ask him of all the activities in his book what was his favourite? My heart was all a flutter when he said Affinity Diagrams. Again if you haven't read Gamestorming, I would urge you to do so as it has loads of activities for group facilitation and discovery something that will serve you very well on agile projects.
23. Mental Space Task Group Task Group Task Group Task Group Task Group Task Task Task Task Task Task Task Feature Feature Feature Feature Feature Content Content Content Content Content For comparison, here is a simplified version of our mental model diagram.
24. Feature Story Story Feature Story Story Feature Story Feature Story Goal Goal Story Story Story Story Activity Activity Activity Activity Activity Feature Story Story Story And a story map.
25. The Story Wall Another diagram that it is important to mention as an aside is the Story Wall used to represent a teams workflow on a project.
26. http://www.flickr.com/photos/distan/5144708015/ MoSCoW to M.V.P. Stories in Prioritisation & Planning We’ve looked at a common tool we use to make sense of stories. Look at how each of them are used and the kind of activities used to prioritise and plan.
27. Mental Space Task Task Group Task Task Group Task Task Group Task Task Group Task Task Task Group Task Feature Feature Feature Feature Feature Content Content Content Content Content MUST HAVE SHOULD HAVE COULD HAVE WOULD BE NICE TO HAVE Once you have you mapped some content and features against your mental model how do you decide on what is most important? Typically you would do some kind of prioritisation activity like MOSCOW.
28. Feature Story Release 1 Activity Activity Activity Story Feature Story Story Feature Story Feature Story Goal Goal Story Story Story Story Release 2 Activity Time Priority Story Story M.V.P. This kind of prioritisation is also something we do with our story map. We want to identify what features can be built for a specific release and that will deliver some sort of measurable value to the customer. This is essentially what is meant by the often misunderstood term Minimum Viable Product. I say misunderstood because clients often believe this is just a TARDIS-like container that they need to fit everything into. The important point here though is that if you can successfully prioritise features you are perfectly placed to plan products.
29. "critical... to have the UX person heavily involved in the prioritization of the back log. " Jeff Gothelf I think this is what Jeff Gothelf means when he says this. You need to be part of the conversation to have influence. Incidentally, this isn’t taken from Jeff’s book but from a QA on a recent Spoolcast.
30. Testing & Learning Smarter Stories, Leaner Research http://www.flickr.com/photos/zusician/5431935468/ So far we have considered the common ground that exists between customer stories and user stories in terms of analysis, representation and prioritisation. We have looked at how understanding these activities provides a common frame of reference for a UX person working in an agile context. How do we leverage this to create the kind of strong foundations for agile projects that user research provides? Lets look at the natural pivot points.
31. "because customers don’t know what they want, it’s easy for entrepreneurs to delude themselves they are on the right path" Eric Ries What Eric is talking abut here means is the build, measure, learn cycle. But research provides ways to understand what customers want so we don’t spin our wheels when cycling.
32. Aligning Research & Delivery Spaces Groups Activities Goals Tasks Stories Features Features Mental Model Story Wall Story Map This is an example of how the outputs of our research can input into the agile process. It’s not always going to be a straightforward mapping as we inevitably deal with more than just customer needs on an agile projects. We also need to take into account business requirements, technical constraints, bugs, design debt but for me this would be an ideal starting point as the foundations feel more solid.
33. Writing Better Stories As a first time attendee I want to find my way around So that I can relax and enjoy the conference Using customer stories to tell better user stories. • Take out the user (or developer) and replace with a persona or behavioural group • Use the right verbs to describe the activity • Write the benefits from customer POV
34. Just Enough Research Just Enough Research There are some lesson for research from agile as you can do too much research. The concept of value as used in agile helps keep you lean. In agile you ask What is the value of this story to the business? How much value will this amount of activity deliver to the business? We should also apply that thinking to our research to avoid becoming complacent and wasting our effort.
35. Social stories Socialising Stories Thanks to Daniel Eizans Getting out of the deliverables business is how Jeff Gothelf describes doing UX in the agile environments. Not less work but less time spent documenting work. As long as your research is locked up in documentation, it's not being effectively socialised with the rest of your team. This is an example of a mental model on the wall. If your stories are on the wall, your research should be too, in proximity.
36. Further Reading - Articles • Mental Models: Aligning Design Strategy with Human Behavior http://rosenfeldmedia.com/books/mental-models/ • UX BA Collaborative Workflow http://blog.nanchu.me/post/44833999380/ux-ba-collaborative- workflow • The new user story backlog is a map http://www.agileproductdesign.com/blog/the_new_backlog.html • Mental Modeling For Content Work http://danieleizans.com/2011/11/mental-modeling-for-content-work- an-introduction/
37. Further Reading - Books
38. Cheers @stuartcurran scurran@thoughtworks.com