Easy Agile Team

Brainstorming as a group can generate a ton of ideas, but what do you do with all of those ideas after you’ve come up with them? How do you organize an entire team’s ideas? How do you narrow down the best solution? And how do you document the ideation session so you don’t lose any data? Never fear — affinity mapping is here. 🗺

Affinity mapping is an agile technique that helps teams reach a consensus after a brainstorming session, usability testing, or user research survey. It’s most helpful when you have a large amount of data to sort and when you need to distill all of that data into specific solutions the whole team agrees on.

Continue reading to learn more about affinity mapping, including when to use the maps, the benefits of affinity maps, and how to run an affinity mapping session.

What is affinity mapping?

Affinity mapping is an agile technique used to solve problems by distilling many ideas into the best solution or path forward. The exercise is designed to quickly get teams on the same page about a problem that needs to be solved.

Typically, affinity mapping occurs after a large group brainstorming exercise during which many team members and sometimes clients or stakeholders have given their input.

All of the team's ideas are added to sticky notes, which are organized somewhere for everyone to see. The team groups similar solutions until natural relationships form. Everyone involved in the session is able to see various paths forward, which can be discussed and narrowed down to the best solution.

Try affinity mapping whenever:

• A problem needs to be solved as a group
• The team has struggled to reach a consensus
• There’s an issue or problem that’s too complex or tough to grasp
• You need to reach one solution that everyone on the team will buy into
• Large amounts of data need to be sorted
• Data or survey results need to be analyzed
• A project or product is in a state of chaos

The activity sparks initial discussion on problems that are best solved by many minds coming together and agreeing on a course of action. Affinity diagramming is typically used in user experience design, UX research, and design thinking industries, but the practice can be implemented by any team that wants to distill information.

The benefits of affinity mapping

Affinity mapping provides a number of benefits for teams that need to solve a problem, sort large amounts of data, or reach a mutual consensus.

Affinity mapping helps teams:

• Prioritize what’s most important
• Unlock ideas that hadn’t been considered before
• Discover the “real” problem
• Work together to solve a problem (team building)
• Empathize with users or customers on common pain points
• Utilize multiple minds
• Reach a consensus together
• Make decisions without using up too much of anyone’s time
• Establish a safe environment to flesh out touchy or conflict-fueled discussions
• Facilitate equal participation, even from those who speak up less
• Involve stakeholders and clients in the discussion and agile process

The step-by-step process for affinity mapping

You can use affinity diagrams for a variety of reasons. They are commonly used to sort a large number of ideas after a brainstorming session or to make sense of data after usability testing, user interviews, or other user research.

Brainstorm ideas or collect data

The first step (or preemptive step) to affinity mapping is collecting your data points. If you are trying to solve a problem or make sense of a project, this will involve running a brainstorming session as a group. Make sure everyone starts solo when brainstorming to ensure no one is influenced by other people’s ideas before they’ve come up with their own.

It can help to frame whatever problem you are trying to solve into a “how might we” statement. For example, “how might we get younger audiences to use our product” or “how might we double last year’s sales goals.”

If you’re working with research findings for your session, you instead need to transcribe all of the qualitative data so that it can be organized and sorted during the mapping session.

Post the ideas or data for everyone to see

Take all of the ideas everyone came up with and put them on individual index cards, or use a separate sticky to represent each point on a whiteboard or wall. It’s important the surface you choose is visible to everyone.

Begin grouping data

As you add each point to the main wall, sort them into related groups. Organize the clusters naturally, combining or separating clusters as branching ideas form.

Don’t discard any duplicate thoughts, as these will help you visualize how popular an idea is. Continue to add to the board until every sticky note or card has a reasonable place on the visible wall.

Use a “parking lot” for ideas you can't sort

Create an area along the side of your wall called a “parking lot” for any ideas that don’t fit into a cluster. As you continue to build and sort the board of ideas, you may find reasonable spots for them.

Assess and name each category

Assess your clusters. Are there any clusters too similar to one another that could be joined together to create a larger group? Are there any clusters with too many branching ideas that should be separated into smaller groups?

Once you’ve completed your sorting and thematic analysis, it’s time to name each category. Don’t take too much time on this part. The category name just needs to generally describe the ideas inside the cluster. If you need to, vote on the best name to ensure too much time isn’t spent debating.

Vote and make decisions

If you’re analyzing a collection of data, you can now document the findings. What categories have the most data points? What connections do you see between clusters? What observations can you make from common themes?

Before dismantling the map, ensure you document everything with photographs so you can go back to the affinity map at any time to gather more insights.

If you’ve arranged ideas from a brainstorming session, it’s time to discuss the possible solutions and vote on the best option. Placing each solution category on an impact effort matrix helps the team visualize where their effort would be best spent. You can also work through different forms of voting, such as dot voting or the hundred dollar test.

Affinity mapping for remote teams

Many of the teams and businesses we work with are remote, which means getting into one room to collaborate around a bunch of Post-its isn’t an option. Luckily, there are plenty of online tools that make affinity mapping possible for remote teams.

You can create an affinity diagram template and follow nearly all of the same steps for affinity mapping by using online collaborative design thinking tools like Mural.

Affinity mapping brings teams together for a collaborative experience. It’s a simple process that ends with a consensus around the best solution or path forward. It’s especially helpful for complex problems, bottlenecks, or times when the team needs to get on the same page.

More From Easy Agile

Easy Agile is passionate about helping teams work better. To us, that means working more efficiently, effectively, and collaboratively. If you want more agile articles and how-to guides like this one, follow the Easy Agile blog for our latest content.

We build products specifically designed for Jira users to help agile teams collaborate using buyer personas, roadmaps, user story maps, and more. Our tools are simple to use and integrate directly with Jira for seamless product development. Try any of our plugins free for 30 days.

It's a Monday morning and I’ve just pulled into the Kiama train station carpark.

It’s a short commute to the Wollongong CBD, where I am greeted by the team as I enter the office.

We start the day with a morning huddle in which each of us shares something good that’s happened during the last 24 hours, what we’re going to be working on that day and whether we’ve come up against any blockers.

The entire team then takes a walk down to local cafe, Beast, and get a coffee together. It’s a wonderful way to start the day, with a group of inspiring people.

For me, customer support is up next and I am super keen to get into helping our customers on their day’s journey with our product. My past experience in customer support has shown me just how much customers appreciate timely and helpful responses. It can really change a person’s day.

When customers have been responded to, I continue with my daily work using Easy Agile tools. I can say for sure this does make managing and working through sprints much easier.

I’ve got great team mates; if I want to discuss something, get some feedback or pair up, my colleague Matt is always there to help. Here he is:

He is genuinely an advocate for software craftsmanship and I'm totally onboard with this approach.

Around noon, we all stop for lunch. Some of us will get takeaway from the local mall, and others will bring something from home, but generally we all sit together and enjoy each other's company. On Fridays the street market draws the attention of most of us. There will usually be a session on the Switch - Mario Kart or Smash Bros the most popular choices.

It’s back into things after lunch and I have a check-in with Dave to see how things are going. We discuss my journey so far and what my ideas are for our upcoming inception week.

It's great to be able to sit down and talk about how we can make our systems better and improve the day-to-day work for our team.

There’s a few more things to get done and then it’s time to head to the station for the commute home. Matt and I chat about software architecture and almost miss the train.

When I look back over the last couple of weeks at Easy Agile, what stands out is the culture and the values of the team.

The commitment to integrity, honestly, inclusion and work philosophy is truly inspiring and uplifting. Never in my experience have I started a work day where everyone shares something positive. it really sets the tone for the following hours.

Easy Agile is an amazing company, especially when I compare it with my experiences over the last 20 years in manufacturing, customer support and software development. The team at Easy Agile practically demonstrate a holistic approach to both work and life which is equally refreshing and encouraging.

We all know writing unit tests is important but sometimes it feels like it can take up more time than the feature work itself. I’ve found a couple of handy hacks that I feel have increased my speed when writing tests whilst also improving their quality and, being the kind fellow I am, I’m going to share those with you:

Hack 1: Use Testing Playground

I guess the first tip in this article is - use Testing Library. I didn’t make this its own point because it is already so popular. But if you are not using it yet, make sure you do!

Unit testing with Testing Library is really easy and intuitive. Despite this, it can still be challenging to find the right queries or to understand why an element isn't being matched.

Enter Testing Playground.

Testing Playground allows you to render a component in a sandbox providing you with direct visual feedback of the component. It also allows you to interact with the rendered component to come up with the best queries to select elements. And, like Testing Library, everything it does is with accessibility (a11y) in front of mind so it teaches you about the importance of a11y and best practices while you use it.

There are many ways you can use Testing Playground including a chrome extension and a browser based app.

The best way I have found which has been an absolute time saver for me though is by invoking screen.logTestingPlaygroundURL() right from the test block itself. I usually find myself doing this as soon as I get the component rendering, just to get the lay of the land and work out what parts of it my test might like to interact with.

Hack 2: Use test.todo

Please don’t jump down my throat, but I have tried Test Driven Development and didn’t like it. Like anarchism, I think it sounds awesome in theory, but found that it actually slowed down my development cycle when I tried to implement it.

I still like the idea of getting some thinking about testing down before I finish building a feature though and have settled on a process that, for me, seems to work well and keep my development moving along.

I now use Jest’s test.todo to record what I am going to test as I am planning to and building out a feature (Big thanks to Karl for first introducing me to the idea!).

My usual process goes a bit like this. First I capture the requirements spelled out for me by my awesome Product Owner (Hi Biz!) in test.todo form, like a todo list. Then, as I am building and encounter other edge cases and important testing areas I add these as test.todo’s too. That way, when it comes to testing time, I have thought through a lot of what I am going to test and am less likely to miss testing edge cases or important functional requirements.

A simple example for a test.todo for the following <UserDetails /> component:

import React from "react";export interface User {  firstName: string;  lastName: string;  username: string;  emailAddress: string;  SEN: string;}export interface ShowHideUserDetailsProps {  showDetails: boolean;  user: User;}const UserDetails = ({ showDetails, user }: ShowHideUserDetailsProps) => (  <>    {showDetails ? (      <div>        <h1>User Details</h1>        <ul>          <li>{user.firstName}</li>          <li>{user.lastName}</li>          <li>{user.username}</li>          <li>{user.emailAddress}</li>          <li>{user.SEN}</li>        </ul>      </div>    ) : (      <div>        <h1>Privacy Protected</h1>      </div>    )}  </>);export default UserDetails;

Might be as follows:

describe('<UserDetails />', () => {  test.todo('Should show user details when show details is true');  test.todo('Should NOT show user details when show details is false');});

Hack 3: Use builder functions

I used to find myself creating objects for each test to mock out values for testing. Then I wrote another component which used the same object and mocked it out again there. There’s got to be a better way, I thought. And Matt Smith at FinoComp introduced me to one.

I now use builder functions which return commonly used object types in testing and which allow properties to be overridden everywhere. There is certainly a little bit of extra time needed to set them up but I find that, once they are done, the next time you have to interact with that object you are so glad they are there.

// Example typeinterface User {  firstName: string;  lastName: string;  username: string;  emailAddress: string;  SEN: string;}interface ShowHideUserDetailsProps {  showDetails: boolean;  user: User;}// Builder pattern to build a mock object for the// ShowHideUserDetailsProps typeexport const buildShowHideUserDetailsProps = (overrides?: Partial<ShowHideUserDetailsProps>): ShowHideUserDetailsProps => {  const defaultShowHideUserDetailsProps = {    showDetails: false,    user: {      firstName: "Jazmyne",      lastName: "Jacobs",      username: "Kylee_Skiles37",      emailAddress: "Rashawn13@gmail.com",      SEN: "SEN-123456"    }  };  return { ...defaultShowHideUserDetailsProps, ...overrides };};

There are some limitations to this pattern however as they become less useful with deeply nested object types. Additionally, they do require some upkeep when object types change in the codebase which brings me to my next point...

Hack 4: Use a tool to mock your Typescript types

Look, I’m going to be straight here. This is the part where I plug my own work but at least I left it for last, right?

Whenever I found myself creating another mock object for testing I kept looking at my Typescript types and thinking, can’t something look at that and do it for me? This sent me down a search for a solution and I was so stoked to find intermock which is a command line tool that does just that. While it is still a work in progress and has some limitations I have found it super helpful when writing tests.

I did find using the combination of the CLI and copy/pasting from the terminal a little cumbersome though. How could I make this even easier I thought.

Enter my VSCode extension, Emulative. Simply select your type name, run a command through the Command Palette in VSCode and you can use Emulative to produce Typescript objects, Json objects or the aforementioned builder functions from Typescript types. These are automatically copied to the clipboard but the plain objects can also be sent to a new scratch file.

But wait, there’s more! Where I work at Easy Agile we have a bunch of properties we work with from Jira which aren’t accurately represented by string or number. With Emulative you can set up key/value pairs which will overwrite any matching properties which are found in your types.

Shout out to Easy Agile for giving me the time, resources and encouragement during an Inception Week to work on Emulative!

Well, that’s it for me, I hope you find some of these tips and tricks useful for speeding up front end testing.

Either way please feel free to sound off in the comments about nifty tricks you have found to improve your unit testing speed (or just how wrong I am about TDD).