Here’s what to do when user research doesn’t fit in a sprint
I teach teams how to integrate UX practices into Agile ways of working. One question that comes up in every class is this:
“What about work that takes longer than one sprint?
While most software developers find that the nature of writing code lends itself easily to the agile practice of slicing work into small chunks, designers and researchers have a much harder time. One reason for this is that some design work takes a long time. Especially user research.
So what should you do when you’re planning an 8-week research project, but your team is working in 2-week sprints?
The Pressure To Fit It In
Designers and researchers face a lot of pressure to force their work into a sprint framework. I don’t make it easier for them with my insistence that teams work from a single backlog. That means that I want design and research work represented in the backlog. When they do this and put their 8-week research project into the backlog, they end up having to explain at the end of every sprint why their work isn’t “done.” It makes everyone unhappy.
Going Back To Principles
When faced with a conflict like this, it’s helpful to go back to principles. Why is the Scrum framework so insistent on “Done” for example? What else can Scrum offer to help us solve the conflict here? Here are some principles that I use to get out of this mess:
Principle 1: Don’t Do The Same Thing Faster
When teams adopt Agile, the first attempts often involve doing the same things you’ve always done, just faster. This never works out well. You can’t do eight weeks of research in two weeks. Don’t even try. Instead, you need to behave in a new way. You need to re-conceptualize the work. How do you do that? Read on…
Principle 2: Beware of an [X] Phase
Any time you have a research phase, a design phase, a development phase, a testing phase, a (god-forbid) hardening phase, really an anything-phase, it should serve as a warning sign that something’s wrong.
Agile teams should be doing all of these things continuously, in every sprint. You want to be researching continuously. Designing continuously. Building continuously. Testing… you get the point. So instead of running an 8-week research study that you think of as a “phase,” instead, run eight weeks of continuous research. (And then, plan to run eight more. Forever.)
Principle 3: “Done” means “Be transparent & deliver value every sprint.”
Scrum places so much emphasis on work being “done” at the end of every sprint because “done” is a powerful forcing function. It forces everyone to show their work. And it makes the assumption that finished work is valuable. (That’s not always true, but that’s the goal.)
If you want research to be “done” in a traditional sense, you’re thinking about completing the study, synthesizing the research, creating artifacts like personas and journey maps, and so on. But remember, we’re not going to do the same thing faster. We’re going to do something new. So instead of “done”, let’s think about delivering value and being transparent.
If your 8-week research study has to deliver value every two weeks, what would you deliver at sprint demo on Friday? How about an experience report about your first two site visits? How about some early conclusions after completing half of your interviews? How about the new questions that have come up as you’ve started to learn new things? Would those things be valuable? Yes they would. And would that make your work transparent? Yes, it would do that too.
Research is Never Done
A high-functioning agile team should be doing research continuously. That research should inform the decisions the product team is making. (And conversely, the research agenda should sometimes drive development priorities because sometimes you need to make stuff specifically to support the needs of your researchers. It’s a two-way conversation.)
So, stop thinking in terms of research studies and research phases, and instead think of research as a continuous part of your team’s operating rhythm. Share your work. Deliver value each week. Be honest about what you do and don’t know. Help your team learn.
If you liked this article, check out my new book, Outcomes Over Outputs.
