Top 10 project manager and scrum master interview questions

Waterfall is sequential: requirements → design → build → test → deploy, each phase finishing before the next. It needs stable requirements, gives predictable plans and documentation, but changes are expensive and users see the product late.

Agile is iterative: work is delivered in short cycles (sprints) as working increments, with continuous feedback and reprioritisation. It handles changing requirements and reduces the risk of building the wrong thing, but needs engaged stakeholders and makes long-term fixed-scope commitments harder.

Choose based on uncertainty and cost of change: construction or regulatory compliance projects lean waterfall; software and digital products lean agile; many organisations use a hybrid.

• Roles: the product owner (maximises value, owns the backlog order), the scrum master (coaches Scrum, removes impediments, facilitates), and developers (build the increment).
• Events: the sprint (a fixed timebox, usually 2 weeks) containing sprint planning, the daily scrum, the sprint review and the retrospective; plus ongoing backlog refinement.
• Artefacts: product backlog (with a product goal), sprint backlog (with a sprint goal) and the increment (meeting the definition of done).

The empirical pillars are transparency, inspection and adaptation, and the values are commitment, focus, openness, respect and courage.

1. Diagnose: how far behind, on which tasks, and why (underestimation, blockers, scope growth, resource issues)? Check the critical path.
2. Assess impact on milestones, budget and dependencies.

3. Options:

   • Re-prioritise and cut or defer lower-value scope (often the best lever).
   • Fast-track: do tasks in parallel where it's safe.
   • Crash: add resources to critical-path tasks (only helps if people can ramp up quickly).
   • Remove blockers and reduce context switching for the team.
   • Negotiate a revised deadline if needed.
4. Communicate early and honestly with stakeholders: status, cause, options and a recommendation.
5. Prevent recurrence: better estimates, buffers and earlier risk tracking.

Prevent it: define scope, deliverables and acceptance criteria clearly at the start, with sign-off, and set up a change control process.

When a new request comes: acknowledge it, capture it, assess its impact on timeline, cost, quality and risk with the team, and present options to the sponsor or product owner: add it with more time/budget, swap it for something of similar size, or defer it to a later phase. Document the decision. In agile, new requests go into the product backlog to be prioritised rather than into the current sprint.

I run a risk identification session at the start (with the team and stakeholders, reviewing assumptions, dependencies and lessons from past projects) and keep a risk register: description, probability, impact, score, owner, response plan and triggers.

Responses: avoid, mitigate, transfer or accept, with contingency plans for major risks. I review the register in regular meetings and status reports, and update it as things change.

Example: "In a CRM rollout, data migration was high-risk. We mitigated it with a trial migration two weeks early, which found 12% of records with bad phone formats that we cleaned before go-live."

"I first understand each stakeholder's goals and concerns individually. Then I bring them together with the facts: project objectives, constraints, and the impact of each option on cost, schedule and value. I use objective criteria (business value, deadlines, regulatory needs) to frame the trade-off, and when they can't agree, I escalate to the sponsor with a clear recommendation and let the accountable person decide. I document decisions and communicate them to everyone, so the project doesn't keep reopening the same debate."

• Break work down with a WBS until tasks are small enough to estimate reliably.
• Involve the people doing the work.
• Use techniques suited to the context: analogous estimates from past projects, three-point/PERT for uncertainty ((O + 4M + P) ÷ 6), bottom-up for detailed plans, story points and planning poker with velocity in agile.
• Include dependencies and identify the critical path.
• Add contingency for risks, and communicate estimates as ranges with assumptions.
• Track actuals against estimates to get better over time.

• Schedule: milestone completion, SPI (earned value ÷ planned value), burndown/burnup charts, cycle time.
• Cost: budget vs actual, CPI (earned value ÷ actual cost), forecast at completion.
• Scope: number and impact of change requests, scope growth.
• Quality: defects found and escaped, test pass rates, rework.
• Risks and issues: open high risks and ageing issues.
• Team and stakeholders: velocity stability, team morale, stakeholder satisfaction.

I summarise these in a RAG status report with honest explanations and the decisions needed.

"I start with a private, supportive conversation to understand the cause: unclear expectations, skill gaps, workload, personal issues or motivation. I give specific examples, agree on clear expectations and a plan (training, pairing with a senior, adjusted tasks, more frequent check-ins), and follow up regularly with feedback. I recognise improvement. If performance doesn't improve despite support, I involve their line manager or HR and follow the formal process. Throughout, I protect the project by adjusting plans if needed."

Use STAR with project specifics:

• Situation: "As placement coordinator, I managed our college's first virtual placement week for 600 students and 25 companies, with 6 weeks to prepare."
• Task: "Deliver interviews for all shortlisted students with no scheduling clashes."
• Action: "I broke the work into a WBS (company onboarding, student registration, test platform, interview scheduling, tech support), assigned owners from a 10-person team, ran weekly status meetings with a RAG tracker, and maintained a risk register. The biggest risk was internet failures; we mitigated it with backup slots and a helpdesk."
• Result: "We completed 1,140 interviews in 5 days; 212 offers were made, 30% more than the previous year's in-person drive. I documented lessons learned, which became the template for later drives."