Agile Delivery interview questions: roadmap and stakeholder management
Reviewed by Mark Dickie · Last updated
6 questions on this page you can answer and see marked on the spot. Go to the first one
Agile delivery roadmaps are time-boxed plans that communicate what a team intends to build and why, without locking every detail into a fixed schedule. For an interview focused on roadmap and stakeholder management, you should know how to build a roadmap that balances business goals with delivery uncertainty, how to prioritise work using frameworks like WSJF or MoSCoW, and how to keep stakeholders informed without turning the roadmap into a rigid commitment. Expect questions about handling competing priorities, managing expectations when timelines shift, and proving value delivery through measurable outcomes.
The core skills an interviewer probes in this area break down as follows:
| Skill area | What gets tested | Common question shape |
|---|---|---|
| Roadmap construction | Can you distinguish a release plan from a product roadmap and explain when to use each? | "Walk me through how you would build a 6-month roadmap for a new product." |
| Prioritisation | Do you understand WSJF, MoSCoW, or RICE and can you defend trade-off decisions? | "Two stakeholders want their feature shipped first. How do you decide?" |
| Stakeholder communication | Can you keep sponsors aligned when scope or dates change mid-quarter? | "A key stakeholder disagrees with the roadmap. How do you handle it?" |
| Value measurement | Can you tie roadmap items to OKRs or other outcome metrics? | "How do you know the roadmap is delivering the right things?" |
How do you build an Agile roadmap that survives changing priorities?
A strong answer walks through the inputs, the structure, and the governance loop. The roadmap starts from a product vision and a set of business objectives, then breaks those into themes or outcomes rather than a list of features with dates. Each item on the roadmap should map back to a measurable goal so that when priorities shift, the conversation stays anchored in outcomes, not opinions. Quarterly reviews, backlog refinement, and stakeholder demos form the feedback loop that keeps the document honest.
- Define 2–4 quarterly outcomes that tie to company-level OKRs or business goals.
- Group candidate work into themes under each outcome, leaving room for discovery and spikes.
- Apply a prioritisation framework (WSJF, RICE, or MoSCoW) to rank themes by value versus effort and risk.
- Share the draft with stakeholders in a working session, capture objections, and adjust based on new constraints or market signals.
- Revisit the roadmap every sprint or quarter, measuring whether shipped work moved the target metric.
What does a stakeholder management interview question test?
Interviewers want to see that you can hold a difficult conversation without defaulting to either silent compliance or stubborn refusal. A good answer names the stakeholder's concern, restates the business objective the roadmap serves, and offers a concrete path forward, such as a trade-off, a spike to reduce uncertainty, or a phased delivery that de-risks the ask. The interviewer is listening for whether you treat stakeholders as partners who share a goal, not obstacles to work around.
Key facts
- Tarmac has 42 Agile Delivery interview questions on this topic, 10 of them on this page, at difficulty 1–5 of 5.
- Tarmac tracked 2,666 job postings asking for Agile Delivery in September 2026.
- Roles asking for Agile Delivery advertise a median base salary of £75,000, across 384 job postings as of September 2026.
- Tarmac last reviewed these Agile Delivery interview questions on 19 October 2026.
At a glance
| Questions | 10 shown · 42 in the bank |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | Multiple choice, Ordering, Multiple answer, Behavioral, True / false, Design exercise, Short answer, Flashcard |
What you'll review
- stakeholder communication
- stakeholder engagement strategies
- roadmap planning
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
A stakeholder wants to see the working software built during the latest sprint and give feedback on it. Which Scrum event is designed for this?#
Options
Show answer
The Sprint Review is the Scrum event where stakeholders inspect the working increment built during the sprint and give feedback that shapes the product backlog. The Daily Scrum is a short developer sync, the Sprint Retrospective covers team process, and Sprint Planning sets the sprint's scope before work starts.
The Sprint Review is the Scrum event where the team demonstrates the working increment completed during the sprint, and stakeholders inspect it and provide feedback that informs the product backlog. The Daily Scrum is a short, developer-focused synchronization meeting, the Sprint Retrospective examines how the team works rather than showing the product, and Sprint Planning sets the sprint goal and scope before work begins.
Put these steps of a Scrum sprint review's stakeholder communication loop in the order they happen, from first to last.#
Put these in order
Show answer
In a Scrum sprint review, the stakeholder loop runs in this order: the team demonstrates the completed increment, stakeholders give feedback, the Product Owner updates the product backlog, and the updated backlog is used in the next sprint planning. Each step needs the output of the previous one, so the sequence is fixed.
Stakeholders can only give feedback once the team has demonstrated the completed increment, so the demonstration comes first. The feedback is then recorded by updating the product backlog, which must happen before that backlog is used to plan the next sprint. Each step depends on the output of the one before it, so the order is a strict chain: demonstrate, collect feedback, update backlog, plan the next sprint.
In Scrum, which event is the main opportunity for stakeholders to inspect the completed increment and give feedback that shapes the product backlog?#
Options
Show answer
The Sprint Review is the Scrum event where stakeholders inspect the completed increment and give feedback that shapes the product backlog. It is held at the end of each sprint as a working session on the product rather than a status report. The Daily Scrum coordinates developers' work, and the Retrospective examines how the team works.
The Sprint Review is held at the end of each sprint so the Scrum Team can present the finished increment to stakeholders, gather their feedback, and update the product backlog based on it. The Daily Scrum is a short internal sync for developers to plan their next 24 hours, the Sprint Retrospective inspects how the team worked to find process improvements, and Sprint Planning decides the sprint goal and which backlog items to pull in. Only the Sprint Review is designed around stakeholder inspection and feedback.
Your product team works in two-week sprints and must keep several non-technical stakeholders informed about the roadmap. Which of the following practices are sound ways to communicate progress and plans? Select all that apply.#
Options
Pick every one that applies.
Show answer
Effective agile stakeholder communication combines a provisional, theme-based roadmap, sprint reviews that demonstrate working software, and a predictable status update covering progress, decisions, and risks. Fixed dates for every backlog item months ahead and a private roadmap both undermine trust, because agile plans change as the team learns.
Sound stakeholder communication in agile keeps plans visible but honest about uncertainty. A theme-level roadmap labeled as provisional shows direction without false precision, sprint reviews let stakeholders inspect working software and shape the next steps, and a predictable update cadence that names decisions and risks keeps everyone aligned. Committing fixed dates for every backlog item months ahead conflicts with the empirical, adaptive nature of agile work and sets up missed expectations, while keeping the roadmap private to the team removes the transparency stakeholders need to trust the plan.
Tell me about a time you had to engage a stakeholder who was not part of the day-to-day sprint work (for example, a senior business sponsor, a finance lead, or an external partner) so that a project could keep moving. Describe the situation, what you specifically did to engage them, the measurable result, and what you would do differently next time.#
Show answer
On a payments integration project, our finance sponsor was not attending sprint reviews, and she first learned about a two-sprint slip at the quarterly steering meeting, where she was unhappy with the surprise. I asked her for a 30-minute check-in every two weeks and sent her a one-page view listing the three decisions only she could make, each with the date the team needed it by. I also ran the reconciliation demo in her terms, showing how many transactions would fail month-end close under each option. She made the tax-rounding decision on our second call, which avoided a rework cycle we had estimated at about a week. We went live within one sprint of the revised date, and user acceptance defects dropped from 14 in the prior cycle to 3. Looking back, I should have set this cadence at kickoff instead of waiting for the slip, so now I agree on a sponsor check-in cadence and a decision list in the first sprint of every project.
A strong answer sets up a concrete project and a stakeholder who was outside the team's regular rhythm, then describes the first-person engagement actions the candidate chose (such as a standing check-in, a tailored one-page view of the decisions needed, or a demo framed in the stakeholder's terms). It ends with a measurable outcome, such as a decision made by a specific date, rework avoided, or a sprint of delay recovered, and an honest reflection on what the candidate would change, such as starting the cadence earlier. Each rubric criterion is scored independently, so the situation, the actions, the result, and the reflection each need to be present and specific.
True or false: If a Scrum team's release burndown chart shows the team consistently ahead of its planned trend line, stakeholders can treat the release date as guaranteed, because the chart already accounts for any future scope changes.#
Options
Show answer
A burndown chart running ahead of plan does not guarantee a release date. It shows that work is currently being completed faster than forecast, but it does not account for scope added later, re-estimation, or unplanned work. Teams communicate it as a forecast with stated assumptions and a range of likely dates.
The statement is false. A burndown chart shows remaining work against a plan based on current scope and past throughput. It does not account for scope added later, re-estimation, unplanned work, or changes in team capacity, so it cannot guarantee a release date. Good stakeholder communication presents the chart as a forecast, with its assumptions stated and a range of likely dates rather than a promise.
You are the product owner for a 9-person product team that runs two-week Scrum sprints. Three stakeholders are pulling the roadmap in different directions: the VP of Sales wants a specific enterprise feature by the end of the quarter, the Head of Compliance wants an audit-logging change that the team estimates at about 40% of one sprint's capacity, and the CFO wants a monthly view of spend and committed scope. Over the last two quarters, the roadmap was shared as a single fixed date list, items slipped without warning, and stakeholders learned about slips at quarter end. Design the stakeholder communication system you would put in place: the artifacts, the audiences and cadence for each, how conflicting requests get decided, and how you surface changes in forecast. Explain how you would know the system is working.#
Show answer
I would separate the audiences and give each a different artifact. For the VP of Sales and the CFO, I would publish a one-page monthly executive roadmap that lists committed outcomes, not fixed dates, each with a confidence range and a status (on track, at risk, re-baselined), plus a monthly spend and committed-scope view for the CFO. For the engineering team and the Head of Compliance, I would use the sprint review and a shared, ordered backlog where the audit-logging work appears as a visible item with its estimated share of capacity, so compliance sees exactly when it lands. Conflicting requests go to one quarterly planning review, where I, as product owner, rank all requests against agreed criteria: customer value, regulatory risk, and capacity. Sales and Compliance both attend and present their case, and no request is accepted or rejected through a side conversation with an executive. I keep a shared decision log that records each request, the decision, the rationale, and what was declined and why; after each planning review I send a short written summary to each stakeholder and ask them to confirm or flag misunderstandings before the next sprint starts. Forecast changes are raised at the first sprint review where the estimate moves, not at quarter end. Each change states the new range, the cause, the options (scope cut, date move, or added capacity), and the trigger I agreed on for re-baselining, such as a forecast moving beyond the agreed range for two consecutive sprints. To judge whether this works, I would track how many slips were first reported by someone other than the product owner, how many escalations bypassed the planning review, how often a logged decision is later reopened, and whether stakeholders can restate the trade-off back accurately in their own words.
The strongest answer is a system rather than a status report: it differentiates artifacts by audience, funnels all conflicting requests through one forum with explicit criteria, makes forecasts probabilistic and surfaces changes at the earliest sprint review with defined re-baselining triggers, and closes the loop with a decision log and an explicit understanding check. Each criterion is independent: artifacts describe what each audience sees, the decision path describes how trade-offs are resolved, the forecast criterion describes how uncertainty and change are communicated, and the decision record describes how decisions and understanding are documented and verified. Answers that only say to 'communicate more often' or 'keep stakeholders informed' do not earn credit because they lack the concrete artifact, decision owner, and trigger.
True or false: To forecast when a roadmap item will be delivered, you can divide its remaining estimated story points by the team's recent average velocity (points per sprint), and the resulting date should be presented as a range rather than a firm commitment.#
Options
Show answer
True. Forecasting a roadmap item's delivery means dividing its remaining story points by the team's recent average velocity to estimate the sprints needed. Because velocity varies with estimation error and changing scope, teams present that forecast as a range rather than a firm commitment.
Velocity is an empirical measure of how many estimated points a team completes per sprint. Dividing remaining points by average velocity gives an estimated number of sprints to finish the item. Because estimates, team changes, and scope discovery all add variance, a good forecast is communicated as a range (for example, using best and worst recent velocities) rather than a single guaranteed date. The statement is therefore true.
A VP asks you to turn your quarterly roadmap into a single committed ship date for a theme that depends on the Platform team's API, which is still unfinished. The VP wants the date in a board deck. In 3-6 sentences, explain how you would respond: what you would tell the VP about the dependency and the uncertainty, which alternatives you would offer instead of one fixed date, and how you would protect trust if the date later moves.#
Show answer
I would explain that the date depends on the Platform API, which is not yet finished, so a single committed date would be a guess presented as a promise. I would give a forecast range based on the Platform team's current progress and state the confidence level and the assumptions behind it. I would offer alternatives: commit to a scope-based milestone (for example, the first customer-facing slice once the API contract is agreed), or commit to a date only after a named dependency milestone is met. I would agree on a review point where the range is updated, and I would flag any change early, with the cause and the options, so the VP is never surprised by a slip.
The strong answer recognises that a date built on an unfinished upstream dependency is an uncertain estimate, so the stakeholder should receive a forecast range with an explicit confidence level and stated assumptions rather than a single committed date. It then offers alternatives that stay honest, such as a scope-based milestone or a date gated on a dependency milestone, and sets a regular checkpoint to re-forecast. Trust is protected by surfacing changes early with causes and options, not by hitting a date at any cost. The keywords check for dependency handling and for range, confidence, forecast, scope or milestone language, which together capture the core of this communication.
An executive sponsor asks for one committed ship date for a 12-epic roadmap whose estimates vary widely, and the team has several months of historical throughput data (completed items per week). Name the forecasting technique you would use to turn that throughput history into a date forecast, and state what it outputs that a single date does not.#
Show answer
Monte Carlo simulation of the backlog using historical throughput. Repeatedly sample weekly throughput from past data to simulate how many weeks it takes to finish the remaining scope, many thousands of times. The output is a probability distribution of completion dates, so you can report a date range with confidence levels (for example, a 50%, 85%, and 95% likelihood date) instead of one committed date. Communicate that range alongside the scope that is flexible, so stakeholders can trade scope against date.
A single date hides the variance in the estimates and throughput, so it implies a precision the data does not support. Monte Carlo forecasting from historical throughput is the standard probabilistic method in Agile delivery: it samples past weekly completion rates to simulate many possible futures and yields a distribution of finish dates. Presenting percentile-based dates with the flexible scope made explicit gives stakeholders an honest, decision-useful forecast that can be re-run as new throughput data arrives.
Related interview questions
Job market
See agile-delivery salaries and hiring demand from live job postings.
The other 32 questions
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 32 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan