An 8-person team completed 31, 28, 34, 30, 29, 33, 27, and 32 points across eight 2-week Sprints; how would you answer a request to promise the next Sprint from this velocity series?

I would use that velocity only as a local planning signal and would not turn it into a promise or a performance score. - The sorted series is 27, 28, 29, 30, 31, 32, 33, 34, so the median is 30.5 and the observed range is 27 to 34 points. - I would retain the 27 to 34 range only if team membership, Sprint length, and estimation practice remain comparable, because points have no valid meaning across teams. - The forecast note would show the range and assumptions, while Sprint Planning would still select work around one Sprint Goal and the Developers' actual capacity.

A mature team completed 7, 9, 6, 8, 10, 7, 8, 9, 5, 8, 7, and 9 work items in 12 weeks; what throughput view would you prepare for the next monthly review?

I would present throughput as a distribution over time, not collapse it into one target. - The 12-week median is 8 items, the observed range is 5 to 10, and the total is 93 items, or 7.75 per week. - The chart would show weekly counts plus a 4-week rolling median, with separate series for features, defects, and maintenance if their sizes differ materially. - I would flag a sustained shift only after at least 4 comparable weeks, then inspect policy or demand changes rather than asking the team to chase a quota.

You receive a CSV of 60 completed items with key, work_type, started_at, and done_at for the last 10 weeks; how would you calculate and explain cycle-time percentiles?

I would calculate elapsed time from started_at to done_at and report a percentile distribution by comparable work type. - After sorting 60 durations, nearest-rank p50 is item 30, p85 is item 51, and p95 is item 57, which keeps the tail visible. - The analysis sheet would state calendar versus working days, timezone, start and end status mappings, and whether reopened time is included. - I would use p85 as a service expectation only after checking at least 30 comparable items, while p95 prompts inspection of rare delay causes rather than a delivery promise.

A quarter extract contains 90 items with requested_at, started_at, released_at, and work_type; how would you separate lead time from cycle time and locate waiting time over 13 weeks?

I would calculate lead time, cycle time, and queue time for each item before comparing their distributions. - For every row, queue time equals started_at minus requested_at, cycle time equals released_at minus started_at, and lead time equals their sum under one calendar and timezone rule. - I would sort the 90 row-level values separately and report p50 and p85 by work_type; I would never subtract the lead-time p85 from the cycle-time p85 because those ranks can represent different items. - I would target a persistently high queue-time percentile with an intake or WIP experiment, then check after 4 weeks that waiting fell without cycle time or quality worsening.

A board snapshot has 14 in-progress items with started_at dates, and 4 items are 12 days old against an 8-day p85 service expectation; how would you use work item age today?

I would make the four aging items a flow conversation, not label their owners as slow. - Work item age is today minus started_at and includes blocked or waiting time, so 12 days is 150 percent of the 8-day expectation. - An aging-WIP chart would order all 14 items by age, mark the 8-day line, and add blocked reason and next action for every item beyond it. - At the Daily Scrum, the Developers could swarm or split the oldest item; I would review the policy if more than 20 percent of WIP exceeds the line for 2 weeks.

An 8-week cumulative flow diagram built from daily status counts shows the Test band widening from 5 to 18 items while Done keeps a steady slope; what would you inspect and change?

I would treat the widening Test band as growing WIP and inspect the constraint before changing team commitments. - I would verify status mapping and calculate net accumulation as arrivals to Test minus departures, which is 13 extra items across 8 weeks. - The review artifact would pair the diagram with the 5 oldest Test items, wait reasons, defect returns, and available test capacity. - A 2-Sprint experiment could cap Test WIP at 6 and trigger swarming at 5, succeeding if the band narrows without p85 cycle time or post-release defects worsening.

A 6-Sprint burnup table shows total scope rising from 120 to 155 items while completed scope reaches 20, 45, 69, 90, 111, and 132; how would you brief stakeholders?

I would use the burnup to separate delivery progress from scope growth and make both trends visible. - The team completed 132 of 155 items, leaving 23, while scope added 35 items, or 29 percent of the original 120. - Completion increments are 20, 25, 24, 21, 21, and 21, so a recent median near 21 is a scenario input, not a guaranteed finish rate. - The one-page brief would show both lines, the remaining scope, major additions, and a range based on historical throughput for the next 2 to 3 Sprints.

For 40 items closed over 6 weeks, an export with cycle_hours, blocked_hours, and blocked_reason totals 3,200 cycle hours and 480 blocked hours; how would you report blocked time and choose an improvement threshold?

I would aggregate blocked time by elapsed hours and reason rather than average item percentages. - The portfolio-safe calculation is sum of blocked_hours divided by sum of cycle_hours; 480 blocked hours over 3,200 cycle hours equals 15 percent. - A Pareto table would show blocked hours, item count, median duration, and owner of the next system action for each reason. - I would investigate any reason contributing over 30 percent of blocked hours or any item blocked beyond 2 working days, then review the trend after 4 weeks.

During 10 weeks, 80 released items produced 12 post-release follow-up records, including 5 customer-visible defects; how would you define and use an escaped-work measure?

I would define escaped work explicitly as follow-up discovered after the agreed Done or release boundary and keep severity visible. - The raw follow-up rate is 12 divided by 80, or 15 percent, while customer-visible defects are 5 divided by 80, or 6.25 percent. - The dataset would link each follow-up to source item, discovery date, severity, cause category, and whether the Definition of Done check should have caught it. - I would inspect a 4-week rolling rate and the severe cases, then change a quality policy only if the same cause repeats at least 3 times.

A 10-week dataset has 100 completed rows with work_type, active_hours, wait_hours, and elapsed_hours, totaling 1,600 active hours and 5,000 elapsed hours; how would you calculate flow efficiency without presenting a misleading average?

I would calculate flow efficiency as active time divided by elapsed time and segment it before summarizing. - At aggregate level, 1,600 active hours over 5,000 elapsed hours is 32 percent; averaging 100 row percentages would overweight tiny items. - A box plot would show feature, defect, and maintenance distributions with item counts, p50, and p85 wait time for each type. - I would target a named wait state only when it contributes over 25 percent of elapsed time for 4 weeks, because maximizing utilization can make flow worse.

Over 10 weeks, an intake table records 96 arrivals and 82 completions, with weekly columns for requested, started, and done; how would you assess flow stability?

I would compare arrival and departure rates and show the resulting queue growth. - Net inventory increased by 14 items because 96 arrived and 82 completed, before accounting for any canceled work. - The chart would plot weekly arrivals, starts, completions, and cumulative ready plus in-progress counts with a 4-week rolling median. - If arrivals exceed completions by more than 10 percent for 4 consecutive weeks, I would bring intake policy and ordering options to the Product Owner and team.

For a 12-week flow review, you have weekly throughput, p50 and p85 cycle time, current item age, blocked percent, and escaped-work counts; what 1-page metric brief would you build?

I would build a balanced flow brief that answers forecasting, delay, current risk, and quality questions together. - The top row would show 12-week throughput distribution, p50 and p85 cycle time, and the count of WIP items beyond the age expectation, all with definitions. - The second row would show blocked-time Pareto and escaped work by severity, with links to the 3 most material system actions. - The footer would record the data window, filters, sample sizes, and a rule that no single metric triggers action until a second signal confirms it for at least 2 weeks.

A team has weekly throughputs of 6, 8, 7, 9, 5, 8, 7, 10, 6, 8, 9, and 7 over 12 weeks and 42 comparable items remaining; how would you make an evidence-based forecast?

I would forecast from the empirical throughput distribution and present a range rather than divide by an average and promise a date. - The history totals 90 items with a median of 7.5 per week, so 42 items is roughly 6 weeks at the median before uncertainty is modeled. - I would resample the 12 weekly values into many completion paths and report the 50th, 70th, 85th, and 95th percentile finish weeks. - The forecast card would state that scope, item granularity, capacity, and working policy must remain comparable, with a weekly refresh as each new throughput arrives.

You have 64 remaining items, 20 weeks of historical throughput, and a request for a date forecast using 50,000 Monte Carlo trials; how would you construct and validate it?

I would simulate weekly throughput until each of 50,000 trials completes all 64 items, then read dates from the resulting distribution. - Each trial samples with replacement from the 20 observed weekly throughputs and accumulates them until the remaining count reaches zero. - The output table would show finish dates at 50, 70, 85, and 95 percent probability plus the history window, exclusions, and zero-throughput weeks. - I would backtest on at least 5 earlier cutoffs and revisit the model if fewer than about 85 percent of actual finishes fall inside its stated 85 percent forecast boundary.

A fixed review is 6 weeks away, and the team has 20 weeks of throughput history for a backlog of 70 similarly sliced items; how would you forecast scope instead of a date?

I would simulate how many items can finish within the fixed 6-week window and give probability-based scope options. - For every trial, I would sample 6 weekly throughput values from the 20-week history and sum them, repeating this at least 20,000 times. - The scope table would show conservative p15, median p50, and optimistic p85 completion counts, making clear that higher scope carries lower completion probability. - The Product Owner could order a core slice at the 85 percent probability boundary and optional slices above it, with the forecast refreshed weekly.

A stakeholder asks for one date for 48 items, while a 30,000-run forecast gives August 14 at 50 percent, August 28 at 70 percent, and September 11 at 85 percent; how would you communicate the range?

I would present the dates as explicit probability choices tied to a business decision, not hide the uncertainty behind one date. - August 14 means about half of simulated outcomes finish by then, while September 11 covers about 85 percent under the stated assumptions. - The decision note would compare the cost of waiting 4 more weeks with the cost of missing the earlier date and could reduce scope from 48 items if August matters. - I would publish the remaining-scope burnup and refresh all 3 dates weekly, escalating assumption changes when scope shifts over 10 percent.

A 16-week forecast extract contains 120 completed issues, 18 reopen events, 9 split items, 2 holiday weeks, and columns for type and resolution; what data policy would you define before forecasting?

I would define a reproducible counting policy and run sensitivity checks instead of cleaning away inconvenient history. - Count each delivered customer-facing slice once, preserve zero-throughput holiday weeks when they can recur, and document how parent, child, canceled, and reopened records are treated. - The data-quality sheet would reconcile all 120 issues, the 18 reopen events, and the 9 splits to source keys with no silent deletions. - I would compare forecasts with and without the 2 holiday weeks and stop publishing if either treatment moves the 85 percent date by more than 2 weeks without an agreed future-capacity assumption.

A backlog changed from 30 large items to 110 smaller slices over 8 weeks, while the forecast uses 16 weeks of item throughput; how would you handle the granularity shift?

I would not mix the old and new item counts as if one item still represented the same amount of work. - A histogram would compare cycle time and item size proxies before and after slicing, with the change date and counts of 30 versus 110 visible. - I would forecast from post-change history once it has at least 6 representative weeks, while showing a wider provisional range before that threshold. - As a sensitivity check, I would also group new slices back to their parent outcomes and compare that forecast, rejecting any model whose 85 percent date moves over 2 Sprints between views.

A 7-person Scrum Team uses a Ready, Development, Review, Test, Done board and averages 15 concurrent items in each 2-week Sprint; what Scrumban pull policy would you test for 4 weeks?

I would keep Scrum's accountabilities, events, and goals while adding explicit pull and WIP policies to expose flow. - A starting policy could cap Development at 5, Review at 3, and Test at 3, with a person pulling only when the downstream column has space. - The board policy would say that hitting a limit triggers finishing, swarming, splitting, or removing a blocker before new work starts. - After 4 weeks, I would compare p85 cycle time, throughput, blocked time, and Sprint Goal outcomes, retaining the policy only if flow improves without quality loss.

A Scrumban team has 40 ordered backlog items, replenishes twice each week, and has 6 Ready slots; what explicit replenishment policy would you put on a 1-page board guide?

I would make replenishment a small pull decision with clear entry checks and preserve the Product Owner's ordering responsibility. - Every Tuesday and Thursday, the Product Owner and available Developers would fill at most 6 Ready slots from the ordered Product Backlog. - An item can enter Ready when its outcome, acceptance examples, key dependency, and size suitable for the 8-day service expectation are understood, without inventing a mandatory Scrum artifact. - The guide would record who may request an exception, a maximum of 1 exception at a time, and a monthly review using Ready age and blocked-start counts.

Scrum Master interview questions

100 real questions with model answers and explanations for Scrum Master candidates.

See a Scrum Master resume example →

Practice with flashcards

Spaced repetition · Hunter Pass

Questions

agilepromisesdelivery-metrics

I would use that velocity only as a local planning signal and would not turn it into a promise or a performance score.

The sorted series is 27, 28, 29, 30, 31, 32, 33, 34, so the median is 30.5 and the observed range is 27 to 34 points.
I would retain the 27 to 34 range only if team membership, Sprint length, and estimation practice remain comparable, because points have no valid meaning across teams.
The forecast note would show the range and assumptions, while Sprint Planning would still select work around one Sprint Goal and the Developers' actual capacity.

Why interviewers ask this: The interviewer is checking whether the candidate can use velocity for local forecasting without ranking people, comparing teams, or claiming deterministic delivery.

throughput

I would present throughput as a distribution over time, not collapse it into one target.

The 12-week median is 8 items, the observed range is 5 to 10, and the total is 93 items, or 7.75 per week.
The chart would show weekly counts plus a 4-week rolling median, with separate series for features, defects, and maintenance if their sizes differ materially.
I would flag a sustained shift only after at least 4 comparable weeks, then inspect policy or demand changes rather than asking the team to chase a quota.

Why interviewers ask this: The interviewer is evaluating whether the candidate understands throughput variability and avoids turning a flow measure into an output target.

percentiles

I would calculate elapsed time from started_at to done_at and report a percentile distribution by comparable work type.

After sorting 60 durations, nearest-rank p50 is item 30, p85 is item 51, and p95 is item 57, which keeps the tail visible.
The analysis sheet would state calendar versus working days, timezone, start and end status mappings, and whether reopened time is included.
I would use p85 as a service expectation only after checking at least 30 comparable items, while p95 prompts inspection of rare delay causes rather than a delivery promise.

Why interviewers ask this: The interviewer wants evidence that the candidate can define cycle time reproducibly and interpret percentiles without hiding the tail.

releases

I would calculate lead time, cycle time, and queue time for each item before comparing their distributions.

For every row, queue time equals started_at minus requested_at, cycle time equals released_at minus started_at, and lead time equals their sum under one calendar and timezone rule.
I would sort the 90 row-level values separately and report p50 and p85 by work_type; I would never subtract the lead-time p85 from the cycle-time p85 because those ranks can represent different items.
I would target a persistently high queue-time percentile with an intake or WIP experiment, then check after 4 weeks that waiting fell without cycle time or quality worsening.

Why interviewers ask this: The interviewer is testing whether the candidate distinguishes customer waiting from active delivery and computes percentiles from item-level durations rather than subtracting percentile values.

snapshot

I would make the four aging items a flow conversation, not label their owners as slow.

Work item age is today minus started_at and includes blocked or waiting time, so 12 days is 150 percent of the 8-day expectation.
An aging-WIP chart would order all 14 items by age, mark the 8-day line, and add blocked reason and next action for every item beyond it.
At the Daily Scrum, the Developers could swarm or split the oldest item; I would review the policy if more than 20 percent of WIP exceeds the line for 2 weeks.

Why interviewers ask this: The interviewer is checking whether the candidate uses aging data to manage flow collaboratively rather than assess individuals.

I would treat the widening Test band as growing WIP and inspect the constraint before changing team commitments.

I would verify status mapping and calculate net accumulation as arrivals to Test minus departures, which is 13 extra items across 8 weeks.
The review artifact would pair the diagram with the 5 oldest Test items, wait reasons, defect returns, and available test capacity.
A 2-Sprint experiment could cap Test WIP at 6 and trigger swarming at 5, succeeding if the band narrows without p85 cycle time or post-release defects worsening.

Why interviewers ask this: The interviewer is evaluating whether the candidate can read CFD band behavior and design a safe response to a flow constraint.

agilescope-managementstakeholder-management

I would use the burnup to separate delivery progress from scope growth and make both trends visible.

The team completed 132 of 155 items, leaving 23, while scope added 35 items, or 29 percent of the original 120.
Completion increments are 20, 25, 24, 21, 21, and 21, so a recent median near 21 is a scenario input, not a guaranteed finish rate.
The one-page brief would show both lines, the remaining scope, major additions, and a range based on historical throughput for the next 2 to 3 Sprints.

Why interviewers ask this: The interviewer is checking whether the candidate prevents a changing scope line from being mistaken for poor team performance.

I would aggregate blocked time by elapsed hours and reason rather than average item percentages.

The portfolio-safe calculation is sum of blocked_hours divided by sum of cycle_hours; 480 blocked hours over 3,200 cycle hours equals 15 percent.
A Pareto table would show blocked hours, item count, median duration, and owner of the next system action for each reason.
I would investigate any reason contributing over 30 percent of blocked hours or any item blocked beyond 2 working days, then review the trend after 4 weeks.

Why interviewers ask this: The interviewer wants to see a reproducible blocked-time measure tied to system action rather than blame.

releasesdefects

I would define escaped work explicitly as follow-up discovered after the agreed Done or release boundary and keep severity visible.

The raw follow-up rate is 12 divided by 80, or 15 percent, while customer-visible defects are 5 divided by 80, or 6.25 percent.
The dataset would link each follow-up to source item, discovery date, severity, cause category, and whether the Definition of Done check should have caught it.
I would inspect a 4-week rolling rate and the severe cases, then change a quality policy only if the same cause repeats at least 3 times.

Why interviewers ask this: The interviewer is testing whether the candidate can measure escaped work without mixing severities or using defects to judge individuals.

I would calculate flow efficiency as active time divided by elapsed time and segment it before summarizing.

At aggregate level, 1,600 active hours over 5,000 elapsed hours is 32 percent; averaging 100 row percentages would overweight tiny items.
A box plot would show feature, defect, and maintenance distributions with item counts, p50, and p85 wait time for each type.
I would target a named wait state only when it contributes over 25 percent of elapsed time for 4 weeks, because maximizing utilization can make flow worse.

Why interviewers ask this: The interviewer is evaluating whether the candidate understands weighted calculations, segmentation, and the risk of optimizing utilization.

schema

I would compare arrival and departure rates and show the resulting queue growth.

Net inventory increased by 14 items because 96 arrived and 82 completed, before accounting for any canceled work.
The chart would plot weekly arrivals, starts, completions, and cumulative ready plus in-progress counts with a 4-week rolling median.
If arrivals exceed completions by more than 10 percent for 4 consecutive weeks, I would bring intake policy and ordering options to the Product Owner and team.

Why interviewers ask this: The interviewer is checking whether the candidate can connect demand, throughput, and growing inventory without simply asking the team to work faster.

throughputmonitoring

I would build a balanced flow brief that answers forecasting, delay, current risk, and quality questions together.

The top row would show 12-week throughput distribution, p50 and p85 cycle time, and the count of WIP items beyond the age expectation, all with definitions.
The second row would show blocked-time Pareto and escaped work by severity, with links to the 3 most material system actions.
The footer would record the data window, filters, sample sizes, and a rule that no single metric triggers action until a second signal confirms it for at least 2 weeks.

Why interviewers ask this: The interviewer is evaluating whether the candidate triangulates flow and quality signals rather than managing by one number.

throughput

I would forecast from the empirical throughput distribution and present a range rather than divide by an average and promise a date.

The history totals 90 items with a median of 7.5 per week, so 42 items is roughly 6 weeks at the median before uncertainty is modeled.
I would resample the 12 weekly values into many completion paths and report the 50th, 70th, 85th, and 95th percentile finish weeks.
The forecast card would state that scope, item granularity, capacity, and working policy must remain comparable, with a weekly refresh as each new throughput arrives.

Why interviewers ask this: The interviewer is checking whether the candidate bases forecasts on observed delivery and communicates uncertainty honestly.

validationthroughput

I would simulate weekly throughput until each of 50,000 trials completes all 64 items, then read dates from the resulting distribution.

Each trial samples with replacement from the 20 observed weekly throughputs and accumulates them until the remaining count reaches zero.
The output table would show finish dates at 50, 70, 85, and 95 percent probability plus the history window, exclusions, and zero-throughput weeks.
I would backtest on at least 5 earlier cutoffs and revisit the model if fewer than about 85 percent of actual finishes fall inside its stated 85 percent forecast boundary.

Why interviewers ask this: The interviewer is evaluating practical Monte Carlo mechanics, assumptions, and calibration rather than tool-name familiarity.

scope-managementagilethroughput

I would simulate how many items can finish within the fixed 6-week window and give probability-based scope options.

For every trial, I would sample 6 weekly throughput values from the 20-week history and sum them, repeating this at least 20,000 times.
The scope table would show conservative p15, median p50, and optimistic p85 completion counts, making clear that higher scope carries lower completion probability.
The Product Owner could order a core slice at the 85 percent probability boundary and optional slices above it, with the forecast refreshed weekly.

Why interviewers ask this: The interviewer wants to see whether the candidate can invert a forecast for a fixed date without converting uncertainty into a commitment.

stakeholder-managementcommunication

I would present the dates as explicit probability choices tied to a business decision, not hide the uncertainty behind one date.

August 14 means about half of simulated outcomes finish by then, while September 11 covers about 85 percent under the stated assumptions.
The decision note would compare the cost of waiting 4 more weeks with the cost of missing the earlier date and could reduce scope from 48 items if August matters.
I would publish the remaining-scope burnup and refresh all 3 dates weekly, escalating assumption changes when scope shifts over 10 percent.

Why interviewers ask this: The interviewer is checking whether the candidate can turn confidence ranges into a transparent business choice.

schema

I would define a reproducible counting policy and run sensitivity checks instead of cleaning away inconvenient history.

Count each delivered customer-facing slice once, preserve zero-throughput holiday weeks when they can recur, and document how parent, child, canceled, and reopened records are treated.
The data-quality sheet would reconcile all 120 issues, the 18 reopen events, and the 9 splits to source keys with no silent deletions.
I would compare forecasts with and without the 2 holiday weeks and stop publishing if either treatment moves the 85 percent date by more than 2 weeks without an agreed future-capacity assumption.

Why interviewers ask this: The interviewer is evaluating whether the candidate protects forecast integrity through explicit inclusion rules and sensitivity analysis.

backlogthroughputagile

I would not mix the old and new item counts as if one item still represented the same amount of work.

A histogram would compare cycle time and item size proxies before and after slicing, with the change date and counts of 30 versus 110 visible.
I would forecast from post-change history once it has at least 6 representative weeks, while showing a wider provisional range before that threshold.
As a sensitivity check, I would also group new slices back to their parent outcomes and compare that forecast, rejecting any model whose 85 percent date moves over 2 Sprints between views.

Why interviewers ask this: The interviewer is checking whether the candidate recognizes item-size stability as a core assumption of throughput forecasting.

agileconcurrency

I would keep Scrum's accountabilities, events, and goals while adding explicit pull and WIP policies to expose flow.

A starting policy could cap Development at 5, Review at 3, and Test at 3, with a person pulling only when the downstream column has space.
The board policy would say that hitting a limit triggers finishing, swarming, splitting, or removing a blocker before new work starts.
After 4 weeks, I would compare p85 cycle time, throughput, blocked time, and Sprint Goal outcomes, retaining the policy only if flow improves without quality loss.

Why interviewers ask this: The interviewer is evaluating whether the candidate can supplement Scrum with Kanban practices without replacing Scrum or maximizing individual utilization.

agilebacklog

I would make replenishment a small pull decision with clear entry checks and preserve the Product Owner's ordering responsibility.

Every Tuesday and Thursday, the Product Owner and available Developers would fill at most 6 Ready slots from the ordered Product Backlog.
An item can enter Ready when its outcome, acceptance examples, key dependency, and size suitable for the 8-day service expectation are understood, without inventing a mandatory Scrum artifact.
The guide would record who may request an exception, a maximum of 1 exception at a time, and a monthly review using Ready age and blocked-start counts.

Why interviewers ask this: The interviewer is checking whether the candidate can define a pull policy precisely without inventing Scrum accountabilities or a compulsory Definition of Ready.

Locked questions

21
A quarterly service log has 30 items classified as 22 Standard, 5 Fixed Date, 2 Intangible, and 1 Expedite; what classes-of-service policy would you agree with the team?
22
From 80 comparable items completed in 12 weeks, 68 finished within 9 days; how would you define and operate an 85 percent service level expectation?
23
Eight team members have 60 minutes to analyze 24 observations from the last 2 Sprints; how would you use 1-2-4-All to produce 2 retrospective actions?
agile
24
A 9-person team has seen handoff delay recur in 4 Sprints and has a 75-minute Retrospective; how would you facilitate TRIZ without turning it into a complaint session?
agilesessions
25
Nine people need to review 12 recurring team activities in a 90-minute workshop; how would you use Ecocycle Planning to free capacity for the next 6 weeks?
capacity-planningcapacity
26
Two closely related teams, 10 people total, have 60 minutes to decide ownership boundaries for 3 shared API areas; how would you run a Conversation Cafe neutrally?
ownershipapi
27
A 9-person team has a 45-minute workshop to reduce a 17-rule working agreement to 5 essential policies for the next 3 Sprints; how would you use Min Specs?
agile
28
Eight team members must choose among 3 review policies in 40 minutes after hearing competing preferences; what conflict-neutral decision rule and artifact would you use?
artifacts
29
A mature 8-person Scrum Team has 2 hours for Planning a 2-week Sprint, an ordered Product Backlog, a capacity sheet, and a 3-month Product Goal; how would you facilitate the event?
agilecapacity-planningcapacity
30
A 90-minute Sprint Review includes 12 stakeholders, 4 completed outcome slices, a burnup, and 3 changed market assumptions; how would you design it as a working session?
agilestakeholder-managementdesign
31
Eight Developers have relied on the Scrum Master to lead every 15-minute Daily Scrum for 6 months; what 4-week coaching plan would move the event toward team ownership?
agileownership
32
A mature team wants to rotate facilitation of 6 Scrum event sessions across 3 Sprints; what coaching artifact and safety checks would you create to build autonomy?
agilesessionsartifacts
33
An impediment register has 24 entries from 8 weeks with opened_at, impact, owner, next_action, due_at, and closed_at; what operating policy would you establish?
34
A quarterly log contains 36 impediments: 12 access, 9 environment, 8 dependency, and 7 clarification cases, plus blocked hours; how would you choose one systemic improvement for 6 weeks?
dependenciessystem-design
35
Two related teams have 14 dependencies across the next 6 weeks in a table with needed_by, provider, consumer, status, probability_score, and impact_score; how would you manage risk without acting as an RTE?
probabilitydependenciesrisk-management
36
Nine dependency requests over 10 weeks have response times of 2, 3, 3, 4, 4, 5, 6, 7, and 11 days; what service policy would you propose for two related teams?
dependencies
37
Twenty-five stakeholders need weekly visibility for 12 weeks into one team's Product Goal, Sprint Goal, scope, forecast, quality, and 6 open impediments; what dashboard would you publish?
agilescope-managementstakeholder-management
38
A 6-week risk board lists 6 delivery risks with probability_score, impact_score, trigger, mitigation, owner, and review_date; how would you keep it useful in a 20-minute weekly review?
risk-managementprobability
39
A 3-month Product Goal is to reduce median customer onboarding from 12 to 8 minutes, and the Product Backlog has 45 items; how would you create a line-of-sight artifact for the next 6 Sprints?
agileonboardingartifacts
40
A quarterly OKR aims to raise onboarding activation from 42 to 50 percent across 6 Sprints; how would you connect it to Scrum without turning each Sprint Goal into the key result?
agileactivationokrs
41
You have the text of 10 past Sprint Goals from five months and want a 0-to-6 quality rubric; what would you score and what threshold would trigger coaching?
agile
42
Across 8 two-week Sprints, 6 Sprint Goals were achieved, but item completion ranged from 60 to 95 percent; what review artifact would you use to discuss outcome quality?
agileartifacts
43
A Jira board has 300 completed issues from one quarter, 6 workflow statuses, and 4 work types; how would you define an advanced control-chart report for cycle time?
44
You need a Jira cumulative flow view for 12 weeks of daily history across Backlog, Ready, Development, Review, Test, and Done; what dashboard definition and checks would you create?
backlogagile
45
Two related teams share a Jira product board and need a 12-week dashboard with no velocity comparison; which 6 report definitions would you include?
delivery-metrics
46
A 90-day Jira audit covers 500 issues and finds 38 Done issues without Resolution and 62 started issues without a usable start transition; how would you restore reporting hygiene?
47
In 8 weeks, Jira shows 55 blocked events, but 40 percent lack start or end timestamps because Flagged was used inconsistently; what tracking design would you implement?
design
48
A team wants to test lowering the Review WIP limit from 4 to 3 for 4 weeks, using an 8-week baseline of 96 items; how would you pre-register the process experiment?
experimentsconcurrencyagile
49
After a 4-week WIP experiment, Review p85 fell from 6.2 to 4.8 days, throughput moved from 12 to 11.5 items per week, and blocked time fell from 9 to 8 percent across 24 trial items; how would you review the result?
experimentsthroughput
50
A Jira dashboard has 9 charts, 6 inconsistent metric definitions, and 3 months of stakeholder use; what reporting-governance artifact and review cycle would you establish?
stakeholder-managementmonitoringartifacts
51
On day 5 of a Sprint, new experiment evidence shows the Sprint Goal would increase forced sign-ups, while the Product Goal is to reduce 30-day churn. How should the Scrum Team inspect and adapt?
agileexperimentschurn
52
At the end of a four-hour Sprint Planning for a two-week Sprint, Developers have confirmed only 32 of 45 expected Developer-days because on-call and leave remain unresolved. How would you close the timebox with a transparent forecast?
agileon-call
53
Sprint Goal success fell from 70% to 35% across eight Sprints while carryover rose from 12% to 31%, but incoming interruptions stayed near 8%. How would you diagnose the decline?
agile
54
The selected-to-Done ratio dropped from 90% to 62% over six Sprints, and average blocked time rose from 0.7 to 2.6 days. The team says it only needs better estimates. What would you do?
agileestimation
55
On day 4 of a 10-day Sprint, only 2 of 7 goal-related items are Done, one critical item has been blocked for 30 hours, and three have not started. How would you help correct the forecast?
agile
56
For four Sprints, Daily Scrum reports stayed green until day 9, then work aged 7 to 9 days and the Sprint Goal was declared impossible. What would you change?
agile
57
A Scrum Team already holds Daily Scrum, and 9 of 30 recent items breached an 8-day SLE. What would you cover in a weekly Kanban Flow Review, and how is it different from Daily Scrum?
agile
58
A service completed 60 requests last month: 42 Standard, 8 Fixed Date, 6 Intangible, and 4 Expedite; 12 breached their class SLE and 3 Fixed Date items were late. How would you run a Service Delivery Review?
59
6 of 10 planned stories depend on customer research that finishes mid-Sprint, and 4 stories were reversed after new findings in the last 2 Sprints. How would you handle the discovery uncertainty?
agile
60
Refinement marks 90% of items ready, yet integration unknowns create 40% unplanned work each Sprint and goal success is only 50%. What would you test?
agile
61
The Product Owner and sales VP changed the top priority 12 times in two weeks, and the team started 9 items but finished 3. How would you address the conflict?
62
Two stakeholders bypass the Product Owner and send direct requests to Developers; 7 of 18 Sprint items entered through private messages last month. What would you do?
agilestakeholder-managementcommunication
63
An external platform team missed 3 of 4 dependency dates, causing 11 blocked days across your last two Sprints. How would you improve the forecast?
agiledependencies
64
Leadership announces a fixed launch in six weeks with 140 Product Backlog items and asks the team to commit to all of them, although it completed 52 comparable items in the prior six weeks. How would you respond?
agilelaunchesbacklog
65
Five requests arrived during a 10-day Sprint; two were called urgent, three entered immediately, and the Sprint Goal is now at risk on day 6. What would you do?
agilerisk-management
66
The Product Goal is to reduce median invoice reconciliation from 40 to 15 minutes, but Sales asks for the next three Sprints to build a custom approval flow toward a $300,000 quarterly target; usage data shows the flow serves 2% of users and does not affect reconciliation. How would you handle the stakeholder conflict?
agilestakeholder-managementcommunication
67
A customer escalates a severe issue and an account executive promises a fix within 48 hours before the team has diagnosed it; the current Sprint has 3 days left. What would you facilitate?
agileescalationpromises
68
Compliance rejected 4 of 6 items: every rejected item lacked the same audit trail, while two also lacked feature-specific consent evidence. Where should each requirement live, and who decides Done?
69
At Sprint Review, sales asks for bulk export next, support asks to simplify the current flow, and security advises delaying both until a new threat is tested. How would you handle the contradictory feedback?
agilefeedback
70
One team wants to remove API v1 in two weeks, but a consuming team needs six weeks to migrate and no automated compatibility evidence exists. What agreement would you facilitate?
api
71
Two Developers argue publicly on 6 of the last 8 pull requests, and median review time rose from 1 to 3 days. What would you do?
code-review
72
Only one Developer can deploy and roll back the billing service, and that person will be unavailable for two weeks next month. How would you reduce the bus factor without assigning people yourself?
deploymentrollback
73
A remote Developer with a hearing impairment says hybrid Sprint Reviews are unusable because the room has side conversations, no captions, and one shared microphone. How would you accommodate them?
agile
74
In the Sprint Retrospective, the team selects a two-Sprint experiment using an isolated CI runner to reduce a 45-minute test wait, but the organizational platform owner refuses access under the current policy. What would you do?
agileexperiments
75
An experienced team's p85 cycle time rose from 6 to 11 days, so the Developers propose a two-Sprint WIP limit of four. The Product Owner resists because having fewer items in progress appears to lower utilization. How would you handle this?
agileaggregation
76
When you were absent for 3 days, Daily Scrum was canceled twice, the board had no updates, and one blocker waited 26 hours. What would you do on return?
agilecommunication
77
Two Developers independently report that a manager threatened performance consequences after they raised a harassment concern, and one asks you to tell nobody. How would you respond?
performance
78
Two senior Developers are deadlocked over dual-write versus a maintenance window for a payment migration, and the unresolved decision has blocked work for four days. How would you mediate?
migrationslocking
79
A senior Developer declines recurring refinement sessions, and five items were returned because teammates lacked acceptance and integration knowledge that only they had. How would you address the collaboration harm?
sessions
80
Developers and testers blame each other in Daily Scrum; 9 defects were reopened last Sprint, and handoff comments average 14 messages per item. How would you handle the conflict?
agiledefects
81
Production work consumed 35% of team capacity in each of the last four Sprints, but Planning still assumes none; three of four Sprint Goals were missed. What would you change?
agilecapacity-planningcapacity
82
The team handles 23 support requests per week in Slack, but only 6 appear on the board and support work is absent from Sprint inspection. What would you do?
agile
83
One engineer loses about 2 days per Sprint to on-call while four teammates lose under half a day, and the on-call engineer carries over work in 5 of 6 Sprints. How would you respond?
agileon-call
84
Defect work rose from 18% to 31% of completed items over five Sprints, and 40% of fixed defects reopened once. What would you do?
agiledefects
85
QA returns 27% of items because acceptance examples are missing, and returned items spend a median 2.3 extra days in progress. What experiment would you facilitate?
experiments
86
The same component caused 4 production incidents in 6 weeks, but incident reviews happen separately and none of their findings reached the Product Backlog. What would you do?
backlogcomponentsincidents
87
Post-incident reviews produced 14 action items in two months, but only 2 were completed and 8 have no owner. How would you restore follow-through?
trackingincidents
88
To meet a feature date, a director asks the team to bypass two Definition of Done checks for 3 stories; escaped defects already rose from 2 to 7 last month. What would you do?
defectsdod
89
The support queue has 17 items, its 85th-percentile age is 9 days against a 3-day expectation, and new requests arrive faster than they finish for four weeks. What would you facilitate?
percentilesdata-structures
90
On-call handoffs between two teams caused 6 escalations in a month; ownership was unclear for a median 95 minutes, and both teams maintain different runbooks. What would you do?
ownershipon-callrunbooks
91
A team using two-week Scrum receives 55% unplanned service work and priorities change daily; only 3 of the last 8 Sprint Goals survived. How would you judge a move toward Scrumban or Kanban?
agile
92
An 8-person team set a per-person WIP limit of 2, yet 14 items remain active, median cycle time is 9 days, and everyone says the limit is being followed. How would you redesign the experiment?
experimentsagile
93
A WIP limit of 6 was breached 11 times in one Sprint because the team moved blocked items to a parking column and stopped counting them. What would you do?
agileschema
94
Reported cycle time improved from 6 to 3 days after the team began closing tickets at code complete and opening follow-up tickets for testing; customer delivery time stayed at 8 days. How would you handle the gaming?
testing
95
Management set a 20% velocity-growth target; points rose from 28 to 46 in three Sprints, but Sprint Goal success stayed at 50% and completed item count was flat. What would you do?
agiledelivery-metrics
96
A completed two-Sprint experiment reduced peer review from two reviewers to one; cycle time fell from 5.2 to 4.0 days, but escaped defects rose from 2 to 8 against a guardrail of at most 3. What would you do?
agiledefectsexperiments
97
The team replaced Daily Scrum with asynchronous updates for a month; meeting time fell by 75%, but median blocker age rose from 0.8 to 2.4 days and two Sprint Goals were missed. How would you react?
agilereactasync
98
After refinement was cut from 90 to 30 minutes, the ready queue fell from 12 items to 3 and Sprint Planning expanded from 90 minutes to 3 hours twice. What would you do?
agiledata-structures
99
A trade-show capability loses most of its value after October 31, and comparable items have a 12-calendar-day p85 SLE. Today is October 10; which class of service fits, and what is the latest responsible start?
100
You introduced 3 process changes in 5 Sprints, two were abandoned, and a team pulse shows trust in improvement experiments fell from 4.0 to 2.6 because people say outcomes were predetermined. How would you restore trust?
agileconcurrencyexperiments

Questions

1An 8-person team completed 31, 28, 34, 30, 29, 33, 27, and 32 points across eight 2-week Sprints; how would you answer a request to promise the next Sprint from this velocity series?

2A mature team completed 7, 9, 6, 8, 10, 7, 8, 9, 5, 8, 7, and 9 work items in 12 weeks; what throughput view would you prepare for the next monthly review?

3You receive a CSV of 60 completed items with key, work_type, started_at, and done_at for the last 10 weeks; how would you calculate and explain cycle-time percentiles?

4A quarter extract contains 90 items with requested_at, started_at, released_at, and work_type; how would you separate lead time from cycle time and locate waiting time over 13 weeks?

5A board snapshot has 14 in-progress items with started_at dates, and 4 items are 12 days old against an 8-day p85 service expectation; how would you use work item age today?

6An 8-week cumulative flow diagram built from daily status counts shows the Test band widening from 5 to 18 items while Done keeps a steady slope; what would you inspect and change?

7A 6-Sprint burnup table shows total scope rising from 120 to 155 items while completed scope reaches 20, 45, 69, 90, 111, and 132; how would you brief stakeholders?

8For 40 items closed over 6 weeks, an export with cycle_hours, blocked_hours, and blocked_reason totals 3,200 cycle hours and 480 blocked hours; how would you report blocked time and choose an improvement threshold?

9During 10 weeks, 80 released items produced 12 post-release follow-up records, including 5 customer-visible defects; how would you define and use an escaped-work measure?

10A 10-week dataset has 100 completed rows with work_type, active_hours, wait_hours, and elapsed_hours, totaling 1,600 active hours and 5,000 elapsed hours; how would you calculate flow efficiency without presenting a misleading average?

11Over 10 weeks, an intake table records 96 arrivals and 82 completions, with weekly columns for requested, started, and done; how would you assess flow stability?

12For a 12-week flow review, you have weekly throughput, p50 and p85 cycle time, current item age, blocked percent, and escaped-work counts; what 1-page metric brief would you build?

13A team has weekly throughputs of 6, 8, 7, 9, 5, 8, 7, 10, 6, 8, 9, and 7 over 12 weeks and 42 comparable items remaining; how would you make an evidence-based forecast?

14You have 64 remaining items, 20 weeks of historical throughput, and a request for a date forecast using 50,000 Monte Carlo trials; how would you construct and validate it?

15A fixed review is 6 weeks away, and the team has 20 weeks of throughput history for a backlog of 70 similarly sliced items; how would you forecast scope instead of a date?

16A stakeholder asks for one date for 48 items, while a 30,000-run forecast gives August 14 at 50 percent, August 28 at 70 percent, and September 11 at 85 percent; how would you communicate the range?

17A 16-week forecast extract contains 120 completed issues, 18 reopen events, 9 split items, 2 holiday weeks, and columns for type and resolution; what data policy would you define before forecasting?

18A backlog changed from 30 large items to 110 smaller slices over 8 weeks, while the forecast uses 16 weeks of item throughput; how would you handle the granularity shift?

19A 7-person Scrum Team uses a Ready, Development, Review, Test, Done board and averages 15 concurrent items in each 2-week Sprint; what Scrumban pull policy would you test for 4 weeks?

20A Scrumban team has 40 ordered backlog items, replenishes twice each week, and has 6 Ready slots; what explicit replenishment policy would you put on a 1-page board guide?

Locked questions