Agile, Scrum and Delivery

What this area actually covers

Two separate things share one name. The first is Scrum, a deliberately small framework defined in a document of roughly a dozen pages: three accountabilities, five events, three artefacts, and a set of rules about who may decide what. It is short enough to read in twenty minutes and specific enough that most disagreements about "whether we are doing Scrum" could be settled by reading it. The second thing is delivery practice — the facilitation, forecasting, dependency management, flow measurement and stakeholder negotiation that a team needs whether or not it uses Scrum at all. Interviews in this area range across both, and confusing them is the commonest reason a candidate sounds shallow.

A great deal gets wrongly bundled into "Scrum". Story points, velocity, planning poker, burndown charts, a Definition of Ready, backlog grooming as a scheduled meeting, Sprint Zero, hardening sprints, and the three questions people still recite at standup are none of them in the framework. Some are useful conventions, some are actively harmful, but a candidate who presents them as Scrum has revealed that their knowledge came from a course deck rather than the source. Equally, project management is adjacent but distinct: a delivery manager owns a plan, a budget and a set of external dependencies, which Scrum does not describe at all.

The boundary with engineering management matters too. Scrum says nothing about performance reviews, hiring, compensation or careers. Those belong to the manager, and one recurring organisational failure is a Scrum Master who drifts into them without the authority or the accountability that should accompany them.

The seven areas underneath

This section covers the definitional material, the practical craft and the situations, in that order, because interviews in this area move through the three in a predictable sequence: a few questions to check you have read the Guide, then a longer stretch on how you actually run things, then scenarios.

Scrum Framework covers roles, artefacts, events and the rules about who decides what, answered from the Guide rather than from a training deck. It comes first because these questions come first in every interview and because getting one wrong is disproportionately damaging: an interviewer who hears velocity described as part of Scrum stops treating your later answers as informed. Open it for the definitions, the commitments attached to each artefact, and the half-dozen widely believed claims that are simply not in the document.

Facilitation & Ceremonies is the craft of running the events so that each produces its intended output: a Sprint Goal rather than a ticket list, a Daily Scrum owned by the developers rather than a status report to you, a Review where stakeholders actually inspect working software, a Retrospective that changes something. It exists as its own subsection because the framework specifies the purpose of each event and says almost nothing about technique, and technique is where the difference between a useful hour and a wasted one lives.

Backlog & Estimation covers refinement, story splitting, relative sizing against absolute estimates, planning poker and its failure modes, and forecasting a delivery date you are willing to defend. It is separate because it is the most contested territory in the discipline — reasonable practitioners disagree about whether to estimate at all — and because the interview questions here are practical: split this epic, forecast this backlog, explain this variance.

Metrics & Flow deals with velocity and its misuse, burndown and burnup, cycle time distributions, cumulative flow diagrams, throughput and probabilistic forecasting. It has its own area because it is where the discipline becomes quantitative and where most candidates are weakest; it is also the material that converts an opinion about a date into a defensible range.

Impediments & Conflict is about the work that sits outside the team: a shared platform team that will not commit, an environment queue, a security review with a three-week turnaround, and the intra-team disputes that a facilitator has to handle without positional authority. It is separated out because it is the part of the job that is genuinely hard and genuinely unglamorous, and because interviewers use it to distinguish people who have done the work from people who have attended the course.

Scaling & Frameworks covers SAFe, LeSS, the widely misattributed Spotify-model material, and the underlying mechanics of multi-team dependency management and release trains. It exists as its own subsection because scaled environments are where a large share of the paid roles are, and because the frameworks make specific claims that you should be able to describe accurately before you criticise them.

Scrum Scenarios works through situations live: a Product Owner who will not prioritise, a team that has stopped doing retrospectives, scope injected mid-sprint by someone senior. It sits last because scenarios draw on all the preceding material at once, and because this is the format most interviews in this area actually use.

Where it sits in a real business

Delivery sits at the join between a commercial promise and a team's capacity, which is why the work is political rather than procedural. A commitment enters from sales, a regulator, a board deck or a customer contract. Somewhere it has to become a sequence of increments with a defensible date, and someone has to say out loud when the arithmetic does not work.

Follow one piece of work through. A stakeholder wants a feature. The Product Owner decides where it sits in a single ordered Product Backlog, which is the only queue that matters, and refines it until the team can size it. At Sprint Planning the team commits to a Sprint Goal, not to a list, and builds a Sprint Backlog it owns. For the next one to four weeks they produce an Increment that meets a Definition of Done, meaning genuinely releasable rather than "dev complete". At the Sprint Review stakeholders inspect that increment and the backlog is adapted in response; at the Retrospective the team changes how it works. The money loop closes when the increment reaches users, which is the step organisations most often break by keeping Scrum inside engineering while release remains quarterly and gated.

flowchart TD
    A[Stakeholder need arrives] --> B[Product Owner orders the Product Backlog]
    B --> C[Refinement until the team can size it]
    C --> D[Sprint Planning sets a Sprint Goal]
    D --> E[Sprint Backlog owned by the developers]
    E --> F[Increment meeting the Definition of Done]
    F --> G{Released to users}
    G -->|Yes| H[Review inspects real feedback]
    G -->|No, quarterly gate| I[Review inspects a demo]
    H --> B
    I --> B

The fork near the bottom is the whole argument. Both paths run the same events and cost the same amount of meeting time; only the left one produces the information the events exist to gather. An organisation on the right-hand path has bought the ceremony without the feedback, and no amount of better facilitation repairs it.

That is the point worth internalising before any interview here. Scrum's mechanics only pay for themselves if inspection happens against real working software in front of real stakeholders, and a candidate who can identify that gap in a described situation is demonstrating the one diagnostic skill the role is for.

Who does this work

The Scrum Master facilitates events, coaches the Product Owner and the team, and works on impediments that sit outside the team's control. Done well it is unglamorous systems work: noticing that three sprints of carry-over trace to one shared platform team, then fixing the dependency rather than the estimate. The Product Owner owns ordering and value, and is the single most load-bearing accountability in the framework; a passive Product Owner breaks Scrum more thoroughly than a weak Scrum Master does. Developers — everyone building the increment, whatever their specialism — own the Sprint Backlog, the plan and the quality bar.

Around that sit delivery managers, who own dates, cross-team plans and reporting into a programme; agile coaches, who work above team level on how the organisation itself operates; and Release Train Engineers in SAFe organisations, who are essentially chief Scrum Masters for a group of teams. In small companies one person holds several of these at once. A working day is mostly conversations, a small amount of arithmetic on flow data, and a persistent effort to make an invisible constraint visible to someone who can remove it.

The distinction that matters most in practice is between facilitating and deciding. A Scrum Master does not order the backlog, does not assign work, does not set the technical approach and does not appraise anyone. Every one of those boundaries is crossed routinely in real organisations, usually because there is a vacuum and someone competent fills it, and every crossing is worth being able to discuss in an interview: what you did, why it was the wrong shape, and what you did to hand it back.

The framework, in the terms the Guide uses

Definitional questions open most interviews in this area, and they are trivially easy to get right and surprisingly commonly got wrong. The 2020 Scrum Guide describes a Scrum Team of ten or fewer people, with three accountabilities, five events and three artefacts, each artefact carrying a commitment.

The five events are the Sprint itself, which contains the other four, plus Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. The Sprint is a month or less. The Daily Scrum is fifteen minutes, is for the developers, and the Guide does not prescribe the three questions people recite in it. Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint, the Review to four and the Retrospective to three, with shorter Sprints usually taking less. Only the Product Owner may cancel a Sprint.

Underneath sit three pillars — transparency, inspection and adaptation — and five values: commitment, focus, openness, respect and courage. The pillars are worth more than they sound, because they give you the reason for every event. Inspection is pointless without transparency, which is why a Review of a demo rather than a releasable increment produces nothing, and adaptation is what distinguishes a Retrospective that changes something from a meeting where people list grievances.

Knowing this precisely has a specific interview value beyond the definitional questions. When you are asked what you would do about a dysfunctional practice, being able to say "that is not in the framework, but here is why the team adopted it and whether it is helping" is a much stronger answer than either defending the practice as Scrum or condemning it as heresy.

Demand, adoption and how that is changing

Framework adoption remains very wide — Scrum is the default for software teams in most enterprises and has been for over a decade — and demand for the skills follows that. The dedicated job, however, has contracted noticeably, and pretending otherwise would make this page useless.

Three forces drove it. Cost pressure from 2022 onward targeted roles whose contribution to output was hard to evidence, and a full-time facilitator on a nine-person team is an easy line to question; some large employers, notably Capital One in early 2023, publicly eliminated their agile-role population outright. Second, the work was absorbed rather than deleted: engineering managers, tech leads and product managers now run the events themselves, which is often a better arrangement because the person facilitating also has the authority to act on what surfaces. Third, the credential became cheap. When a two-day course produces a certificate, the certificate stops distinguishing candidates and interviewers respond by probing judgement instead, which is exactly why this section is scenario-heavy.

What remains healthy is delivery leadership at scale and inside regulated or heavily-dependent programmes, where coordinating fifteen teams is a real and hard job. Treat this as a steady market for the capability and a shrinking one for the standalone title, and plan accordingly: this is a strong second skill and a fragile only skill.

The practical consequence for your preparation is that interviews have moved away from definitions and towards evidence of effect. The question is no longer whether you can describe a Retrospective; it is what changed in your team because of one, and how you know. Candidates who prepared for the older shape of interview describe process faithfully and score badly, and they usually leave the room thinking they did well.

What makes it hard

The framework is trivial to learn and hard to hold. Everything in Scrum is a mechanism for forcing an uncomfortable conversation to happen on a schedule, and the difficulty is entirely in surviving the pressure to soften it. A stakeholder wants scope added mid-sprint. A director wants velocity in a performance review. A Product Owner would rather not choose between two stakeholders. Each time, the procedurally correct answer is obvious and the socially expensive one is the same answer. Most degraded Scrum implementations are not the result of ignorance; they are the accumulated residue of someone taking the comfortable option forty times.

Second, you are accountable for outcomes with no positional authority whatsoever. The impediments that matter most — a shared team that will not commit, an environment queue, a security review with a three-week turnaround — belong to people who do not report to you and have their own priorities. Influence is the only instrument, and it works slowly.

Third, measurement is genuinely subtle. Any delivery number you publish and reward will be optimised directly, and most of them corrupt when that happens. Velocity is the textbook case: it is an internal capacity input that becomes meaningless the moment it is a target, because inflating it requires no deceit at all, merely slightly larger estimates. Knowing which numbers survive being watched and which do not is where practitioners separate from certificate holders.

Fourth, and least often named, is that the role has no natural evidence of its own contribution. When a team delivers well, the credit belongs to the team, and when it delivers badly the facilitator is visible. That asymmetry is why the position is fragile in a downturn, and it is why the practitioners who last are the ones who keep a written record of the impediments they removed and what each one was costing before it went.

Scope injection, as it really arrives

The commonest scenario question in this area is mid-sprint scope injection, and the reason it discriminates is that the wrong answer is the polite one. Watch where the decision belongs.

sequenceDiagram
    participant D as Director
    participant S as Scrum Master
    participant P as Product Owner
    participant T as Developers
    D->>S: This has to go in this sprint
    S->>D: What is the deadline behind it
    S->>P: New item, and here is the deadline
    P->>T: Does it fit against the Sprint Goal
    T-->>P: Only if the reporting item comes out
    P->>D: We can do it, and reporting slips a sprint
    D-->>P: Accepted
    P->>T: Swap confirmed, Sprint Goal unchanged

The move that matters is the third arrow. The Scrum Master does not accept, does not refuse and does not negotiate the trade — they route the decision to the person accountable for it and make sure the cost is named before anyone agrees. A facilitator who says yes has quietly taken the Product Owner's job; one who says no has taken it as well, in the other direction. Interviewers are watching for that routing, and for whether you asked about the deadline before you asked about anything else, because half of all urgent requests dissolve when someone asks what date they are actually attached to.

The one case where the answer is different is when the Sprint Goal itself is no longer worth pursuing. That is the situation the Guide reserves for cancelling the Sprint, and it is the Product Owner's decision alone. Being able to name that, and to say that you have never seen it used, is a more informed answer than pretending it is a routine tool.

The numbers that survive being watched

Flow metrics are the part of this discipline that converts opinion into argument, and they are also where an interviewer can tell in ninety seconds whether you have used them. The distinction to hold is between a number that describes the system and a number that describes the team's estimating habits.

The important habit is to look at the distribution rather than the average. Average cycle time hides the item that sat for six weeks waiting on a security review, and that item is the one worth a conversation. An eighty-fifth percentile is a far more useful thing to quote to a stakeholder, because it is the number you can actually promise against.

Forecasting from throughput rather than estimates is the technique most worth carrying into an interview, and it needs no tooling.

FORECASTING A BACKLOG FROM THROUGHPUT

  Observed, last 10 sprints, items completed per sprint:
    7, 5, 9, 6, 8, 4, 7, 6, 10, 5

  Remaining scope, counted as items:   62
  Expected new items discovered:       about 15 per cent, so treat as 71

  Pessimistic run, using the worst four sprints (4, 5, 5, 6 - mean 5):
    71 / 5   = 15 sprints
  Typical run, using the median of 6.5:
    71 / 6.5 = 11 sprints
  Optimistic run, using the best four (8, 9, 10, 7 - mean 8.5):
    71 / 8.5 = 9 sprints

  What you say to the sponsor:
    "Between nine and fifteen two-week sprints, most likely around
     eleven. That is eighteen to thirty weeks. If you need the low end,
     the lever is scope, not effort - tell me which twenty items can
     go and I will re-run it."

Every number in that calculation comes from the ten observations at the top, and that is the point. The forecast is defensible because someone can check it, it gives a range rather than a false single date, and it ends by naming the lever the sponsor controls. A candidate who produces something of this shape in an interview is demonstrating the thing the discipline is for; a candidate who says "we would estimate the backlog and divide by velocity" has described the same arithmetic without any of the honesty.

Scaling, and what the frameworks claim

A large share of the paid roles in this area are in organisations running multiple teams against one product, and the interview will go there. Describe the frameworks accurately before you evaluate them, because dismissing SAFe fluently is a very common candidate behaviour and interviewers who work inside it hear it as unseriousness.

SAFe organises teams into an Agile Release Train, plans on a cadence through a big-room planning event, and adds roles above team level including the Release Train Engineer. Its critics say it reintroduces the coordination layer agile was meant to remove; its users say coordination existed anyway and is now explicit. LeSS goes the other way, scaling by keeping one Product Owner and one Product Backlog across many teams and adding as little as possible. The material commonly called the Spotify model described how one company was organised at one point in time and was never proposed as a framework, a fact worth knowing because it is frequently cited as though it were a standard.

Underneath the branding, the actual work of scaling is the same three problems in every organisation: a dependency between teams that nobody owns, a shared component team that becomes a queue, and an integration point where the real state of the programme is hidden until late. A strong answer in this territory describes how you would make those three visible, and treats the framework as the vocabulary the organisation happens to use rather than the solution.

Why study it

Study it if you lead a team or expect to. If you are a tech lead or engineering manager, the retrospective that changes something, the forecast that holds, the dependency spotted three weeks early — these are directly load-bearing in your job and nobody is going to teach them to you. The material is unusually cheap to acquire relative to its usefulness: a couple of hours on the Guide plus deliberate practice on your own team's data.

Study it if you already run programmes and want to stop arguing from opinion. Flow metrics and probabilistic forecasting turn "we think about six weeks" into a defensible range with a stated confidence, and that changes how leadership treats you.

Study it too if you are an engineer with no ambition to lead anything, for a narrower and quite practical reason: most of the frustration engineers report about process comes from working inside a degraded version of something whose purpose they never learned. Knowing what a Retrospective is for makes it possible to fix the one you are in, and knowing that velocity is not a productivity measure makes it possible to say so to the person using it as one.

Do not study it as a route into technology from outside. The certification industry markets Scrum Master as an entry point, and it is close to the worst available one — the job market for a certified beginner with no delivery track record is thin, and the roles that do exist increasingly go to people with engineering or product credibility. Do not collect a second or third certificate expecting a different result; interviewers have long since stopped reading them as signal. And if what you want is technical depth or a design-heavy career, this is a detour.

Your first hour

Read the Scrum Guide end to end, which takes about twenty minutes, then spend the remaining forty auditing your own team against it. Produce a two-column table: what the Guide says, and what your team does. Do not editorialise; just record.

Practice                  Guide                          Us
------------------------- ------------------------------ ------------------------------
Sprint Goal               Committed at Planning          None. We commit to 14 tickets.
Daily Scrum owner         Developers, 15 min             SM runs it, ~25 min, status to SM
Increment                 Releasable, meets DoD          "Dev complete", releases monthly
Backlog ordering          One ordered list, one owner     Three lists, two stakeholders
Retro outcome             At least one improvement in
                          the next Sprint Backlog        Notes in Confluence, no owner
Who cancels a Sprint      Product Owner only             Has never happened

Now pick the single row where the gap is doing the most damage — in that example it is the Increment, because a monthly release means no inspection loop and therefore every other event is theatre — and write three sentences on what it would take to close it and who would have to agree. That artefact, an honest gap analysis with one prioritised change, is a better interview answer than any framework recital, and it is roughly what a competent Scrum Master produces in their first fortnight on a new team.

If you have no team to audit, do the same exercise against a team you were on previously, from memory. The recall is imperfect and it does not matter; the value is in noticing which rows you cannot fill, because those are the parts of the framework you have only ever read about.

What this is not

It is not agility. Scrum is one framework in a wider family that includes Kanban, XP and plain flow-based delivery, and for a team doing interrupt-driven support work Kanban is simply the better fit. A candidate who treats Scrum as synonymous with working well has narrowed themselves unnecessarily.

It is not project management with new vocabulary, and the reverse mistake is just as common: Scrum genuinely does not answer how to run a fixed-scope regulatory programme across nine teams, so borrowing planning technique from elsewhere is not heresy.

It is not a productivity system — nothing in it makes a team faster, it only makes reality visible sooner. That distinction is worth being able to state plainly, because a sponsor who expects the former and is sold the latter becomes the person who cancels the transformation eighteen months later.

It is not certification: the credential is an entry ticket to a screening conversation and nothing more. And it is not a management role, however often the Scrum Master is asked to appraise the people they facilitate.

The framework takes twenty minutes to learn and years to hold under pressure, and every interview in this area is designed to find out which of the two you have done.