Scrum Master Interview Questions

Aspect	Scrum	Kanban
Cadence	Fixed sprints (1-4 weeks)	Continuous flow
Roles	Scrum Master, Product Owner, Developers	No prescribed roles
Work limits	Sprint backlog (committed per sprint)	WIP limits per column
Changes	Discouraged during sprint	Allowed anytime
Ceremonies	Sprint Planning, Daily Scrum, Review, Retro	No required ceremonies
Board	Reset each sprint	Persistent, continuous
Metrics	Velocity, sprint burndown	Lead time, cycle time, throughput
Planning	Sprint-based estimation	Just-in-time, pull-based

When to use Scrum: Teams that benefit from structure, predictable delivery cadence, and regular planning cycles.

When to use Kanban: Support/ops teams, teams with unpredictable work, or when continuous delivery is more important than sprint commitments.

Scrumban combines both: sprint cadence with WIP limits, or Kanban flow with regular retrospectives. Works well for teams transitioning between methodologies.

Key things to listen for:

• Team ownership — the team creates and maintains the DoD, not just the SM
• Living document — DoD evolves as the team matures
• Consistent enforcement — DoD is applied to every story, not selectively

What a good DoD includes:

• Code written and peer-reviewed
• Unit tests written and passing
• Integration tests passing
• No known critical bugs
• Documentation updated (if applicable)
• Deployed to staging environment
• Acceptance criteria met and verified
• Product Owner has reviewed and accepted

Creating the DoD:

1. Discuss as a team what "done" means for your context
2. Start with a minimal DoD and expand as the team matures
3. Write it down and make it visible (posted on the board or wiki)
4. Review and update it during retrospectives

Maintaining it:

• Reference the DoD during sprint planning ("Can we realistically meet DoD for all these items?")
• Use it during sprint review as the acceptance checklist
• If items frequently don't meet DoD, discuss why in retro
• Never compromise DoD under pressure — incomplete work creates hidden debt

Handling disagreements: Refer back to the written DoD. If the DoD is unclear, improve the wording in the next retro. The PO has final say on acceptance criteria; the team has final say on technical quality standards.

Key things to listen for:

• Practical experience — has dealt with real scaling challenges, not just theoretical knowledge
• Communication focus — understands that scaling is primarily a coordination problem
• Framework awareness — knows frameworks exist but doesn't blindly follow them

Common challenges:

1. Cross-team dependencies — teams waiting on each other, integration conflicts
2. Consistent practices — different teams using different standards or definitions of done
3. Shared codebase — merge conflicts, architectural decisions affecting multiple teams
4. Communication overhead — more teams = exponentially more communication channels
5. Prioritization — competing backlogs and conflicting priorities
6. Alignment — keeping all teams moving toward the same product vision

Scaling frameworks:

• SAFe — most structured, heavy process, works for large enterprises
• LeSS — minimal framework, extends Scrum to multiple teams
• Nexus — Scrum.org's scaling framework, focuses on integration
• Spotify Model — squads, tribes, chapters, guilds (not a framework, an organizational model)

Practical solutions:

• Scrum of Scrums — representatives from each team sync regularly
• Shared backlog refinement for cross-team items
• Common Definition of Done across teams
• Architectural guilds for cross-cutting technical decisions
• Joint sprint reviews to see the whole product increment

Key things to listen for:

• Preparation — works with PO before planning to ensure backlog is refined
• Team involvement — the team decides what they can commit to, not the SM or PO
• Clear sprint goal — focuses on outcomes, not just a list of stories

Good approach:

1. Before planning:

   • Ensure backlog items are refined (clear acceptance criteria, estimated)
   • PO prioritizes the backlog based on business value
   • Review team capacity (vacations, meetings, on-call)

2. During planning:

   • PO presents the sprint goal and top priority items
   • Team discusses each item, asks questions, clarifies scope
   • Team selects items they can commit to based on capacity and velocity
   • Break items into tasks if needed
   • Agree on a clear sprint goal

3. Time-box: 2 hours per sprint week (e.g., 4 hours for a 2-week sprint)

Over-committing: Review historical velocity, encourage the team to leave buffer, discuss why it keeps happening (optimism bias, unclear stories, unplanned work).

Under-committing: Stretch goals, review if stories are too large, check if the team is sandbagging or if there are hidden impediments.

Key things to listen for:

• Proactive detection — doesn't wait for problems to be reported
• Servant leadership — removes blockers so the team can focus on work
• Escalation awareness — knows when to escalate vs. resolve directly
• Systemic thinking — addresses root causes, not just symptoms

Detection methods:

• Daily standup ("What's blocking you?")
• One-on-ones with team members
• Observing team dynamics and energy levels
• Monitoring board for stuck items (long cycle time)
• Retrospective feedback

Resolution approach:

1. Log the impediment — make it visible (impediment board or backlog)
2. Assess impact — how many people are affected? Is it blocking the sprint goal?
3. Classify — can the team resolve it, or does it need external help?
4. Act immediately — for high-impact blockers, drop other work
5. Escalate when needed — involve management for organizational impediments
6. Follow up — verify the impediment is truly resolved

Common impediment types:

• External dependencies (waiting on another team)
• Unclear requirements (needs PO clarification)
• Technical blockers (environment issues, access permissions)
• Organizational (slow approval processes, meeting overload)
• Team dynamics (conflicts, communication breakdowns)

Key things to listen for:

• Empathy — understands why the PO changes priorities (market pressure, stakeholder demands)
• Structured pushback — doesn't just say yes or no, but facilitates a conversation
• Process as a shield — uses Scrum framework to protect the team while staying flexible
• Data-driven — shows the impact of frequent changes with metrics

Good approach:

1. Understand the root cause — why are priorities changing? Is the market volatile, or is there a planning problem?
2. Make the cost visible — "Changing this mid-sprint means X won't get done. Is that acceptable?"
3. Shorter sprints — if change is constant, reduce sprint length to 1 week for faster feedback
4. Buffer capacity — reserve 10-20% of sprint capacity for unplanned work
5. Backlog refinement — better refinement reduces surprises
6. Sprint goal focus — "Does this change align with our sprint goal? If not, it waits."

Mid-sprint scope change:

• Scrum Guide says sprint scope should not change during a sprint
• Facilitate a conversation: "We can add this, but what do we remove?"
• If the change invalidates the sprint goal, consider canceling the sprint (rare but valid)
• Track scope changes to show the pattern in retrospectives
• Work with the PO to improve upstream planning

Key things to listen for:

• Empathy first — understands and validates the resistance before trying to change it
• Lead by example — shows value through results, not by forcing compliance
• Patience — recognizes that change takes time
• Adaptability — willing to adjust the approach, not dogmatic about specific practices

Understanding resistance sources:

• Bad past experience with agile ("We tried it, it didn't work")
• Fear of losing autonomy or control
• Doesn't see the value ("This is just more meetings")
• Comfort with current way of working
• Imposed without team input ("Management decided we're doing Scrum")

Good approach:

1. Listen first — understand why they're resistant (1-on-1 conversations)
2. Start small — introduce one practice at a time, not everything at once
3. Show value quickly — pick a practice with immediate visible benefit (e.g., daily standup to improve communication)
4. Involve the team — let them shape how practices are implemented
5. Focus on problems, not practices — "We have a communication gap" not "We need daily standups"
6. Celebrate wins — highlight when agile practices produce positive results
7. Be flexible — adapt ceremonies to fit the team's culture (e.g., async standups for distributed teams)

Handling open hostility:

• Private conversation — understand their specific concerns
• Acknowledge valid points — maybe some ceremonies do need adjustment
• Agree on a trial period — "Let's try it for 2 sprints and evaluate"
• If behavior is disruptive, address it as a team dynamic issue, not an agile issue

Key things to listen for:

• Realism — acknowledges the onboarding tax and plans for it honestly
• Team involvement — uses onboarding as a team activity, not just an SM task
• Stakeholder transparency — communicates impact proactively

Onboarding approach:

1. Before they join:

   • Prepare a "day one" guide (repo access, dev environment setup, key contacts, team norms)
   • Assign an onboarding buddy from the team
   • Reserve capacity in the sprint plan — don't plan at full velocity

2. First sprint:

   • Start with a well-understood, scoped story (low risk, good for learning the codebase)
   • Pair programming with an experienced team member
   • Walk through the full workflow: picking up a story, branching, PR process, DoD
   • Include them in all ceremonies immediately — observation before participation is okay

3. Team ceremonies:

   • Facilitate introductions in the team retrospective — let the new person share first impressions
   • Include onboarding experience in retrospective: "What would have helped you get started faster?"

Handling reduced velocity:

• Adjust capacity in sprint planning: "We have a new team member starting, so we're planning at 80% capacity"
• Communicate proactively to stakeholders before the sprint: "Expect lower output while we onboard"
• Reframe: "We're investing in capacity — velocity will recover and grow"
• Avoid hiding it — a sudden velocity dip mid-sprint is more alarming than a communicated one

Key things to listen for:

• Variety — uses different formats to keep retros fresh
• Psychological safety — creates an environment where honest feedback is safe
• Actionable outcomes — retros produce concrete improvements, not just complaints
• Follow-through — tracks action items and reviews progress

Popular formats:

• Start/Stop/Continue — simple and effective for any team
• Mad/Sad/Glad — emotion-based, good for surfacing team morale
• Sailboat — wind (what helps), anchors (what holds back), rocks (risks), island (goal)
• 4Ls — Liked, Learned, Lacked, Longed for
• Timeline — plot events on a timeline and discuss highs/lows
• Dot voting — identify top issues democratically

Keeping retros engaging:

• Rotate formats every 2-3 sprints
• Use online tools (Miro, FunRetro) for remote teams
• Start with an icebreaker or energizer
• Timebox discussions to keep energy up
• Celebrate wins, not just problems
• Occasionally let a team member facilitate

Ensuring follow-through:

• Limit action items to 2-3 per retro (focus over quantity)
• Assign an owner and deadline to each action item
• Review previous action items at the start of each retro
• Add action items to the sprint backlog so they get tracked

Key things to listen for:

• Metrics as tools, not targets — uses metrics for insight, not performance evaluation
• Team-level metrics — never measures individual developer velocity
• Trend over absolute — focuses on trends over time, not sprint-to-sprint numbers
• Transparency — shares metrics openly and explains their purpose

Good approach:

1. Educate stakeholders — velocity is a planning tool, not a productivity measure
2. Use ranges — "Our velocity is typically 30-40 points" rather than "We do 35 points"
3. Focus on flow metrics:
   • Cycle time (how long items take from start to done)
   • Throughput (items completed per sprint)
   • WIP (work in progress at any time)
4. Never compare teams — different teams estimate differently
5. Celebrate improvement — highlight reduced cycle time or fewer bugs, not higher velocity

When management asks to increase velocity:

• Explain that velocity measures estimation accuracy, not productivity
• Inflating points doesn't deliver more value
• Focus conversation on: What outcomes do you want? More features? Faster delivery? Better quality?
• Suggest: "Instead of increasing velocity, let's reduce cycle time and remove impediments"

Warning signs of metric abuse: Teams inflating story points, avoiding complex work, rushing quality, or feeling anxious about sprint commitments.

Key things to listen for:

• Pattern recognition — can identify common dysfunctions
• Root cause thinking — looks beyond symptoms to underlying issues
• Constructive approach — addresses problems without blame

Common anti-patterns:

Ceremony anti-patterns:

• Daily standup becomes a status report to the manager
• Retros produce no action items or same issues repeat
• Sprint review is a demo, not a feedback session
• Planning is dictated by PO/manager, not collaborative

Team anti-patterns:

• "Mini-waterfalls" within sprints (all dev, then all testing)
• Hero culture (one person does all the hard work)
• No real collaboration (everyone works in silos)
• Fear of raising issues or disagreeing

Process anti-patterns:

• Velocity used as a performance metric
• Stories carry over every sprint
• No working software at end of sprint
• Scrum Master assigns tasks (should be self-organizing)
• "Agile in name only" — same waterfall process with new terminology

Addressing anti-patterns:

1. Observe and gather data (don't act on assumptions)
2. Raise it in a retrospective as a discussion topic, not an accusation
3. Use questions: "I've noticed X happening — what do you think is causing it?"
4. Let the team own the solution
5. Experiment and iterate — try a change for one sprint and evaluate

Key things to listen for:

• Framework trade-offs — understands that more structure comes with more overhead
• Context-driven selection — matches the framework to the organization, not the other way around
• Experience — ideally has used at least one in practice

SAFe (Scaled Agile Framework):

• Most prescriptive and comprehensive
• Introduces Agile Release Trains (ARTs), Program Increments (PIs), and multiple roles (RTE, Product Manager)
• Strong portfolio-level governance, budgeting, and roadmaps
• Best for: Large enterprises with compliance needs, waterfall roots, or many inter-dependent teams (50+ people)
• Drawback: Heavy ceremony load, can feel bureaucratic, risk of becoming "SAFe washing"

LeSS (Large-Scale Scrum):

• Minimalist — extends standard Scrum with as little additional process as possible
• One Product Owner, one Product Backlog, multiple teams sharing the same sprint cadence
• Strong on organizational design; encourages removing specialist silos
• Best for: Organizations willing to restructure around feature teams (5-8 teams)
• Drawback: Requires significant organizational change and trust to work

Nexus:

• Scrum.org's scaling guide, sits between LeSS and SAFe in complexity
• Adds a Nexus Integration Team responsible for cross-team coordination and integration
• Keeps most of standard Scrum intact
• Best for: 3-9 teams working on a single product; pragmatic extension of Scrum
• Drawback: Less guidance at portfolio level compared to SAFe

Selection criteria:

• Organization size and number of teams
• Willingness to restructure (LeSS requires it, SAFe doesn't)
• Regulatory/compliance needs (SAFe has HIPAA, CMMI alignment)
• Existing Scrum maturity
• Management appetite for change

Key things to listen for:

• Proactive visibility — makes dependencies visible before they become blockers
• Cross-team relationships — builds trust between teams, not just process
• Escalation path — knows when to involve leadership or a Release Train Engineer

Dependency management approaches:

1. Make dependencies visible early:

   • Use a dependency board or risk board visible to all teams
   • Identify dependencies during backlog refinement and sprint planning
   • Mark dependent stories with explicit links and expected delivery dates

2. Cross-team ceremonies:

   • Scrum of Scrums — representative from each team meets 2-3x per week
   • PO Sync — Product Owners align on shared priorities and trade-offs
   • Joint sprint planning — teams planning together when major cross-team work is involved
   • System demo — integrated demo at the end of each PI (in SAFe context)

3. API-first and interface contracts — agree on interfaces early so teams can work in parallel

4. "Team API" concept — each team publishes what they can deliver and when, others plan around it

When a dependency blocks a sprint goal:

• Raise it immediately in Scrum of Scrums
• Negotiate urgency with the providing team's SM and PO
• Escalate to leadership if it's a business priority conflict
• Adjust the sprint goal rather than silently miss it
• Retrospect on why the dependency wasn't caught earlier

Key things to listen for:

• PI Planning understanding — knows it's a big-room planning event, not just a longer sprint planning
• Preparation discipline — success at PI Planning starts weeks before the event
• Team-level vs. train-level thinking — the team must think beyond its own sprint into cross-team commitments

What a Program Increment (PI) is:

• A fixed timebox of 8-12 weeks consisting of 4-5 development sprints + 1 Innovation & Planning (IP) sprint
• The entire Agile Release Train (ART) aligns on the same PI objectives
• At the end of each PI, the ART delivers a working, tested system increment

PI Planning (the event):

• 2-day event (can be remote or in-person) where all ART teams plan the upcoming PI together
• Output: team PI objectives, program board with dependencies and risks, draft sprint plans for all iterations

Preparing the team:

1. Feature readiness — ensure Business Owners and Product Management have prioritized features 2 weeks before
2. Capacity planning — identify team availability (vacations, hiring plans) for the full PI
3. Architecture briefing — system architect presents enablers and architectural runway
4. Team backlog — PO refines stories for at least Sprint 1-2 before the event
5. Train the team — if it's the first PI, run a workshop explaining the format, outputs expected, and how dependencies are tracked

Common first-time pitfalls:

• Over-committing in the excitement of big-room energy
• Not identifying cross-team dependencies until mid-PI
• Treating PI objectives as a waterfall contract rather than a commitment with uncertainty
• Teams not coordinating with the System Team (CI/CD pipeline, environments)
• Ignoring the IP sprint (treating it as extra development time)

Key things to listen for:

• Precise definitions — doesn't conflate the two
• Practical application — uses them to diagnose bottlenecks, not just report numbers
• Stakeholder communication — can translate flow metrics into business language

Definitions:

• Lead time — total time from when a request is created (added to the backlog) to when it is delivered. Includes wait time in the backlog.
• Cycle time — time from when work actively starts (moved to In Progress) to when it is done. Excludes queue time.

Example:

• A feature is added to the backlog on Monday
• Development starts the following Monday (7 days of waiting)
• Development and review take 3 days
• Lead time = 10 days, Cycle time = 3 days

How to use them:

Metric	What it reveals	What to do
Long lead time	Backlog is too large, prioritization issues	Backlog grooming, WIP limits
Long cycle time	Stories are too large, blockers, lack of focus	Split stories, remove impediments
Lead > Cycle (large gap)	Work sits in queue too long	Reduce batch size, pull sooner

For stakeholders: "Lead time tells us how long customers wait for something they've asked for. Cycle time tells us how efficiently the team works once they pick something up. We want both to shrink — but for different reasons."

Practical tools: Jira's Control Chart and Cumulative Flow Diagram (CFD) visualize both metrics over time.

Key things to listen for:

• Metrics skepticism — understands that charts can be gamed or misleading
• Qualitative + quantitative — combines data with team observations
• Early warning instinct — proactively checks in rather than waiting for the chart to show problems

Why a burndown can look good but mask problems:

1. Story point inflation — team estimates higher to make the chart look comfortable
2. Closing stories prematurely — marking items done before they meet DoD
3. Hidden technical debt — features ship but are fragile, slow, or hard to maintain
4. Unplanned work absorbed quietly — team works weekends to compensate, burndown looks smooth
5. Single contributor — one person carries the sprint, others are blocked but stories still close
6. Late-breaking scope creep — PO quietly adds small items that inflate the total and don't show in burndown

Signs to look for beyond the chart:

• Daily standup energy and body language
• Number of items in "In Progress" simultaneously (high WIP)
• Bug rate during the sprint
• Team members skipping retro action items
• Team saying "we'll clean it up next sprint" frequently

Combining data sources:

• Burndown + cycle time per story (are stories cycling fast or sitting?)
• Burndown + daily standup notes (qualitative mood tracker)
• Burndown + DoD compliance rate
• Burndown + team satisfaction pulse survey (e.g., NPS or weekly 1-5 rating)

Key things to listen for:

• Holistic view — understands that a high-velocity team can still be burned out or unhappy
• Qualitative + quantitative — combines hard metrics with soft signals
• Trust preservation — measures without creating a surveillance culture

Team health indicators beyond velocity:

Flow metrics:

• Cycle time stability (consistent is healthy; wild variance = chaos)
• WIP level (high WIP = overloaded team)
• Escaped defects (bugs found by users, not the team)
• Technical debt ratio (story points for new features vs. debt repayment)

Team dynamics indicators:

• Retrospective participation rate and quality of conversation
• Daily standup energy (are people present and engaged, or going through the motions?)
• Sick day frequency (burnout signal)
• Turnover and tenure (high turnover = team instability)
• Pair programming or collaboration frequency

Formal tools:

• Team Health Checks (Spotify model) — quick visual vote on dimensions like "Pawns or Players", "Speed", "Fun"
• Weekly mood survey — anonymous 1-5 rating on: clarity, collaboration, confidence, energy
• NPS-style team survey — "Would you recommend this team to a colleague?"

Acting without surveillance:

• Share aggregate results with the full team, not management
• Use results to start conversations, not make decisions
• Let the team decide what to do with the data
• Never tie health data to individual performance reviews

Key things to listen for:

• Visual fluency — can read and explain a CFD without notes
• Actionable interpretation — connects what they see to concrete process changes
• Leading indicator mindset — uses CFD proactively, not just post-mortem

What a Cumulative Flow Diagram (CFD) shows:

• A stacked area chart where each band represents a workflow stage (Backlog, In Progress, Review, Done)
• The vertical distance between bands at any point in time shows the amount of work in that stage
• The horizontal distance shows the approximate cycle time for items

Healthy CFD:

• Bands are roughly parallel and grow smoothly upward
• The "Done" band rises steadily — work is completing consistently
• Bands are thin relative to total flow — no stage accumulates work

Bottleneck signals:

• Widening band — a stage is accumulating more work than it's releasing (e.g., "In Review" grows wide)
• Flat "Done" band — work is not completing; the team may be working but not finishing
• Steep step-changes — batch processing rather than continuous flow
• Narrowing upstream bands — downstream bottleneck is starving upstream stages of pull

High WIP on the CFD:

• The "In Progress" band balloons vertically
• Items take longer to complete (horizontal distance increases)
• Team members are context-switching between too many parallel tasks

Response actions:

• Introduce or tighten WIP limits for the bottlenecked stage
• Swarm on blocked items — pull team members from upstream stages to clear the bottleneck
• Look for root cause: unclear acceptance criteria, missing skills, external dependencies

Key things to listen for:

• Neutrality — doesn't take sides; acts as a facilitator, not a judge
• Safety preservation — keeps the environment psychologically safe for both parties
• Resolution focus — moves toward a decision without suppressing valid debate

In the moment:

1. Acknowledge both perspectives — "I hear two valid points of view here. Let's make sure both are understood."
2. Timebox the debate — "We have 5 minutes to explore this before we need to move on."
3. Separate the people from the problem — redirect from "I think you're wrong" to "What outcome are we trying to achieve?"
4. Ask clarifying questions — help both sides articulate their concerns precisely
5. Look for common ground — often disagreements share the same goal but different risk tolerances

When you're not technical enough to judge:

• Don't fake expertise or pick a side
• "I'm not the right person to evaluate the technical trade-offs here — you two are. What process can we use to decide?"
• Suggest a spike (time-boxed investigation) to gather evidence before committing
• Propose majority vote or coin flip if both options are viable and the cost of delay exceeds the cost of the wrong choice
• Timebox the decision: "Let's decide in 10 minutes — what information do we need?"

After the meeting:

• Check in privately with both individuals
• Discuss at the next retro if it's a recurring pattern
• Build a team agreement on how technical decisions are made

Key things to listen for:

• Boundary clarity — knows the SM role does not include HR or formal performance management
• Coaching first — tries to understand and support before escalating
• Team protection — balances empathy for the individual with responsibility to the team

Initial approach (SM's domain):

1. Private conversation first — "I've noticed you seem less engaged lately. Is everything okay?"
2. Assume positive intent — there may be personal issues, unclear expectations, or skill gaps
3. Listen actively — is the underperformance due to confusion, burnout, disengagement, or external factors?
4. Clarify expectations — ensure the person knows what "good" looks like
5. Offer support — pairing, training, reduced load temporarily, mentoring
6. Set a check-in cadence — follow up weekly to see if things improve

When it becomes a management issue:

• Behavior persists after coaching conversations
• There are formal deliverable failures (repeated missed DoD, sprint commitments)
• The team formally raises it as a blocker
• The issue involves conduct, not just performance
• Legal, HR, or contractual elements appear

Transition to management:

• Loop in the line manager with context and data: "I've had three coaching conversations with X over 6 weeks. Here's what we tried and what hasn't changed."
• Do not handle it unilaterally or gossip to other team members
• Protect the team by ensuring the situation is being addressed, even if you step back

In retrospectives: Facilitate team norms conversations so expectations are co-created, reducing future conflicts.

Key things to listen for:

• Role clarity — can articulate where SM authority ends and PO authority begins
• Systemic approach — addresses the relationship, not just the incident
• Team protection — prioritizes the team's self-organization above the ego conflict

Authority split in Scrum:

• Product Owner: what gets built (backlog priority, product vision, acceptance criteria)
• Scrum Master: how the team works (process, ceremonies, impediment removal, coaching)
• Developers: how to build it (technical decisions, task breakdown, daily work organization)

When conflict emerges:

1. Private conversation — discuss the tension one-on-one with the PO before it becomes public
2. Return to first principles — open the Scrum Guide together; roles are not negotiable
3. Separate the problem — "The goal we both share is successful delivery. Let's figure out where the confusion is coming from."
4. Involve a coach or management — if the relationship is broken, a neutral party is needed

When the PO assigns tasks directly to developers:

• Address it immediately and privately: "When you assign tasks directly, it undermines the team's ability to self-organize. The team needs to pull work based on the sprint goal."
• In the next retrospective, facilitate a discussion about team working agreements
• Create a written team agreement: "All work enters the board through the backlog. The PO adds and prioritizes; the team pulls."
• If it continues, escalate to a shared manager — this is a governance issue, not just a process issue

Key things to listen for:

• Purpose clarity — refinement is about readiness, not just estimation
• Shared understanding — the goal is that all team members understand what needs to be built
• Right size and cadence — refinement is continuous, not a single big meeting

What makes refinement effective:

1. Regular cadence — typically mid-sprint, so there's always a ready backlog for the next sprint
2. Right attendees — PO, developers, SM; invite subject matter experts only when needed
3. Definition of ready — each item should have: a clear user story, acceptance criteria, no open external dependencies, and a rough size estimate
4. Timeboxed — aim for 10% of sprint capacity (e.g., 4 hours in a 2-week sprint)
5. Three horizons — refine items for next sprint in detail, look 1-2 sprints ahead at medium level, and flag anything further out

Techniques used during refinement:

• Story splitting (INVEST criteria)
• Three Amigos (developer, tester, PO discuss each story)
• Acceptance criteria workshops
• Planning poker or T-shirt sizing for estimates

When a story is too vague to estimate:

• Don't force an estimate — inflated estimates are worse than no estimate
• Create a spike: "Let's spend 2 hours researching this and come back with a better understanding"
• Ask the PO for more context or to involve the requester
• Return the story to the backlog with a "needs clarification" flag
• This is a healthy gate — teams that estimate vague stories ship vague features

Key things to listen for:

• Feedback loop focus — understands the review is an inspection-adaptation event, not a sign-off meeting
• Stakeholder engagement skills — actively works to bring the right people and draw out useful input
• Outcome orientation — drives toward actionable feedback, not applause

Structuring an effective sprint review:

1. Set the context — briefly recap the sprint goal and what was attempted vs. completed
2. Demo working software — show real functionality in a real (staging) environment, not slides
3. Focus on outcomes, not output — "This feature reduces checkout abandonment" not just "we built a new button"
4. Invite interaction — let stakeholders try the software themselves when possible
5. Ask targeted questions — "Does this solve the problem you described last month?" "What would make this more useful?"
6. Capture feedback live — write feedback on a shared board, triage with PO after the meeting
7. Close with what's next — brief preview of what's planned for next sprint to maintain engagement

When stakeholders don't show up:

• Investigate why — too long, too frequent, not relevant to them, no agenda?
• Shorten the format or make it async (recorded demo with async feedback form)
• Ensure the right stakeholders are invited, not just management
• Work with PO to demonstrate business value more explicitly
• Consider inviting end users rather than internal stakeholders

Key things to listen for:

• Root cause focus — goes deeper than surface-level complaints
• Psychological safety — recurring complaints often mean the team doesn't feel heard
• Facilitation creativity — changes the format to break the cycle

Why the cycle happens:

• Action items from previous retros were never implemented
• The underlying problem is organizational (outside the team's control)
• The team doesn't believe change is possible
• The same vocal people dominate and others disengage

Techniques to break the cycle:

1. Five Whys — take one chronic complaint and dig into the root cause together
2. Fishbone diagram — map causes and effects visually for a recurring issue
3. Control vs. Influence vs. Accept — sort complaints into what the team can control, influence, or must accept
4. Retrospective on the retrospective — explicitly discuss: "Why do we keep having this conversation?"
5. Focus on one thing — ban the "top 10 problems" list; commit to one meaningful change
6. Outcome-first framing — "What does success look like in 4 weeks?" then work backward

Balancing feelings and solutions:

• Start by fully acknowledging the frustration: "This has been a problem for 4 sprints. That's genuinely frustrating."
• Validate before problem-solving: "Before we discuss solutions, let's make sure everyone feels heard."
• Then shift: "We've diagnosed this well. What's one thing we could try differently this sprint?"

Key things to listen for:

• Gradual empowerment — doesn't flip a switch; progressively transfers decision-making
• Safety creation — team won't self-organize if mistakes are punished
• Clear boundaries — self-organization happens within constraints, not without them

Signs a team is NOT self-organizing:

• SM or PO assigns tasks at the daily standup
• Team waits for direction before starting work
• Only one person makes technical decisions
• Team blames the SM when something goes wrong
• No one speaks up in retrospectives unless asked

Coaching toward self-organization:

1. Stop answering, start asking — when someone asks "What should I do?", respond with "What options do you see?"
2. Pull back visibly — announce: "I'm going to stop jumping in on X. I want the team to own that."
3. Celebrate team decisions — when the team decides something without you, acknowledge it explicitly
4. Create safe-to-fail experiments — let the team try approaches that might not work, then reflect together
5. Working agreements — facilitate the team creating its own rules and holding itself accountable
6. Coach the leader — often one person dominates; coach them to ask for input before sharing their own view

Self-organizing vs. unmanaged:

• Self-organizing teams have clear goals (sprint goal, product vision), shared constraints (DoD, capacity), and mutual accountability
• Unmanaged teams have none of the above — no shared direction, no accountability, no coordination
• The SM's job is to create the conditions for self-organization, not disappear entirely