Delivery practice questions

Team calendar.

Why it fails: A team calendar schedules ceremonies, leave and events; it carries no product direction. It is tempting because it is a shared, readily available team artefact, but defining the product vision requires a vision statement or roadmap that states the target outcome and audience, which a calendar cannot express.

Sprint burndown.

Why it fails: A sprint burndown tracks remaining work within a single iteration, giving no view of the product's longer-term direction. It is tempting because it is a visible, frequently updated chart, but the product vision requires a product vision statement or roadmap spanning releases, not sprint-level progress.

Meeting minutes.

Why it fails: Meeting minutes record discussions and decisions but do not articulate the product vision itself. They are tempting because they capture stakeholder input that informs the vision, yet the vision statement or product roadmap is the artefact that actually defines and communicates the intended outcome.

Ask the team to work overtime to finish the backlog faster.

Why it fails: Overtime increases output volume, not alignment; the backlog itself encodes the outdated priorities, so faster delivery reproduces the same mismatch. It appeals because visible effort feels responsive. Re-prioritising the backlog with the product owner would be correct when the issue is delivery pace rather than content.

Update the release burn-down chart to reflect current progress.

Why it fails: A burn-down chart reports remaining work over time; updating it changes only the displayed progress, not which features are built, so alignment stays broken. It tempts because stakeholders often cite stale charts. Refreshing burn-downs is correct when reporting accuracy, not priority mismatch, is the underlying issue.

Change the definition of done to speed up delivery.

Why it fails: Redefining done lowers the quality bar; it does not reorder work toward current organisational priorities, so delivered features remain misaligned. It tempts because accelerating throughput appears to address stakeholder dissatisfaction. Tightening or relaxing done is correct when the team's quality standard, not the backlog's ordering, is the actual problem.

Sprint Retrospective.

Why it fails: The retrospective inspects the team's own process and working agreements after a sprint; it produces improvement actions rather than synchronising in-flight dependencies across teams. It is tempting because it is a recurring cross-team touchpoint. A Scrum of Scrums or similar integration event is the correct forum for coordinating inter-team dependencies.

Daily Stand-up.

Why it fails: The Daily Stand-up is a single team's internal inspection of progress toward its sprint goal; it does not provide the cross-team representation needed to resolve inter-team dependencies. It is tempting because it is frequent and coordination-focused. A Scrum of Scrums, with delegates from each team, is the correct synchronisation forum.

Sprint Planning.

Why it fails: Sprint Planning commits one team to its own sprint backlog and forecast; it does not synchronise dependencies between multiple teams during delivery. It is tempting because dependencies are discussed when work is selected. A Scrum of Scrums or scaled planning event is the correct forum for ongoing cross-team dependency coordination.

Increase the story point estimates to account for the decrease.

Why it fails: Inflating estimates to match the lower velocity masks the underlying impediment and corrupts the team's historical data, since story points measure relative size, not capacity. It is tempting because re-baselining feels like honest recalibration, but that is warranted after a deliberate scope or team change, not a sudden unexplained decline.

Reduce the team size to improve communication overhead.

Why it fails: Shrinking the team lowers capacity further and destroys the shared ownership that surfaces impediments; velocity would likely drop again. Reducing headcount is tempting when communication overhead is blamed, but the first step is examining the cause of the decline, such as new work or blockers.

Commit to the same number of story points to pressure the team to improve.

Why it fails: Committing to the same story points ignores the observed 20% velocity drop, forcing overcommitment and eroding trust rather than addressing the cause. It is tempting because fixed commitments can feel like healthy pressure, but that approach suits stable-velocity teams, not one already trending downward across two iterations.

Require every team to report directly to the Portfolio Manager for daily tasks.

Why it fails: Daily reporting to a Portfolio Manager inserts a command-and-control layer that contradicts scrum team self-organisation and cross-team coordination. It tempts because portfolio governance exists for funding and strategic alignment, but that is periodic oversight, not daily task direction.

Mandate that each team has a different iteration length to avoid meeting conflicts.

Why it fails: Differing iteration lengths across teams break the shared cadence needed for a common sprint review, joint backlog refinement and synchronised release increments. It tempts because staggered iterations can reduce meeting clashes, but coordinated multi-team delivery depends on aligned sprints.

Report primarily on task completion percentages from the Jira dashboard.

Why it fails: Task completion percentages track activity against a plan, which is a project-based control metric and says nothing about whether the product delivers value to users. It is tempting because Jira dashboards surface this data readily, but task completion is the right measure for monitoring execution progress within a defined project scope.

Track the number of features delivered per quarter.

Why it fails: Counting features per quarter measures output volume, not the outcome or value the product delivers, so it does not reflect product-based funding's focus on continuous value realisation. It is tempting because delivery metrics are easy to pull from tracking tools, but throughput counting suits capacity planning rather than demonstrating product success.

Focus on budget adherence and total project spend.

Why it fails: Budget adherence and total spend measure cost control against a fixed project budget, which is the project-based funding model being replaced, not product outcome. It is tempting because finance reporting centres on spend, but budget tracking is correct when the organisation funds discrete projects with defined scope and end dates.

Outsource the testing phase to a specialized third-party vendor.

Why it fails: Outsourcing testing inserts an external handoff and wait state, lengthening the end-to-end flow the team is trying to shorten. It is tempting because a specialist vendor can absorb peak test volume, which suits a fixed-scope release needing extra capacity rather than continuous flow optimisation.

Add a quality assurance gate at the end of the development lifecycle.

Why it fails: A gate at the lifecycle's end batches defects into a late inspection queue, extending lead time instead of reducing it. It is tempting because end-stage QA gates suit regulated, phase-gated delivery where formal sign-off evidence is contractually required before release.

Increase the frequency of daily stand-ups to two times per day.

Why it fails: Doubling stand-ups adds ceremony without removing any queue, handoff or work-in-progress limit, so lead time is unchanged. It is tempting because stand-ups surface blockers, and in a team whose flow is stalled purely by unspoken impediments, a second daily sync could genuinely accelerate resolution.

Add more team members to distribute the workload.

Why it fails: Adding team members increases coordination overhead and does not address the context switching itself, so end-to-end flow remains impeded. It is tempting because resource levelling can relieve individual overload, and it would suit a capacity-constrained backlog where throughput is limited by headcount rather than by work-in-progress discipline.

Conduct a daily stand-up meeting for longer durations.

Why it fails: Extending the daily stand-up addresses coordination visibility, not flow. It cannot reduce context switching because it adds meeting time without limiting work in progress or removing queueing between stages. Stand-ups suit surfacing blockers and synchronising a team; value-stream mapping or WIP limits are the lean techniques that actually optimise end-to-end flow.

Increase the sprint duration to allow more time for tasks.

Why it fails: Lengthening the sprint leaves context switching intact and delays feedback; it does not limit work in progress. Sprint duration is a cadence decision, correct when a team needs a longer horizon for genuinely larger increments.

Switch to Kanban to eliminate the need for sprint planning.

Why it fails: Kanban still requires explicit policies and dependency management; removing sprint planning does not eliminate external waits or create flow. It tempts teams wanting continuous delivery with variable arrival of work, where cadence is deliberately replaced by WIP limits and service classes.

Lengthen the sprint duration to allow more time for external teams to respond.

Why it fails: Longer sprints delay feedback and hide dependency blockage rather than removing it, so end-to-end flow worsens. It appeals because more calendar time appears to absorb external waits, and fixed-length sprints suit teams whose dependencies reliably respond within the iteration.

Assign a dedicated project manager to track dependency status manually.

Why it fails: Manual tracking by a project manager adds coordination overhead and lag without changing the dependency itself, so flow does not improve. It appeals where dependencies are few and a single owner can escalate, but sustained cross-team blockage needs visible queues and pull-based flow.

Individual task duration.

Why it fails: Individual task duration measures effort on single tasks, not value delivered by the whole team per iteration. It is tempting because task timing feeds cycle-time analysis, yet it would be the right metric for diagnosing workflow bottlenecks, not iteration-level value consistency.

Team morale survey scores.

Why it fails: Morale survey scores capture team sentiment, not delivered value, so they cannot measure consistency of output per iteration. They are tempting because morale influences performance, yet such surveys would be the correct choice for tracking team health or engagement over time.

Number of meetings attended.

Why it fails: Meetings attended counts activity, not delivered value, so it cannot show consistency of output per iteration. It is tempting because engagement feels related to performance, yet it would suit assessing collaboration or ceremony participation, not value delivery.

Stop all work until the dependencies are resolved.

Why it fails: Halting all work converts a coordination problem into a delivery stoppage, wasting capacity while dependencies remain unresolved. Dependencies are handled by making them visible, sequencing work and coordinating through Scrum of Scrums or dependency boards. Stopping suits a genuine blocking impediment, not routine cross-team dependencies.

Assign a single manager to direct all four teams.

Why it fails: A single directing manager reinstates command-and-control, removing the teams' self-organisation and delaying decisions to one person. Dependency management at scale uses Scrum of Scrums or a shared dependency board, where representatives coordinate across teams. A single manager suits a small, co-located team lacking direction.

Merge all teams into one large team to simplify communication.

Why it fails: Merging four teams into one enlarges communication paths and destroys the small-team structure that enables self-organisation. Cross-team dependencies are managed through Scrum of Scrums, shared backlogs and dependency boards while teams stay intact. Merging suits a team too small to hold all needed skills.

Extend the sprint to accommodate the blocker.

Why it fails: Sprint length is fixed; extending it breaks the timebox that underpins empiricism and forecasting. It tempts because adding time appears to solve capacity shortfalls, but the correct response is to renegotiate scope with the product owner or remove the blocked item.

Remove the feature from the product backlog entirely.

Why it fails: Deleting the item discards prioritised value the product owner owns, rather than addressing the blocker. It tempts because removing work reduces sprint scope, but backlog refinement and re-prioritisation, not deletion, handle items that cannot yet be delivered.

Ignore the blocker and hope the team finishes.

Why it fails: Ignoring the blocker leaves the sprint goal unachievable and hides an impediment the team must surface. It tempts because teams sometimes hope issues resolve themselves, but agile practise requires the blocker be raised, analysed and addressed or the scope renegotiated with the product owner.

The team is highly efficient.

Why it fails: A widening gap indicates a backlog of work, not efficiency.

The sprint is ahead of schedule.

Why it fails: Ahead-of-schedule delivery would show Done rising steeply with a narrowing In Progress band, not a widening one. It is tempting because rising lines suggest progress, but the gap specifically measures accumulating unfinished work, which signals delay rather than being ahead.

The team has stopped working.

Why it fails: A widening band means work is entering In Progress faster than it leaves for Done, indicating a bottleneck or accumulating work in progress, not idleness. It is tempting because a flat or horizontal line would indicate no throughput, which is what stopped work actually looks like on a cumulative flow diagram.

Standardize all software tools across the organization.

Why it fails: Tool standardisation addresses technical inconsistency, not the organisational boundaries that block flow; identical tooling still leaves teams handing off work across functional walls. It is tempting because shared platforms reduce friction, and would be correct if the problem were incompatible toolchains rather than siloed teams.

Implement a waterfall project plan to force coordination.

Why it fails: A waterfall plan imposes sequential phase gates and upfront scheduling, which reinforces the functional handoffs causing the silos rather than removing them. It is tempting because it appears to impose coordination, and would fit a regulated delivery needing fixed baselines, but it cannot optimise end-to-end flow.

Increase the number of status reporting meetings.

Why it fails: Additional status meetings add reporting overhead without altering how work moves between teams, leaving the same queues and handoffs in place. It is tempting because visibility feels like coordination, and would be correct if the problem were unknown progress, but the stem describes siloed delivery flow.

First come, first served.

Why it fails: First come, first served sequences work by request arrival time, not by value or strategic alignment, so high-impact items can wait behind trivial ones. It is tempting for support queues where fairness of arrival matters, but backlog prioritisation requires ranking against organisational objectives.

Random selection.

Why it fails: Random selection ignores business value, risk and dependency, so backlog order bears no relation to organisational goals. It is tempting as a way to avoid stakeholder bias, but random ordering suits only trivial, equally weighted items, never goal-driven prioritisation.

Assigning tasks by individual preference.

Why it fails: Individual preference orders work by developer interest, which need not correlate with customer value or organisational goals. It is tempting because motivated individuals deliver faster, yet preference-based ordering belongs to informal task selection, not to goal-aligned backlog prioritisation.

Add more hours to the work week for the team.

Why it fails: Extending working hours addresses capacity symptoms without controlling incoming scope, and sustained overtime degrades throughput and quality. Scope creep is handled through backlog refinement and stakeholder negotiation; adding hours suits a fixed, agreed deadline with stable scope.

Delete the backlog to force a restart.

Why it fails: Deleting the backlog discards prioritised, refined work and the empirical data needed to re-plan, leaving the team with no ordered queue to pull from. It appeals as a dramatic reset, and would be defensible only when the product direction has fundamentally changed and existing items are genuinely obsolete.

Accept all new requests to please stakeholders.

Why it fails: Accepting every request expands the product backlog without renegotiating priorities, so the team's fixed sprint capacity is consumed by unplanned work and nothing ships. It is tempting because responsiveness to stakeholders feels collaborative, and it would suit a discovery phase where validating demand matters more than protecting a committed delivery cadence.

Increase the WIP limit.

Why it fails: Raising the WIP limit admits more concurrent work, which lengthens queues and increases cycle time further, worsening the symptom. It is tempting because a backlog of unfinished items suggests capacity is the constraint. The correct first step is to inspect the workflow for bottlenecks, not to add load.

Fire the team lead.

Why it fails: Removing the team lead attributes the problem to a person before any data is gathered, destroying psychological safety and hiding the real cause. It is tempting when a visible figure is blamed for delivery slippage. The correct first step is to examine the system, such as work in progress and blockers.

Ignore it as minor fluctuations.

Why it fails: Ignoring the trend leaves the root cause unidentified, so cycle time continues rising and delivery forecasts degrade. It is tempting because minor single-sprint variation is normal noise, and dismissing one spike is reasonable. Three consecutive sprints of increase is a trend, which warrants investigation rather than dismissal.

To discuss team conflicts.

Why it fails: The sprint review inspects the increment with stakeholders and adapts the product backlog; team conflicts belong to retrospectives or coaching conversations. It is tempting because both ceremonies involve the team talking, but the review's focus is product feedback and acceptance, not interpersonal dynamics.

To calculate velocity.

Why it fails: Velocity is computed from completed backlog items, not from the review itself; the review's purpose is inspecting the increment and adapting the backlog. Calculating velocity is a planning or tracking activity, so it would fit a retrospective or refinement session where throughput data informs forecasting.

To plan the next sprint.

Why it fails: Planning the next sprint happens in sprint planning, not the review. The review demonstrates the completed increment to stakeholders and gathers feedback to adapt the backlog; it is tempting because review outcomes do feed planning, but selecting and estimating upcoming work is a separate ceremony with its own purpose.

That the project budget is not exceeded.

Why it fails: Budget adherence is tracked through cost reporting and financial controls, not through the completion criteria a team applies to increments. A Definition of Done instead fixes the quality bar every increment must satisfy before it counts as complete.

That the team is working the required number of hours.

Why it fails: Hours worked measure effort input, whereas a Definition of Done describes the quality criteria an increment must satisfy to be considered finished. Time tracking belongs to capacity planning and timesheets, not to the shared completion agreement.

That all requirements have been met regardless of effort.

Why it fails: A Definition of Done is a fixed quality standard applied to every increment; it does not guarantee that every requirement is delivered regardless of effort. Scope completion is governed by the product backlog and sprint goal, with unfinished work returning to the backlog.

Budget report.

Why it fails: A budget report tracks planned versus actual spend, containing no workflow states, queues or cycle-time data from which bottlenecks could be identified. It is tempting because it is a familiar project artefact, and it would be correct for monitoring cost variance rather than process flow.

Gantt chart.

Why it fails: A Gantt chart plots tasks against calendar time to show scheduling and dependencies, so it exposes timeline slippage rather than workflow congestion. Bottlenecks appear as queued work between process stages, which a cumulative flow diagram or kanban board reveals; Gantt would suit a plan-driven schedule with fixed milestones.

Pie chart of tasks.

Why it fails: A pie chart shows each task's proportion of a total, such as effort split across categories, so it cannot display work flowing between stages or where items accumulate. Bottlenecks are identified from queue build-up in a cumulative flow diagram; pie charts suit static composition questions like defect distribution by severity.