Agile research keeps a product team in contact with users while the product is changing. It makes research part of planning, design, and delivery, so the next decision can draw on evidence collected for that decision rather than on an old report with a vaguely similar topic.
The word “agile” describes how the work is organised. It does not prescribe one research method, a universal sample size, or a rule that every study must fit inside a sprint.
Work from the decisions approaching
A useful research plan distinguishes questions about the current experience from uncertainties further ahead. The team may need to test revised account permissions this week while investigating how larger organisations approve new software over the coming month. Both activities support delivery, although they run on different timescales.
The Government Digital Service’s account of research in agile teams emphasises regular research alongside attention to immediate and strategic questions. This helps avoid a narrow cycle in which every study evaluates the next screen and nobody examines the assumptions behind the wider service.
Attach each study to a decision and identify who needs the findings. A short usability test may answer a focused interaction question. Understanding a lengthy procurement process could require interviews with several roles, access to documents, and more time. Breaking that investigation into manageable activities is sensible; pretending the question has become smaller is not.
Build the arrangements that make research repeatable
Frequent studies become easier when recruitment, consent, scheduling, and analysis have dependable owners. Reusing an interview guide structure or a tested invitation saves preparation without dictating what every study must ask.
Choose moderated or unmoderated work according to the uncertainty. Recorded tasks can suit independent interaction testing, while unfamiliar or sensitive experiences may require a researcher who can listen and follow up. Ballpark’s recruitment tools can help with participant sourcing, but eligibility and coverage still need to be defined for the study.
Leave room between a finding and the decision it should influence. A session completed on time has little practical value if analysis arrives after the implementation has become difficult to change.
Make uncertainty visible as work moves forward
Share enough evidence for colleagues to understand the finding, including who encountered the problem and under what conditions. A short recording can communicate a specific difficulty, but it should not become the entire argument for a broad conclusion.
Keep unresolved questions visible alongside delivery work. Some will justify another small round of iterative research; others need a larger investigation. Agile research succeeds when the team can adapt its plans to that distinction, instead of allowing the sprint calendar to determine what it is willing to learn.