Agile & Scrum Interview Questions and Answers

Scrum has five events, each with a clear purpose.

The Sprint is the container, a fixed period, usually two to four weeks, in which a usable increment is created.

Sprint Planning opens it. The team agrees a Sprint Goal and selects backlog items it can deliver.

The Daily Scrum is a fifteen minute event for the developers to inspect progress toward the Sprint Goal and adapt the plan. It is not a status report to a manager.

Sprint Review closes the sprint by inspecting the increment with stakeholders and gathering feedback for the backlog.

Sprint Retrospective follows, where the team reflects on how it worked and identifies one or two improvements to commit to.

Between events, backlog refinement keeps upcoming items understood and estimated. The events exist to create transparency and inspection, not to fill the calendar.

Story points estimate relative size, not time. They combine effort, complexity and uncertainty compared with other backlog items.

I use planning poker. The team discusses each item, asks clarifying questions, and simultaneously reveals a card from a sequence such as Fibonacci. Disagreement is useful because it surfaces hidden assumptions, so I ask the highest and lowest estimators to explain their thinking. We re vote until we converge, without forcing false consensus.

I anchor estimates with a reference story the team agreed on. A three point story is roughly three times the size of a one point story, but that says nothing about hours.

Points are for the team's own forecasting, not for comparing teams or measuring individual productivity. Velocity is a rough guide for how much to take into a sprint, and it should never be used as a performance target.

I surface it early rather than hoping. Transparency is more valuable than protecting appearances, and late surprises are worse than early honesty.

First I look at why. Is scope larger than estimated, did an unexpected defect or incident absorb capacity, did someone leave, or was there a dependency we did not control? The cause determines the response.

In the Daily Scrum I raise the risk and propose options: reduce scope to the most valuable items that still meet the Sprint Goal, or renegotiate the Sprint Goal with the Product Owner if the goal itself is no longer achievable. I never quietly carry unfinished work as if it were done.

After the sprint I bring it to the retrospective and look for a systemic fix: better refinement, smaller stories, more buffer, or addressing the dependency. Repeated misses usually point to a process problem, not lazy work.

A good retrospective is safe, focused and produces a small number of owned actions.

I set the stage and remind everyone of the prime directive: we assume good intent and focus on the system, not individuals. I choose a format that fits the mood, such as start stop continue, what went well and what did not, or a data driven review of the sprint board and metrics.

I gather input individually or in writing first, so quieter people contribute and louder voices do not anchor the discussion. Then we group themes and vote on the ones that matter most.

We discuss the top one or two in depth and agree concrete actions with an owner and a date. I limit the number so they actually happen.

I record actions where everyone can see them and review them at the start of the next retrospective. A retrospective without follow through quickly becomes theatre.

I start from curiosity, not accusation. Silence usually has a cause: they may feel the ceremonies are pointless, be overloaded, lack psychological safety, or simply prefer written communication.

I would speak to them privately and ask what would make the meetings useful for them. Often the answer reveals a team level problem rather than a personal one.

Then I address the cause. If the Daily Scrum feels like a status report, I refocus it on the Sprint Goal and make it a conversation among developers. If a few people dominate, I use structured formats or written input first. If they are overloaded, we look at workload with the Product Owner.

I also make participation expectations clear and give them a meaningful role, such as owning refinement for a feature.

Persistent disengagement after that is a performance conversation, but that is the last step, not the first.