Affinity Diagramming With Multi-voting

Affinity Diagramming With Multi-voting

Affinity diagramming is one of my favorite quality techniques. The technique is useful in any situation that requires generating ideas or getting a team talking. After generating ideas the technique provides a platform for organizing those ideas. I have used the technique for any scenario in which brainstorming would be appropriate, such as requirements definition, solution generation, process improvement and retrospectives. Affinity diagramming is generally a group technique with a facilitator acting as an anchor.

You need:

  1. Sticky notes (square, 3 inches by 3 inches)
  2. Flat surface (wall or other flat surface)
  3. White board/Flip Chart and dry erase markers

The process:

  1. The first step in the affinity diagramming process is for the facilitator to generate a set of framing questions that will be used to elicit ideas, comments or statements about area being studied. For example
  2. The second step is brainstorming. The facilitator will use the framing questions to get the team to generate ideas, comments or statements. As the team members think of a comment based on the framing question, they write the idea on a sticky note, call out what was written and then hold it up for the facilitator to post on the wall or other flat surfaces. Lettering on the sticky note should be able to be read from across the room. The brainstorming process goes on until the team has exhausted the subject or the time box is used up. Small sticky notes are used to ensure that each note contains a single, short idea.   Typically a team of 5 – 9 can generate 50 to 100 sticky notes during a 30 minute brainstorming session. The facilitator should ensure everyone participates. The facilitator should shift the seed questions as idea generation slows down.
  3. After the competing of the brainstorming phase, the team goes to the wall (or other surface) and re-arranges the sticky notes without conversation. The goal is to discover the relationships in the data. Time box the mute mapping exercise to about 1/3rd of the time of the brainstorming phase. A team is done re-grouping the data when everyone sits down or one item begins shifting spots without other changes. The facilitator should ensure everyone participates without talking. While atypical, not all items will be able to be grouped. Occasionally one or a few ideas will be outliers.
  4. After completing the mute mapping, the facilitator should walk the team through the groups of ideas that have been created. The facilitator begins listing off the entries in the group and then asking the team to name the group. The goal of this phase in the technique is to validate that each idea belongs in the group. The team is free to move notes to the groups if they fit better somewhere else.

Affinity diagramming with mute mapping is a tool to generate and sort a large number of ideas, comments or concepts into a more manageable order. Affinity diagramming is good for decision making, generating an initial product backlog, generating personas for user stories and retrospectives. Affinity diagramming with mute mapping might not be as versatile as duct tape, BUT it is close!

One persona or many?

One persona or many?

Fleshing out the user needs is one of the most critical steps in the process of generating an Agile Story Map.  Sometimes it is easy to jump over the creation of user needs and the stories that are needed to satisfy those needs, and jump directly into the mechanics of building the Story Map, but you will not derive the same value in the end. Personas are an oft-practiced tool used to  help you focus on the generation of user needs and stories.

What Are Personas?

Personas are a metaphor for groups of systems users that were originally introduced by Alan Cooper. Roman Pitchler later suggested a template for a simple version of personas, which included: the persona name, a picture, behavioral characteristics, and business needs.  The first two categories help define the “who” part of the persona, while the rest describe the “why,” i.e. why the person would use the system. The concept of personas is used widely, inside and outside of IT.

The information used to define a persona varies by how the persona is going to be used. Thus there are many other, specialized versions of personas that include other data.  Examples of the other data include: capabilities, attitudes, involvement, age, location, likes and dislikes and technical comfort – just to name a few. I strongly suggest that persona you use be only as complex as it absolutely has to be. Use only the data that is relevant. For general IT projects, I generally use Pitchler’s template and then add location and technical comfort. (We will revisit this concept when we discuss gamification. There more complex personas may be needed.)  Always include a picture when defining personas.  Pictures help to draw in visual learners While I am not an artist, I feel that a hand-drawn picture is better than a photo to reinforce the idea that a persona rarely represents a single person, but rather is a metaphor for a group.

Mining or Defining Personas

Many Agile teams use User stories to delineate pieces of work.  User stories follow a pattern of “As a <user type>, I want to <function> so that I can <business value>.”  User type can be considered as generic starting point for defining a persona. If you use user stories, isolate the user types, group like user types together, give them a name and then complete the template for each persona.

Another place to start, if you have been using use cases, is to gather all of the “actors” that have been identified.  As with user types, group like actors together, name them and complete the template.

If you are not using use cases, user stories or any other user-centered documentation methods, start with a brainstorming workshop to identify the types of users and personas you and the software will be interacting with.  To help the session along, I use seed questions such as:

  • What departments will use this software?
  • What types of users roles are there?
  • What customers will interact with the software?
  • What are the goals type of customer trying to accomplish with the software?

When you have completed the brainstorming session use mute grouping (affinity diagraming) to cluster the roles.  Then name each distinct group and complete a persona template for each.

In Agile, personas are a tool that is used in many situations, such as developing user stories or generating an Agile Story Map. They can be used to focus the discussion of requirements, needs and stories on the types of people that will be interacting with the project or application. Because personas are named and tied to a picture, they are far less impersonal. It is easier for team members to feel a relationship.  The ability to relate to the people that the persona is a metaphor for improves our ability to put ourselves in their place and discover their requirements and needs.

Crowd sourcing is a key retrospective technique.

Crowd sourcing is a key retrospective technique.

Even though there are many different techniques for executing retrospectives, many teams find one or two techniques they like, and then they ride that horse until it collapses.  As we noted in Retrospectives: Obstacles, every Scrum Master and team should have a broad array of retrospective techniques, such as the sailboat technique, the Four L’s or the timeline.  This provides at least two benefits. First, knowing many techniques means that you can match the technique to the particular teams. For example, many techniques use physical sticky notes, which are difficult for distributed teams. So, the Scrum Master needs to know that you can substitute an on-line mind mapping tool for sticky notes.  Second, having a wide range of techniques (and using them) is a formula for beating technique fatigue and the resulting obstacle.

List generation techniques are the most popular class of retrospective techniques.  The list generation techniques are popular because they take very little set-up, are easy to explain, easy to facilitate and get results. Listing techniques build on well understood brainstorming techniques to ensure the whole team has a voice.  Before, we described how to do a retrospective using a simple listing and grouping technique, also called Affinity Diagraming.

Another technique in the listing category would be the Sailboat technique.  This method uses a nautical metaphor.  The boat moves through the water toward a goal (the team delivering functionality), the wind pushes the boat forward.  As the boat moves through the water, it encounters resistance which slows its progress. Examples of resistance might include conflicts for needed resources or conflicting organization goals.   Here is the process:

  1. Set-up: Start by drawing a picture of a sailboat in the water on your white board or flip chart. Explain to the team that some things push forward, like the wind, and some things slow your progress down, like an anchor.
  2. Idea Generation: Ask the team to identify what those items were.  List one item per sticky note, which are then placed on the boat.  As a facilitator, I will continue to tweak the seed questions I am using to keep the team thinking about the sprint from different angles.  You are done when the team is done.
  3. Insight Development: Have the team review the data and group ideas based on how they see the relationships between individual ideas. Techniques like Mute Mapping (grouping without talking) help to maximize team participation while minimizing the chance of a single person dominating.  Once THE grouping is done, I typically ask the team to name each group. This helps to cement the group’s understanding of the groupings of ideas that they have generated.
  4. Identify Improvement Objective: Select a group or specific idea to fix.  There are a number of techniques to select the improvement objective. Discussion followed by group consensus is one method (I use this when it is apparent that the group is close to consensus).  Another method is to vote using dots or post-it flags. In this method give each member a fixed number of flags and then ask them to vote (they can use all votes on one item or spread them).  The item or group with highest number of votes gets fixed first.

Examples of other listing techniques include:

The Four Ls – Use four categories: liked, learned, lacked, and longed for to generate ideas. Write these titles on four flip charts and place around the room.  Have each person silently generate ideas based on those categories.  When the team is done (i.e. everyone stops writing) have the team place their ideas (written on sticky notes) on the appropriate flip chart. Once the team has come up with their lists, identify the improvement objective, usually from the lacked or longed for category.

What Went . . . – Use four flip charts, put one of the following titles on each flip chart: what went well, what did not go well and what should we do more of and what should we do less of.  Brainstorm ideas to put on each flip chart.  Put one idea or statement on each sticky.  Depending on the group, this method can be done non-verbally (everyone puts their ideas on a set of stickies like the Four L’s) or have the team write ideas down and then shout them out (more akin to classic brainstorming). Insight development and identifying the improvement objective would follow a similar path to what was described above.

There are many other listing techniques each using a different set of seed questions (e.g. What worked well? or What would you like to do more of?) or different metaphors (e.g. sailboat, motorboats or trees). The questions or metaphors exist to help the team focus their discussion.  The metaphor or seed questions that are used need to make sense to the team’s culture, and also solicit areas that they are concerned about or can be improved. The Scrum Master or facilitator needs to use their observations about the team to select the retrospective technique that will provide the greatest benefit . I have seen teams of engineers that did not like using techniques that used metaphors (like the sailboat), while a UI team I worked with loved techniques that used metaphors. All of these techniques can work selecting which you will use is matter of team culture.

We will discuss techniques that are not list based here.

Related Entries:

Retrospectives: A Basic Process Overview

Retrospectives: Retrospectives versus a Classic Post-Mortem, Mindset Differences

Retrospectives: Obstacles

Retrospectives: Non-listing Techniques

Retrospectives: A Social Event