User or Customer Interviews

A structured conversation with real users or customers to uncover needs, pain points, and expected outcomes that inform epics, user stories, and acceptance criteria. In Scrum, the Product Owner leads or coordinates interviews to validate value, refine the product backlog, and reduce requirement risk.

Key Points

  • Tool and technique used to elicit requirements and validate assumptions directly with users or customers.
  • Usually led by the Product Owner with facilitation support from the Scrum Master and participation from Developers as needed.
  • Applies during visioning, developing epics, creating user stories, backlog refinement, and before or after Sprint Reviews.
  • Uses open-ended and probing questions to focus on problems, outcomes, and context of use.
  • Can be one-on-one or small group; timeboxed and guided by an interview script.
  • Produces insights that translate into prioritized stories, acceptance criteria, and non-functional requirements.
  • Findings feed into personas, story maps, and the overall product roadmap.

Purpose of Analysis

Interview analysis transforms raw quotes and observations into actionable backlog items. It helps validate the product vision and value propositions, discover unmet needs, and expose risks and constraints early.

The goal is to align epics and user stories with real user workflows, measurable outcomes, and clear acceptance criteria that support Definition of Done.

Method Steps

  • Clarify objectives and hypotheses: what you must learn to refine epics or write stories.
  • Select participants: representative users or customers for each persona and workflow.
  • Prepare an interview guide: open-ended questions, tasks, and probes; include consent and privacy notes.
  • Schedule and brief the team: align roles, timebox, and note-taking responsibilities.
  • Conduct interviews: build rapport, observe context, avoid leading questions, and capture verbatim quotes.
  • Synthesize findings: group themes, pain points, jobs-to-be-done, constraints, and success measures.
  • Translate to backlog: draft or refine epics, user stories, acceptance criteria, and non-functional requirements.
  • Review and prioritize: discuss insights in backlog refinement, adjust ordering, and communicate to stakeholders.

Inputs Needed

  • Product vision, business case, and high-level roadmap.
  • Existing epics, user stories, and acceptance criteria drafts.
  • User personas, journey maps, and current workflow diagrams.
  • Hypotheses, MVP scope, and key risks or assumptions.
  • Sample artifacts such as wireframes, prototypes, or mock data.
  • Operational data such as analytics, support tickets, and incident trends.

Outputs Produced

  • Interview notes, recordings, and synthesized insights and themes.
  • Updated personas, story maps, and clarified user workflows.
  • Refined epics and user stories with specific acceptance criteria and examples.
  • Identified non-functional requirements such as performance, security, and accessibility.
  • Backlog changes: new items, re-prioritized items, and items removed or merged.
  • Documented risks, assumptions, and open questions for follow-up.

Interpretation Tips

  • Differentiate frequency from intensity: common pains and critical but rare issues both matter.
  • Separate problem from solution: capture desired outcomes before proposing features.
  • Triangulate: confirm interview insights with analytics, support data, and usability checks.
  • Turn quotes into tests: write acceptance criteria and examples that reflect real scenarios.
  • Note constraints: environment, policies, regulations, and integration points that shape design.
  • Prioritize by value and risk: fast-track items that unlock learning or reduce uncertainty.

Example

A Product Owner explores a reporting epic. They interview eight users from sales, finance, and operations. Users highlight a recurring need to export filtered data to CSV and strict role-based access controls.

The team adds new user stories for export, filtering, and permissions, writes clear acceptance criteria, and raises a non-functional requirement for performance on large datasets. Backlog order is updated to deliver the highest-value workflow first.

Pitfalls

  • Leading questions that suggest an answer and bias results.
  • Talking to convenient stakeholders instead of representative users.
  • Over-generalizing from a single strong opinion or outlier case.
  • Skipping notes or recordings and losing critical context.
  • Jumping to UI solutions without validating the underlying job to be done.
  • Ignoring non-functional needs and constraints discovered in interviews.

PMP/SCRUM Example Question

During backlog refinement, the Product Owner is unsure which acceptance criteria to include for a high-risk user story. What should the Scrum team do next?

  1. Create detailed technical tasks and let Developers decide the criteria during the sprint.
  2. Schedule user or customer interviews to understand real workflows and define acceptance criteria.
  3. Wait until the Sprint Review to gather stakeholder feedback and then add criteria.
  4. Send a mass survey and convert responses directly into acceptance criteria.

Correct Answer: B — Schedule user or customer interviews to understand real workflows and define acceptance criteria.

Explanation: Interviews elicit concrete needs and examples that translate into clear acceptance criteria before the sprint. Waiting or relying on generic surveys is less effective and increases requirement risk.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Eight teaching sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Take Control of Project Performance!

HK School of Management helps you go beyond status reports and gut feelings. In this advanced course, you will learn Earned Value Management (EVM) to measure progress, forecast outcomes, and take corrective action. Learn how WBS quality drives performance, how control accounts work, and how to use EAC, TCPI, and variance analysis. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More