Loading...
Scrum master, agile coach, and delivery-manager interviews, where framework recall gets you screened in and scenario judgement gets you hired.
21 published across 7 topics.
Roles, artefacts, events, and the Guide-accurate answers to the definitional questions asked first.
Scrum defines three accountabilities (Product Owner, Scrum Master, Developers), five events inside the Sprint container, and three artefacts each carrying a commitment. Each event exists to force one specific inspect-and-adapt decision, and most workplace practices sit outside the framework entirely.
The Definition of Done is one shared quality standard every increment must meet, owned by the Scrum Team unless the organisation mandates a stricter minimum. An item that misses it is not partially done: it returns to the Product Backlog rather than being released or presented as complete.
Scrum's Sprint assumes work that can be planned a fortnight ahead, held stable for that fortnight, and shaped into a goal worth committing to. Where one of those fails - interrupt-driven support, single-item research, hard external gates - a flow-based approach fits better.
Running each event well, keeping standups useful, and facilitating a retrospective that changes something.
Change what the meeting is about rather than how it is run: inspect the board against the Sprint Goal instead of polling individuals, stop being the person addressed, and push detail into a follow-on conversation. If the Sprint has no real goal, no format will save the event.
A retrospective changes something when it ends with one owned improvement that enters the next Sprint Backlog as work. Disengagement is nearly always evidence that previous actions went nowhere, so the fix is to close the loop on old commitments before redesigning the format.
Check whether the increment is genuinely usable before blaming the diary, because stakeholders skip reviews that give them nothing to react to. Then invite fewer and better people, ask questions that require a decision rather than applause, and be willing to say the review is the wrong forum for this product.
Refinement, story splitting, story points versus absolutes, planning poker, and forecasting.
Treat the backlog as inventory with a carrying cost, delete rather than archive the items nobody will ever order, and derive how deep to refine from the team's measured throughput instead of refining everything. Refinement that clarifies nothing is usually missing a decision, not a better format.
Split vertically, so each slice goes end to end and delivers something demonstrable, using patterns such as workflow steps, business-rule variations, happy path first, and data or interface variants. Splitting by layer or by half a Sprint is not splitting - it produces work that cannot be reviewed or shipped.
Points are relative sizes that trade false precision for a fast conversation whose real output is surfaced disagreement. Estimates that are always wrong are a system symptom, so diagnose unclear criteria, oversized stories, invisible work and interruptions, then forecast with throughput and cycle time.
Velocity misuse, burndown and burnup, cycle time and CFDs, and Monte Carlo forecasting.
Forecast from the whole spread of observed weekly throughput rather than its average, subtract the rate at which the backlog is growing, and give a date with a confidence attached. Then say plainly whether you are offering a forecast or accepting a commitment, because they are not the same promise.
DORA now publishes five measures, three of throughput and two of instability, and they work because improving one dishonestly tends to show up in another. Report them as trends for a delivery system rather than as a per-team league table, and never let them into individual performance conversations.
Track throughput, cycle-time distribution and flow efficiency, because they describe the system rather than the estimate. Velocity is denominated in a unit the team defines, so making it a target lets the number rise without any change in delivered output, and it stops measuring anything.
Removing blockers you do not control, protecting the team, and resolving intra-team conflict.
Price the delay in developer-days from the board's own timestamps, then escalate with a specific ask, an owner and a date rather than a complaint. Decide honestly whether this is an impediment somebody can remove or a constraint to design around, and watch for the workaround that hides the cost.
Treat four misses as data about the system rather than a verdict on the team: find out whether the goal is set by the team or handed to it, whether unplanned work arrives mid-sprint, and whether done is being deferred, then fix the cause you find instead of shrinking the commitment.
Separate the technical disagreement from the interpersonal one, since only the first belongs in the open. Speak to each privately about specific observed behaviour and its effect, look for a structural cause such as unclear ownership, and escalate when it becomes conduct or performance.
SAFe, LeSS, and Spotify-model claims, plus multi-team dependency and release-train mechanics.
Reduce dependencies before coordinating them, by moving team boundaries towards whole slices of value and replacing synchronous handoffs with contracts. Coordinate what remains with a visible dependency board and one ordered backlog. SAFe buys alignment and a planning cadence at real cost in batch size and process.
Very little has to be common, and one thing genuinely does: teams releasing one product must share a Definition of Done. Standardise what a joint release depends on, leave cadence, boards and estimation units local, and refuse uniformity whose only benefit is a comparable dashboard.
Start from the business problem and the place where work actually waits, then change the system around the teams - funding, governance, handoffs, utilisation targets. Transformations disappoint because the team-level ceremonies are adopted and the management system that produced the delay is left untouched.
Situations to work through: a PO who will not prioritise, a team that skips retros, mid-sprint scope injection.
Do not argue about priority in the abstract; make the cost of not choosing visible by showing capacity against the ask, then force a decision through a mechanism that requires ordering rather than asking for agreement.
Make the shortfall visible today, then have the Developers and Product Owner renegotiate scope against the Sprint Goal, which is the commitment while the item list is not. Finish work in progress, keep the Sprint length fixed, and return what is unfinished to the Product Backlog for reordering.
Do not open with the Scrum Guide. Show what pre-assignment costs in flow terms, since assigning everyone an item on day one puts the whole Sprint in progress at once and stretches cycle time. Then find out what the manager needs from it and offer a mechanism that meets that need without the assignment.