LEARN. PRACTICE. GROW.Concept and mechanism
A need describes a problem or outcome sought by a user. A proposed solution can be a clue, but requires context. Investigate current work, difficulties, alternatives people use, and the consequences of delays. Combine interviews and observation with usage data and support contacts. Include people performing the task, less frequent users, and those supporting operations. Identify a stakeholder opinion as a hypothesis when evidence is missing. Plan research around the decision you need to make, selecting suitable participants and methods. Collecting many responses without knowing how they will be used can consume time without reducing the uncertainty that matters.
Guided application
APS requests a button to resend files because staff spend time checking several tools. First observe how they establish whether a file failed, was received, and can be resent without duplication. The main need may be reliable status information rather than faster resending. Test a prototype with realistic tasks and neutral instructions that do not reveal where to click. Use fictional data when the environment cannot safely support real data. Record behavior and uncertainty, including situations where the proposal does not help. Research here is a complementary discovery practice; schedules and obligations specific to the British Service Manual are not universal Scrum requirements.
Ask: how does the operator determine whether resending is necessary and safe?
Common pitfalls
Interviewing only managers; leading participants; confusing preference with behavior.
Related topics: Goal, value, and accountability · Ordering and explicit trade-offs · Refinement, criteria, and quality
Choose the next experiment by the uncertainty it can resolve.
Reference: Plan user research for your service · Scrum Guide November2020; EBM May2024; primary product practice reviewed 2026-09-30