Three days into a two-week sprint, a stakeholder asks for "just one small addition" to a story that's already in progress.

What is actually happening (the mental model).

A sprint's whole value is that it's a protected, fixed commitment — the team agreed to a specific slice of work based on a specific capacity, and every "just one small addition" that gets waved through quietly erodes that protection, training stakeholders that the sprint boundary is negotiable whenever they ask nicely.

How to work through it.

1. Size the addition honestly with story points, exactly as if it were a new backlog item — "small" is a feeling, not a measurement.
2. If it fits inside remaining capacity without displacing anything, it can go in — but explicitly, not quietly, so the team's actual delivered scope stays honest.
3. If it doesn't fit, something else has to come out — surface that trade-off to the stakeholder directly rather than letting the team silently absorb it through unpaid overtime or a compressed "done."
4. Log the addition and its impact so it shows up in the sprint's own numbers, rather than becoming invisible extra work that makes next sprint's capacity planning wrong.

The root causes and trade-offs.

Saying yes without sizing leads to invisible scope growth that corrupts future capacity planning, while saying no rigidly with no negotiation can feel bureaucratic for a genuinely small, urgent ask. The trade-off is resolved by making the size and its consequence visible, and then letting the team or the product owner make an informed trade, rather than reacting with a reflexive yes or no.

The trap that less-experienced engineers fall into.

Agreeing to "just one small thing" without sizing it or naming what it displaces — a pattern that, repeated a few times a sprint, quietly turns every sprint commitment into fiction.

🎯 Interviewer follow-up questions you should expect.

• "How do you handle a stakeholder asking for something mid-sprint?" You size it honestly, then make the trade-off, what it displaces, explicit rather than silently absorbing it.
• "Isn't refusing small requests bad for stakeholder relationships?" It's not refusal — it's making the real cost visible so the decision is informed, not reflexive.

A story sized at 3 points is, three days in, clearly going to take the effort of an 8 — and it's the only thing anyone's working on.

What is actually happening (the mental model).

Story points are an estimate made with the information available at refinement — a genuine underestimate discovered mid-sprint isn't a failure of the process, it's new information, and the right response is about protecting the rest of the sprint's commitment, not about assigning blame for a wrong guess.

How to work through it.

1. Surface it immediately, ideally at the next stand-up or the mid-sprint check — the worst version of this is it staying quiet until the very end of the sprint.
2. Reassess what's actually achievable in the sprint's remaining time and capacity, and be honest that something else in scope may now need to be descoped, not just "worked harder" to compensate.
3. Re-estimate the story properly once it's better understood, and note the reason for the miss (hidden complexity? unclear requirements? unfamiliar code?) since that's useful signal for improving refinement next time.
4. Resist the urge to silently absorb the overrun through unpaid extra hours — that hides the real signal and sets a bad precedent.

The root causes and trade-offs.

Sometimes it's genuinely hidden complexity that nobody could reasonably have known about at refinement time, and in that case nobody is at fault, you just re-plan. Other times it's a refinement session that rushed through sizing without enough real discussion, which is a process gap worth naming in the retrospective. Both are common, and the fix depends on telling them apart honestly.

The trap that less-experienced engineers fall into.

Staying quiet and just working longer hours to try to still hit the original estimate — which hides a genuine signal from the team, corrupts the sprint's data, and isn't sustainable if it happens repeatedly.

🎯 Interviewer follow-up questions you should expect.

• "A story is running way over its estimate — what do you do?" You surface it immediately, reassess the sprint's remaining scope honestly, and re-estimate once it's understood — you don't just silently work longer.
• "Whose fault is a bad estimate?" Usually nobody's — it's new information, and the useful question is whether it was genuinely unknowable or a rushed refinement.

At the mid-sprint check, it's clear the sprint goal — not just one ticket — is genuinely unlikely to be met.

What is actually happening (the mental model).

The mid-sprint review exists precisely to catch this while there's still time to act — a sprint goal in danger is a different, more serious category of problem than a single slipping ticket, because it means the thing stakeholders were told to expect this sprint may not land, and that needs an active decision, not a wait-and-see.

How to work through it.

1. Identify precisely what's driving the risk — one blocked story, a cluster of underestimates, an unplanned absence — rather than a vague "we're behind."
2. Decide deliberately: can the team re-focus remaining capacity onto just the goal-critical work, deprioritising nice-to-haves in the sprint even if they were already started?
3. If the goal genuinely can't be met, communicate that early and clearly to stakeholders — a goal missed with two days' warning is a very different conversation than one that surfaces as a surprise at the sprint review.
4. Bring the "why" into the retrospective afterward as real input, not just an excuse — was this a planning miss, a capacity miss, or truly unforeseeable?

The root causes and trade-offs.

This can come from overcommitted capacity at planning time, from a cluster of underestimates compounding on top of each other, or from a genuine unplanned event like an outage pulling people away. The trade-off in refocusing onto the goal is that some in-progress, non-critical work gets shelved, which is a real cost, but usually a smaller one than the cost of a silent miss.

The trap that less-experienced engineers fall into.

Treating the mid-sprint check as a status update rather than a decision point — noting "we're a bit behind" without actually deciding whether to refocus effort or communicate the risk, and then being surprised when the goal is missed at the very end.

🎯 Interviewer follow-up questions you should expect.

• "The sprint goal looks at risk halfway through — what do you do?" You identify exactly what's driving it, then deliberately decide whether to refocus capacity onto goal-critical work and communicate early if it still won't land.
• "Why does this deserve more urgency than one slipping story?" Because it's what stakeholders were told to expect this sprint — the mid-sprint check exists specifically to catch this while there's still time to act.

A story that looked self-contained at refinement turns out, once work starts, to need something from another team that wasn't planned for.

What is actually happening (the mental model).

A dependency you don't control is fundamentally different risk than work your own team controls — your own team's velocity and priorities don't apply to it, so treating it like an ordinary in-sprint task (just "work harder") ignores that its timeline is now genuinely outside your control.

How to work through it.

1. Contact the other team immediately, not at the point you actually need their output — the earlier they know, the more likely they can accommodate it inside their own planning.
2. Treat the ask as an explicit, tracked cross-team dependency (many JIRA setups support linking issues across projects for exactly this) rather than an informal side conversation that's easy to lose track of.
3. Plan the affected story around the dependency's realistic timeline — if the other team can't turn it around this sprint, that's the same "does this threaten the goal" decision as any other risk, and may mean descoping or deprioritising this story now rather than leaving it half-blocked.
4. Flag this pattern in retrospective if it keeps recurring — repeated hidden cross-team dependencies are usually a sign refinement needs a step that explicitly checks for them.

The root causes and trade-offs.

The root cause is usually that refinement never explicitly asked whether this work touches anything outside the team before it was sized, though sometimes the dependency really was impossible to foresee. The trade-off in raising it immediately versus waiting is almost entirely one-sided — earlier is always better for a dependency outside your control.

The trap that less-experienced engineers fall into.

Waiting until the point the dependency is actually blocking, then raising it — losing days of lead time the other team could have used, and turning a manageable dependency into a sprint-goal-level crisis.

🎯 Interviewer follow-up questions you should expect.

• "A story needs something from another team you didn't plan for — what do you do?" You contact them immediately, track it as an explicit cross-team dependency, and plan around their realistic timeline rather than your own velocity.
• "How do you prevent this happening repeatedly?" You add an explicit "does this touch another team" check to refinement.

Someone's mentioned the same blocker at stand-up for four days straight, and it's still not resolved.

What is actually happening (the mental model).

Stand-up is designed to surface blockers quickly, but surfacing is not the same as resolving — if a blocker is repeated day after day with no visible movement, the process that's supposed to remove blockers (usually the scrum master's actual job) has itself stalled, and repeating it at stand-up without escalating just becomes ambient noise everyone tunes out.

How to work through it.

1. Recognise a blocker mentioned more than once or twice as needing escalation outside stand-up itself — stand-up surfaces it, it doesn't have to be where it gets solved.
2. Identify specifically who actually has the power to unblock it (a decision-maker on another team, an access request stuck in a queue, an external vendor) and go directly to them rather than continuing to just mention it in the daily meeting.
3. If it's the scrum master's role to chase this and it isn't happening, that's itself worth a direct, calm conversation — the ceremony only works if someone actually owns follow-through between meetings.
4. Consider whether the blocked work should be swapped out for something else in the meantime, so at least forward progress continues elsewhere while the blocker is chased down.

The root causes and trade-offs.

Sometimes the blocker genuinely requires someone outside the team's control to act, and that needs direct escalation rather than repetition at stand-up. Other times it's the scrum master or team lead not actually following up between stand-ups, which is a process gap rather than a people problem to quietly blame. Swapping in other work keeps momentum going, but it does risk losing the blocked item's context if it drags on too long.

The trap that less-experienced engineers fall into.

Treating "I mentioned it at stand-up" as equivalent to "I'm actively working to resolve it" — repeating the same blocker daily without ever escalating it to the specific person who can actually unblock it.

🎯 Interviewer follow-up questions you should expect.

• "A blocker keeps coming up at stand-up with no progress — what do you do?" You escalate directly to whoever can actually unblock it, rather than continuing to just mention it daily.
• "Whose job is it to chase blockers?" Typically the scrum master's, and if that isn't happening, that gap itself needs a direct conversation.

One sprint the team delivers 45 points, the next only 18, with no obvious external cause — making capacity planning nearly useless.

What is actually happening (the mental model).

Velocity is only a useful planning input if story-point sizing is relatively consistent across sprints and across the people doing the sizing — wild swings usually mean the underlying estimates themselves are inconsistent (different people sizing very differently, or sizing drifting over time), not that the team's actual working capacity is genuinely this volatile.

How to work through it.

1. Look at what actually made up each sprint's points — is the variance concentrated in a few unusually large or small stories, or spread evenly?
2. Check whether sizing is consistent across the people doing it — a common cause is different team members anchoring to very different ideas of what a "5" means, especially on a team that hasn't calibrated together.
3. Look for external factors that genuinely do vary (holidays, on-call rotations pulling people away, a major incident) before assuming it's purely an estimation problem.
4. If it is inconsistent sizing, run a calibration exercise — sizing a few historical stories together as a group — to re-align what the numbers mean before trusting velocity as a planning input again.

The root causes and trade-offs.

Sometimes this comes from inconsistent sizing across people or over time, which is fixable with a calibration exercise. Sometimes it's genuine variability in capacity from absences or incidents, which is a real signal rather than an estimation bug. And sometimes it's a small number of outlier stories dominating the total, which is worth addressing by capping or splitting very large stories. Each of these has a different, specific fix — the mistake is treating all velocity variance as the same problem.

The trap that less-experienced engineers fall into.

Reacting to volatile velocity by abandoning story points altogether ("estimation doesn't work here") instead of diagnosing whether the volatility is a sizing-consistency problem, which calibration actually fixes.

🎯 Interviewer follow-up questions you should expect.

• "Velocity swings a lot between sprints — what do you investigate?" You investigate whether sizing is consistent across people and time, genuine capacity variance from absences or incidents, or a few outlier stories dominating the total.
• "How do you fix inconsistent story-point sizing?" You run a calibration exercise, sizing historical stories together as a group to re-align on what the numbers mean.

A manager starts comparing individual engineers' "points completed per sprint" in performance reviews.

What is actually happening (the mental model).

Story points are a team-level planning tool, calibrated loosely and specifically not meant to be comparable across individuals or even across teams — using them as an individual performance metric misunderstands what they measure and creates a strong, corrosive incentive to inflate estimates, which quietly destroys the very thing that made velocity useful for planning in the first place.

How to reason about it.

1. Name the mechanism directly: once points affect an individual's perceived performance, everyone is incentivised to size generously, and velocity as a planning number stops meaning what it used to.
2. Distinguish what story points are actually good for (team-level sprint planning, capacity forecasting) from what they are not (individual output measurement, cross-team comparison) and make that distinction explicit to whoever introduced the misuse.
3. If individual contribution genuinely needs to be assessed, that's a separate, qualitative conversation — code quality, mentorship, ownership, collaboration — not a proxy derived from a number designed for a completely different purpose.

The root causes and trade-offs.

This usually comes from a well-meaning manager reaching for the only quantitative number visible in JIRA, without understanding what it was actually designed to measure. The real cost is a slow, hard-to-detect inflation of every future estimate, once people realise that the points affect them personally.

The trap that less-experienced engineers fall into.

Going along with it quietly (or worse, gaming their own estimates upward once they notice it's being tracked) instead of directly naming why story points are the wrong tool for this and risk corrupting the whole team's planning data.

🎯 Interviewer follow-up questions you should expect.

• "A manager wants to use story points for individual performance reviews — what's your concern?" It creates an incentive to inflate estimates, which corrupts velocity as a planning tool for everyone.
• "How do you push back on this constructively?" You name the mechanism directly, distinguish what points are for versus what they're not for, and offer that individual contribution needs a separate, qualitative conversation.

Stand-up, meant to be 15 minutes, now regularly runs 40, because every blocker turns into a full group discussion about how to fix it.

What is actually happening (the mental model).

Stand-up has exactly one job — surface status and blockers fast — and it fails at that one job the moment it also tries to be the place blockers get solved, because solving something properly needs the specific people involved, not the whole team standing around while two people debug out loud.

How to reason about it.

1. Reintroduce the discipline explicitly: stand-up surfaces a blocker in one sentence; anything needing real discussion gets a "let's take this offline" and a follow-up conversation with just the relevant people, immediately after.
2. This isn't about suppressing problem-solving — it's about not making the whole team sit through a two-person debugging session that only needs two people.
3. If this keeps recurring, it's worth naming explicitly in a retrospective as a process issue, since it usually means the habit has crept in gradually and needs a deliberate reset, not just one person trying to enforce it unilaterally in the moment.

The root causes and trade-offs.

This usually comes from a well-intentioned instinct to solve problems the moment they're raised, without noticing the cost that imposes on everyone else's time, combined with nobody in the room being willing to be the one who says "let's take this offline." The fix costs a little social awkwardness in the moment, in exchange for a real time saving for the rest of the team, every single day.

The trap that less-experienced engineers fall into.

Letting stand-up creep into a design meeting because redirecting it feels rude or disruptive in the moment — until it's normalised as a 40-minute meeting and nobody remembers it was ever supposed to be 15.

🎯 Interviewer follow-up questions you should expect.

• "Stand-up keeps running long because of deep discussions — what do you do?" You redirect anything needing real discussion to "let's take this offline" with just the relevant people, immediately after.
• "Isn't that suppressing useful problem-solving?" No — it's not solving it in front of everyone who doesn't need to be there; the discussion still happens, just with the right smaller group.

Every retrospective produces a list of things to improve — and the same items reappear, unaddressed, sprint after sprint.

What is actually happening (the mental model).

A retrospective that only identifies problems without any mechanism to actually act on them is just a recurring complaint session — the value of the ceremony is entirely in the follow-through, and a list of good intentions with no owner and no tracking is indistinguishable, in outcome, from not holding the retro at all.

How to reason about it.

1. Treat retro action items exactly like any other piece of committed work — give each one a named owner and, ideally, an actual ticket, rather than leaving them as bullet points in a meeting note nobody revisits.
2. Limit the list to a small number of items per retro (one to three) rather than a long wish list — a long list with no prioritisation is a strong predictor that nothing on it happens.
3. Open the next retrospective by explicitly reviewing whether last time's action items actually happened, before generating a new list — this single habit is usually what turns a retro from performative into effective.

The root causes and trade-offs.

This usually comes from having no named owner or tracking mechanism for action items at all, combined with generating too many items with no prioritisation, so that everything ends up getting equal — which in practice means no — attention. Limiting the list to a small number does cost addressing everything at once, but it massively increases the odds that what does get picked actually happens.

The trap that less-experienced engineers fall into.

Generating a fresh, well-meaning list every retro without ever revisiting whether the previous list happened — which normalises the retro as a venting session rather than an actual improvement mechanism.

🎯 Interviewer follow-up questions you should expect.

• "Retro action items never get done — how do you fix that?" You give each item a named owner and a real ticket, limit the list to a small number per retro, and open the next retro by reviewing whether they actually happened.
• "How many action items should come out of a retro?" A small number, one to three — a long unprioritised list is a predictor that nothing on it gets done.

The backlog has grown to hundreds of issues, many years old, and nobody's confident anything in it is still accurate or relevant.

What is actually happening (the mental model).

A backlog is supposed to be a living, prioritised list feeding refinement — once it becomes an unmanaged archive of every idea anyone ever had, it stops serving that purpose, and refinement sessions waste time re-discovering that old items are stale rather than actually preparing near-term work.

How to reason about it.

1. Separate "old" from "irrelevant" — some old items may still matter, but the backlog's size alone makes it impossible to tell which, which is itself the core problem to fix.
2. Run a deliberate backlog-grooming pass: close out items that are genuinely stale (a rule of thumb like "untouched for over a year and no longer aligned with current priorities" is a reasonable, honest filter), rather than letting everything accumulate indefinitely.
3. Going forward, cap how far out the "actively maintained" portion of the backlog reasonably extends — a backlog that only needs to stay accurate for the next one or two quarters of realistic work is far easier to keep honest than one trying to represent everything forever.
4. Make backlog health itself a periodic check (not just a one-time clean-up), since the same growth will otherwise just recur.

The root causes and trade-offs.

This usually comes from nobody owning backlog hygiene as an explicit responsibility, combined with a natural reluctance to close old tickets that feels like "losing" an idea. Closing stale items does risk occasionally closing something that still mattered, but that's mitigated by writing good closing notes and keeping the ability to reopen, which is a much smaller cost than an unusable backlog.

The trap that less-experienced engineers fall into.

Treating backlog grooming as a one-time clean-up project rather than an ongoing responsibility — leading to the exact same unmanageable pile reappearing a year or two later.

🎯 Interviewer follow-up questions you should expect.

• "The backlog has hundreds of stale issues — how do you fix it?" You run a deliberate grooming pass, closing genuinely stale items with a clear, honest rule, and treat backlog health as an ongoing responsibility, not a one-off clean-up.
• "Aren't you worried about losing good ideas by closing old tickets?" Good closing notes and the ability to reopen mitigate that risk far more cheaply than keeping an unusable backlog around just in case.

The board says a story is "In Progress," but the engineer finished it two days ago and just forgot to move the card.

What is actually happening (the mental model).

Every downstream number — velocity, burndown, sprint reports — is only as honest as the raw ticket data feeding it; if updating JIRA is treated as an afterthought rather than part of actually finishing work, all of those derived numbers quietly become fiction, which nobody notices until a decision gets made based on a burndown chart that was never accurate.

How to work through it.

1. Treat "update the ticket status" as literally part of the definition of done for a piece of work, not a separate administrative chore that happens whenever someone remembers.
2. If stale ticket status is a recurring pattern rather than a one-off, that's worth naming directly — not to police individuals, but because it's actively corrupting the sprint and velocity data everyone else relies on for planning.
3. Consider whether the tooling itself is part of the problem — if updating a ticket takes real friction (too many required fields, a clunky transition flow), that's worth fixing rather than just asking people to try harder.

The root causes and trade-offs.

Sometimes ticket updates are treated as separate from actually finishing the work. Sometimes the tooling itself has enough friction that it discourages quick updates. And sometimes it really is just an oversight. All three point to different fixes — a process norm, a tooling fix, or simply a reminder — so it's worth being specific about which one is actually happening before reacting.

The trap that less-experienced engineers fall into.

Treating a stale ticket as a minor, harmless annoyance, rather than recognising that every velocity number, burndown chart, and sprint report downstream is silently built on exactly this kind of small inaccuracy, multiplied across a whole team.

🎯 Interviewer follow-up questions you should expect.

• "JIRA status doesn't match what's actually done — why does this matter?" Because every derived metric — velocity, burndown, reports — is only as accurate as the raw ticket data feeding it.
• "How do you get a team to keep tickets accurate?" You make updating status part of the definition of done, and check whether the tooling itself is adding friction that discourages it.

A director asks for "a status update on the project" — what do you actually put in front of them?

What is actually happening (the mental model).

Leadership reporting fails most often not from missing information but from the wrong level of detail — a director doesn't want the full ticket list or the daily stand-up notes, and a team lead reporting a raw velocity number with no context is answering a question nobody actually asked; good upward reporting translates ceremony-level detail into decision-relevant signal.

The shape of a good update.

1. Status against the goal, not the tickets — "on track for the committed scope this quarter" or "at risk, here's why," not a list of forty JIRA IDs.
2. Risks and blockers that need their help — specifically the things only someone at their level can unblock (budget, a cross-org dependency, a prioritisation call) — not every in-team blocker that's already being handled.
3. Trend, not just a snapshot — velocity or delivery trending steady, improving, or declining tells a leader far more than one sprint's raw number in isolation.
4. What decision, if any, you need from them — a good update often ends with a specific ask, not just information, since that's usually the actual reason the update is being requested.

The trap that less-experienced engineers fall into.

Reporting raw JIRA data — ticket counts, a velocity number with no trend or context, a list of every blocker regardless of who could act on it — mistaking "comprehensive" for "useful," when a leader's actual job is making decisions that need a much more distilled signal.

🎯 Interviewer follow-up questions you should expect.

• "A director asks for a status update — what do you tell them?" You give them status against the goal, any risks that need their level of help, the trend rather than just a snapshot, and what decision, if any, you need from them.
• "What's the difference between reporting to a director versus your own team?" Your team needs ticket-level detail to do the work; a director needs a distilled signal to make a decision — mixing the two levels up is the most common reporting mistake.