Conducting User Research with a Team Working in 2-Week Sprints When Recruiting Takes 2 Weeks

Are you an in-house user researcher who is trying to make user research work in an agile environment? And, does it take more than one to five days to recruit your participants?

If you answered yes to both of these questions, oof. I feel your pain. At FactSet, I joined a team working within a two-week agile sprint environment. This agile team wanted one dedicated user researcher to conduct an entire user research project almost every two weeks over five months, so not counting a couple of weeks off due to holidays and time off, I conducted eight rounds of user research over this span. In this article, I’ll tell you how I did it. Hopefully, it helps you!

Planning

When I joined the agile team, I explained that the user research process would not follow the exact agile process that we as a team were going to use because recruiting could take upwards of two weeks or even longer for our user research projects. Well, that would be the whole sprint if I didn’t plan far in advance!

Each round of user research took five weeks to complete, so by week three, I began working on the second round of research. By the fifth week of being part of the agile team, I was working on three rounds of research at a time. With proper planning, conducting user research within an agile environment becomes more manageable than it sounds.

Steps

I conduct user research in ten steps:

Over the course of five weeks, these ten steps break out like this across three rounds:

To avoid confusion amongst the team, the team meetings were structured in the calendar so that the team did not meet about different Research Rounds on the same day. (There was one day where the team met to review stimuli for one round and attended live interviews for a different round.)

Caveats because of course there are caveats:

• The methodology for every Research Round except for one round was 60-minute, one-on-one, remote interviews with five to eight participants.
• Each subsequent Research Round did not immediately build upon the findings, insights, and recommendations from the previous round. We were able to work this way because our team was building a product for two entirely different user groups, and each Research Round was dedicated to different areas of the product.
• Our engineering team had their own desktop research to conduct during the first few weeks of being part of the team, so waiting on user research findings from Research Round 1 did not negatively impact the team.

Interviews

I know what you’re thinking. If I’m trying to conduct user research as fast as possible, why did I conduct interviews across three days instead of on one day? Here are a few reasons:

• I’m one user researcher, so I prefer not to moderate more than four hours of interviews in one day. It’s exhausting.
• Having more than one day available for interviews means that recruiting is easier since more days are available for participants to be scheduled.
• Typically, most, if not all, of my team members were able to observe a live interview as long as the interviews were spread out over multiple days.
• If participants needed to move their interviews around to better fit their schedule last minute, I had time to accommodate their needs.

Teamwork

Making it as easy as possible for your team to help you with user research is key.

Therefore, I created a notetaking template in Excel for my team to utilize so that the format of everyone’s notes matched and made it easier for me to combine all of the notes into one Excel spreadsheet. I provided notetaking instructions — the best notes are verbatim notes, but there’s no need to transcribe everything a participant says. With verbatim notes in one Excel spreadsheet, searching and finding quotes for the report was much easier than returning to interview recordings.

Additionally, I used a Teams channel for my team to send questions and comments during the interviews as well as in between interviews so that everyone was kept in the loop even without attending every live interview. Moderating a remote interview on a laptop and monitoring questions coming from your team via the Teams app on your phone can be tricky, so make sure you:

• leave enough time at the end of each interview (~five minutes) for questions from observers.
• convey to your team that you may not get to all of their questions but will incorporate them iteratively into your guide.

Conducting user research rounds this quickly and by one user researcher cannot be accomplished without the help of the whole agile team. Luckily, my team agreed to:

• stick to the Sprint Schedule I had shared with the team (within one to two days), meaning the stimuli were delivered on time, they actively participated in the debriefs, etc.
• ensure that at least one team member was able to attend each live interview and take notes so that I did not have to review recordings in depth.
• watch at least two interviews (live or recorded) each prior to the debrief so that they could actively participate in the debrief.

Reporting

I don’t create user research reports in a silo. Instead, I work off of the notes my team took during the interviews and the outcomes of the debrief meeting, which usually involved an affinity mapping activity on Mural (a digital collaborative tool, kind of like a whiteboard with sticky notes).

I wrote Word Doc reports instead of PowerPoint reports to speed up the process. Once I finished my report, I met with the team to walk through each recommendation to annotate whether or not each recommendation would be included in the MVP (Minimum Viable Product) or post-MVP. Once the MVP was completed, I returned to the reports to find all of the recommendations that we had not implemented to revisit their importance moving forward.

There is no one-size-fits-all approach to conducting user research, but I hope my outline provides you with ideas for integrating your user research process into a team that wants to work in quick sprints. Good luck, and let me know how it goes!

Acknowledgments

Special thanks to all who contributed to this blog post:

Author: David Engel
Managing Editor: Ralph Kootker
Reviewers: Elizabeth Edwards, Rikki Pennisi, Marlene Mrakovcic, Naresh Tammineni, Nupur Jain, Phani Adusumilli, and Charles Papagiannopoulos