Agile & Scrum Practices for Senior Engineers — Interview Questions

How to use this lesson

Interviewers don't want the Scrum Guide recited. They want to see that you use the ceremonies to deliver outcomes:

• predictable delivery;
• early detection of risk;
• continuous improvement.

Mention the anti-patterns you've fixed, and the metrics that improved.

Q1. How do you run effective standups?

Short answer:

• 15 minutes maximum, at the same time each day. Focus on the sprint goal and the flow of work, not a status report to a manager.
• Walk the board right to left: start with the items closest to done ("what do we need to finish this?"), then the blocked items, then new work.
• Surface blockers, and take detailed problem-solving offline ("let's stay after with the two people involved").
• Rotate the facilitator; keep it visible (the board shared on screen for remote teams).
• Asynchronous standups (a written thread) can work for distributed teams across time zones, with a short sync a few times a week.
• Anti-patterns to fix: people reporting to the lead, long technical debates, and "yesterday I worked on stuff".

Q2. What's your role in sprint planning as a senior developer?

Short answer:

• Before planning: make sure the top stories are ready (clear acceptance criteria, dependencies known, designs agreed). Raise technical risks, and split large stories into thin vertical slices.
• During planning:
  • help shape a realistic sprint goal;
  • bring the technical view: dependencies, risks, sequencing, and needed spikes;
  • make sure the plan includes technical debt, operational work and on-call capacity;
  • check the commitment against the actual capacity (holidays, on-call);
  • make sure juniors understand the stories and can pick them up.
• Challenge over-commitment: a plan that's always missed teaches everyone to ignore plans.

Learn it in depth → Facilitating Sprint Planning

Q3. How do you handle scope creep inside a sprint?

Short answer:

• Protect the sprint goal. New requests go to the product owner, who decides whether they are worth disrupting the sprint.
• If it's genuinely urgent, swap it: take out work of similar size, explicitly and visibly.
• If a story itself grows (the "while we're at it" additions), split the extra into a new story for the backlog.
• Track the unplanned work, and discuss it in the retro. If it's regular, reserve capacity for it.

Q4. What do you do when a task carries over across several sprints?

Short answer: Treat it as a signal, not something normal.

1. Find the cause: was it too big, unclear, blocked by a dependency, lacking skills, or deprioritised repeatedly?
2. Split it into smaller, independently deliverable slices, and ship what's done.
3. Re-estimate the remaining work honestly; make the blocker visible, and escalate it.
4. Swarm on it, or pair, if it's a skills or complexity issue.
5. Discuss the pattern in the retro (for example, a rule of thumb: nothing bigger than about 3 days enters a sprint unsplit).

Q5. How do you prioritise technical debt during planning? How do you balance new features against bug fixes?

Short answer:

• Make debt visible: a tech-debt backlog, with each item's impact (incidents, slowdown, risk) and cost, in business terms.
• Reserve capacity (for example 15–20% each sprint) agreed with the product owner, instead of negotiating every item. Or run periodic "hardening" work for larger items.
• Pay debt down where you're working (the boy scout rule), and attach necessary refactoring to the feature that needs it.
• Bugs: triage by severity and customer impact. Critical bugs interrupt the sprint; the rest are prioritised in the backlog like any other work. Watch the bug trend: a growing backlog of bugs is a quality signal, and needs root-cause work (tests, reviews), not just more fixing.
• Agree on a policy with product (for example, "zero known critical or high bugs; medium ones fixed within 2 sprints").

Q6. How do you facilitate a sprint retrospective? Give an example of a major improvement that came from a retro.

Short answer:

• Safe environment: blameless, and the focus is on systems. Vary the format (start/stop/continue, mad/sad/glad, a sailboat, a timeline of the sprint) to keep it fresh.
• Use data: velocity, cycle time, carry-over, incidents, unplanned work.
• Converge: vote on the 1 or 2 most important issues, find their root causes, and agree on specific actions with owners.
• Follow up on the previous retro's actions first. A retro without follow-through loses credibility quickly.
• Encourage quieter voices (silent writing before discussion, anonymous input).

An example of an improvement: "The retros kept flagging 'waiting on reviews'. We agreed on small PRs, a 4-hour review SLA and a daily review slot. The average PR cycle time fell from 2.5 days to under 1 day, and carry-over dropped by half."

Q7. How do you estimate effort during planning? What's your approach to story-point estimation?

Short answer:

• Story points measure relative size: complexity, effort and uncertainty compared with reference stories, not hours. Use a Fibonacci-like scale (1, 2, 3, 5, 8, 13); anything above 8 or 13 should be split.
• Planning poker: everyone estimates independently, then discusses the outliers (they often reveal hidden work or a better solution).
• Keep reference stories for calibration.
• Include everything: tests, reviews, deployment, and documentation.
• Spikes for large unknowns, time-boxed, then estimate afterwards.
• Points aren't a performance metric. Never compare velocity between teams, and never use it to evaluate individuals.
• Alternatives: some teams use no estimates (#NoEstimates) with counting stories of similar size and cycle-time forecasting. It works well when stories are consistently small.

Q8. How do you work with product owners to refine the backlog?

Short answer:

• Regular refinement sessions (for example, 1 hour a week), looking 1–2 sprints ahead.
• The PO brings the why and the what (user problem, value, acceptance criteria); engineering brings the how, options, feasibility, risks and estimates, and suggests cheaper alternatives that meet the goal.
• Split stories into vertical slices, and write clear, testable acceptance criteria (Given/When/Then helps).
• Agree a definition of ready.
• Make sure the technical work (debt, upgrades, observability) is in the same backlog, prioritised with the PO.
• Involve QA and design early.

Q9. How do you handle urgent production bugs during a sprint?

Short answer:

• Triage quickly by severity (the customer and business impact). Critical ones interrupt: fix, or mitigate (rollback, a feature-flag kill switch), then follow up.
• A rotating "shield" or on-call person absorbs interruptions, so the rest of the team stays focused.
• Reserve capacity for unplanned work, based on history (for example 10–20%).
• Make the impact visible: add the bug to the sprint board; if it's large, remove equivalent planned work, together with the PO.
• Afterwards: a postmortem for serious incidents, with preventive actions in the backlog. Track the trend of unplanned work.

Q10. How do you manage several sprint teams working on the same repository?

Short answer:

• Clear ownership: CODEOWNERS per module; a modular structure (a modular monolith, or clear package boundaries enforced with ArchUnit).
• Trunk-based development, with short-lived branches and feature flags, which avoids long-lived branches and painful merges.
• Fast, reliable CI, with a green main branch as a shared responsibility; merge queues if needed.
• Shared conventions (coding standards, a PR template, commit conventions).
• Coordination: a Scrum-of-Scrums or a cross-team sync for shared areas; announce breaking changes; contract tests at module boundaries.
• Consider splitting the repository or module if the coupling hurts too much.

Q11. How do you bring value to a sprint review or demo?

Short answer:

• Demonstrate working software from the user's point of view, tied to the sprint goal and business outcome, not a list of tickets closed.
• Show the data where you can (performance improvement, metrics from a feature in production).
• Invite real stakeholders, and collect feedback that updates the backlog.
• Be honest about what wasn't done, and why.
• Make the technical work visible too (for example "deploys are now 3× faster").
• Let the engineers who built it present it. It builds ownership and recognition.

Q12. How do you identify blockers early in the sprint?

Short answer:

• Refinement: find the dependencies and unknowns before the sprint (definition of ready).
• Start the risky and dependent items first; request anything needed from other teams on day 1.
• Watch the board: items that don't move for a day or two (aging work in progress); many items in progress at once.
• Standups focused on flow, and "what's blocking you?" asked explicitly.
• Integrate early: end-to-end skeletons, and contract tests against dependencies.
• Make it safe to raise problems early, and escalate them fast.

Q13. How do you make sure QA is fully engaged in the sprint?

Short answer:

• Involve QA from refinement: they help write the acceptance criteria, and spot edge cases early (three amigos: product, development, QA).
• Quality is the whole team's job: developers write unit and integration tests; QA focuses on test strategy, exploratory testing and automation frameworks.
• Test continuously during the sprint, not in a final "testing phase". Stories flow to done individually; no mini-waterfall at the end.
• Automate the regression tests in CI, and have QA and developers pair on automation.
• The definition of done includes the tests passing and the acceptance criteria verified.

Q14. How do you track sprint velocity and use it for planning? How do you handle inconsistent team performance across sprints?

Short answer:

• Velocity is the points completed (fully done) per sprint. Use a rolling average of the last 3–5 sprints as a planning guide, adjusted for capacity (holidays, on-call, new joiners).
• It's a planning tool, not a target. Pressure to increase velocity leads to point inflation.
• Complementary metrics: cycle time, throughput, carry-over, unplanned work, escaped defects.
• For inconsistent performance:
  • look at the causes with data: unplanned work, stories that were too large, dependencies, changing priorities, capacity changes, poor refinement;
  • address them in the retro: better slicing, reserved capacity, a definition of ready, WIP limits;
  • if it's individual, handle it privately in 1:1s.
• Aim for predictability (committed vs done), not maximum speed.

Q15. How do you manage dependencies between scrum teams?

Short answer:

• Identify them early: in quarterly or PI planning, or dependency mapping in refinement; a visible dependency board.
• Reduce them structurally: align teams to business domains (stream-aligned teams), with clear API contracts; self-service platforms instead of ticket-based requests.
• Decouple the delivery: agree on API contracts first (OpenAPI, consumer-driven contract tests), use mocks and stubs so both teams can work in parallel, and use feature flags to release independently.
• Coordinate: a Scrum-of-Scrums, named owners on both sides, and dates agreed and tracked.
• Escalate early when a dependency is at risk.

Q16. What do you do when the business constantly changes sprint priorities?

Short answer:

1. Make the cost visible: the work thrown away or carried over, the context-switching, velocity, and morale. Show the data to the PO and stakeholders.
2. Find the root cause: unclear strategy, no single PO decision-maker, or a genuinely volatile market.
3. Adjust the process: shorter sprints (1 week), or Kanban with WIP limits if priorities really change daily; a clear intake rule (changes go through the PO, who swaps them explicitly); a protected sprint goal.
4. Improve upstream: a clearer roadmap, and better refinement.
5. Keep work small so changes cost less.

Follow-up questions this topic invites — and their answers

Q: Scrum or Kanban — when would you choose each? A: Scrum suits teams working on planned product increments, who benefit from a fixed cadence of planning, review and retro. Kanban suits flow-based work with unpredictable arrivals (platform, support, operations), using WIP limits and cycle-time metrics. Many teams use a hybrid.

Q: What's the difference between the definition of ready and the definition of done? A: Ready is the entry criteria for a story before a sprint (clear, estimated, dependencies resolved). Done is the exit criteria (code reviewed, tested, merged, deployed or deployable, documented, acceptance criteria met).

Q: What are the DORA metrics? A: Deployment frequency, lead time for changes, change failure rate, and time to restore service. Together they measure delivery speed and stability, and are more meaningful than velocity for comparing improvement over time.

Q: Why shouldn't velocity be compared between teams? A: Story points are relative within each team's own calibration. Comparing them encourages inflation, and says nothing about the value delivered.