When is the best time within a sprint cycle to integrate guerrilla user research?

Question

Currently, our development follows three-week agile sprints, while our user research and design are still fairly waterfall. I’m hoping to incorporate some guerrilla user research directly into each sprint. One day each sprint, a cross functional group of 4-6 people directly impacted by a feature could spend the morning doing some user interviews or usability studies; in the afternoon, that group could come together to collaboratively design a solution (or tweak a proposed solution) based on what they found.

(I’m assuming that a week before the guerrilla research, we would hold a meeting to brainstorm a list of key unknowns/risks. During that week, I could prepare materials for the research.)

My question is when within each sprint to include this guerrilla research.

A couple of options might be:

1. This research and the connected design studio would take place on the first day of a sprint. (Designs from usability studies would be tweaked and be acted upon immediately. Formative research would feed into designs for future sprints.)
   Pros: People would be able to act upon their new knowledge immediately.
   Cons: People might not have time to adjust the scope of the sprint based on what we found in the design studio.

2. The research could be scheduled toward the middle of each sprint, but wouldn’t be acted upon until 2-3 sprints later, as soon as the relevant feature is scoped in.
   Pros: Research would be completed early enough not to create a time crunch.
   Cons: We might end up researching things in the product backlog that would would end up being removed due to other factors before the sprint began. Also, more documentation would be necessary because people would forget the results of the research and design studio in the weeks between doing the research and implementing the results.

3. The guerrilla user research and design studio could be scheduled on the second-to-last day of the sprint. Design and product would have the following day to tweak stories and designs to prepare for the next sprint.
   Pros/Cons: As an intermediary state between the other two options, this option has a mix of the pros and cons of each.

4. Other options?

When is the best time within a sprint cycle to integrate guerrilla user research?

Answer 1

Option 2 works best for me in this sort of w/agile environment.

Couple of things to consider:

The Dev team are working agile. This means they have a backlog that is constantly being reprioritised, so in the unlikely event any drop-dead high priority issues come up they can be dealt with immediately.

You're doing the right thing involving the team regularly, in hypothesising issues to be tested, observing it, and acting on the testing. They can use what they learn to make better decisions in their own areas, and have buy-in to yours... But you do own user testing so you could test more often if you like. Weekly is better. Or two-weekly.

Your example doesn't put in time for analysis. You DO need to record your sessions (I use snag-it) and analyse them. If you don't analyse, you risk seeing what you want to see and not what's really there. I didn't believe this could happen either... but I've been convincingly proved wrong.

Answer 2

In my experience, guerilla research is generally ad hoc and largely improvised - hence the name.

However, if you are planning to include a scheduled block of research in your sprint I would suggest placing it near the end where you can use it to evaluate the work completed in the sprint and test any secondary ideas, theories, or questions that may have been surfaced by the work in the sprint.

This means that your test results can be presented along with the completed work to inform the content of the backlog and, therefor, what goes into subsequent sprints.

You will also need to remember that it takes time to prepare tests and surveys as well as to collate and analyse the results - In my experience a single quantitative question with a moderate response (about 75-100 respondents) takes about a day to design, run, and analyse. This will need to be factored in when you are scheduling your sprint or deciding what to test.