Accounting for User Research in Agile


User research and Agile are not always the best of friends. Agile development often focuses on building features and breaks down work into bite-sized pieces. User research isn’t always tied to a single feature, which makes it difficult to fit perfectly into two- or three-week increments (the typical sprint duration). How can we fit user research into an Agile framework?

User Research in Agile Is a Challenge

Typically, in Agile environments, user research (such as user interviews, usability testing, and diary studies) is approached in the same way in which the team approaches building new features: by dividing it into bite-sized chunks of work that produce something tangible.

This type of thinking leads to many challenges:

  • Research spans multiple sprints. Teams can’t complete the entire study in a single sprint and the backlog item remains open across several sprints.
  • Research findings aren’t taken into consideration after the research is complete. Teams get feedback from users, but that feedback isn’t funneled back into the backlog to be worked on.
  • There is no tangible artifact that results from the research. Stakeholders and teams don’t know what to do with the learnings that come out of research because they’re used to being handed completed designs or code that’s ready for production.

Because of all these challenges, UX research often ends up neglected or abandoned altogether in Agile environments.

Focus on Outcomes, Not Features

In product development, one of the biggest traps is focusing on outputs over outcomes — that is, discussing what features to build before clearly defining their purpose. This way of thinking prioritizes creating shiny features over understanding the value delivered to users and the business.

For example, an app like Venmo may decide to build a feature to send money to another person so that a user can easily pay someone without cash. The output is the functionality to be built: the Send Money feature. The outcome is what the users get out of it —another way to pay someone. To understand the problems that we’re solving and figure out what the outcomes are, we need to do user research.

One of the main values of Agile is responding to change over following a plan. Teams should focus on continuous discovery — that is, continuous learning — throughout their projects. Research should be the driving force behind this continuous discovery and should be ongoing throughout the entirety of a project. Many teams regard research as a 6-week project or a discovery phase that comes before development and never do research again as the project continues. But they will be more successful in building user-centric products if they aim to do some research every sprint. This way they are always learning and refining their project goals.

Representing Research on the Backlog

Just like with design and development work, we need to represent research efforts on our Agile backlog. When research efforts aren’t reflected on the backlog, they go unnoticed and are inevitably deprioritized — out of sight, out of mind.

To document research on the backlog, follow these steps:

  1. Add the research effort to the backlog as a single backlog item or user story.
  2. Break down the study into bite-sized pieces and add corresponding tasks within the research backlog item.  
  3. As you finish tasks, mark them as done while leaving the research backlog item open until all the tasks have been completed.

Let’s look at an example.

Example: Usability Testing with 6 Participants

For this example, imagine you want to conduct usability testing with 6 participants to learn about how users will (or won’t) use keyboard shortcuts in your application.

To complete this study, you’ll need to complete the following tasks:

  • Recruit and schedule each participant
  • Conduct the session
  • Analyze the data
  • Present findings to stakeholders

For each participant, you add to the backlog separate tasks corresponding to recruiting, scheduling, and conducting the session. Then you can add one or more tasks for data analysis and presenting the findings to your stakeholders. Some teams start looking for patterns at the halfway point of data collection, so they might analyze the data and present some initial findings twice during this research effort.

A Kanban backlog board at the beginning of sprint 3 showcasing three columns: To do, Doing, and Done. In the To Do column, there are several tasks represented. There are no items in the Doing and Done columns.
Representing a 6-user research study at the beginning of the sprint: User Testing: Keyboard Shortcuts is the name of the backlog item; it contains several tasks represented in the To Do column. Since we’re testing with 6 participants, there are 6 tasks represented for any efforts relating to participants. In this case, the team wants to analyze the data and present findings twice.
A Kanban backlog board at the end of sprint 3 showcasing three columns: To do, Doing, and Done. In the To Do column, there are several tasks represented that have not been started. The Doing column has one task open and the Done column has a few tasks completed.
Representing the same usability study at the end of the sprint: At this point, the team has recruited and scheduled 3 participants, is in the process of recruiting and scheduling a fourth, and has completed one usability-testing session.

It’s important to accept and communicate that this research effort will remain open across multiple sprints. This idea is difficult for some stakeholders to grasp, so remind them that research efforts deliver outcomes, not outputs — that is, they deliver goals and needs, not features. Ask yourself if you’re closer to your goal. If yes, then you’re learning — that’s a good thing! In the sprint review you can talk about how the research is going, memorable quotes you might have heard so far, and what is coming up next. This approach will reinforce the idea that research is consistently happening and will continue to build buy-in.

A Kanban backlog board at the end of sprint 4 showcasing three columns: To do, Doing, and Done. In the To Do column, there are still several tasks represented that have not been started. The Doing column has no tasks open and the Done column has several tasks completed.
Representing the 6-user study at the end of the next sprint: All participants have been recruited and scheduled, half of the interviews have been completed, and the researchers have analyzed the first half of the data. The findings that are presented in the sprint review here may include some initial patterns or some other type of progress report.

The halfway point is a perfect opportunity to get stakeholders involved in the process, too! Now that they’ve seen some early feedback, they may want to get involved in the latter half of the research — a first step to making research a team sport. If your study is going quickly, you don’t need a halfway point checkin, but the more transparent you are about the process, the more likely your team and stakeholders are to understand the value it brings to the project.

Once all the tasks are completed in this backlog item, this research effort is considered done and can be closed out.

Update the Backlog Based on Research Findings

After the research is complete, you’ll likely end up with a list of bug fixes, UX debt, potential new features, and opportunities for future research. These should all be funneled back into your backlog — either as tasks on existing backlog items, bugs to fix, or new backlog items.

Bring up this list of items after your presentation of research findings at the sprint review so it can be prioritized and added to the backlog immediately. Since your stakeholders are already present at the sprint review, you won’t need to ask them to attend yet another meeting.

Regardless of how you add incorporate your research findings into the backlog, make sure that you’re acting on them. A team that doesn’t address the feedback received is only discovering new information and not actually responding to change.

Communicating Learnings from Research in Agile

Agile teams know a lot about delivery, but research and continuous learning should be equally important. To overcome the challenges of doing user research in Agile, remember:

  • Research efforts may span multiple sprints. You’re focusing on user goals that will likely influence more than one feature so, during sprint reviews, be transparent about how the research is moving the team forward. Communicating often as the research is being done will build buy-in and common ground.
  • Funnel research findings back into the backlog. Continuous discovery and responding to change are important for building viable software in Agile environments. Make sure that the team not only hears from users, but also responds to their needs.
  • Research provides value to the team in the form of learnings rather than tangible artifacts. Learnings from your research will inform upcoming features, build out requirements and acceptance criteria, and help you understand your users. These are all things that move the team forward and provide value.

Reference

Josh Seiden. 2019. Outcomes Over Output: Why Customer Behavior is the Key Metric for Business Success. Sense & Respond Press, United States.



Source link

More To Explore

Rethinking User Personas | UX Booth

User Personas Need to Evolve UX designers are creating elegant user personas that include details irrelevant to the work at hand, reducing their value for

Share on facebook
Share on twitter
Share on linkedin
Share on email