Product practice questions

Simply follow the highest-paid person's opinion.

Why it fails: This ignores the value perspective of the team and product data.

Prioritize based on whichever stakeholder screams the loudest.

Why it fails: This leads to poor product strategy and team burnout.

Average the rankings provided by all stakeholders.

Why it fails: Averaging often leads to mediocrity and ignores the urgency of specific business needs.

The technical architecture.

Why it fails: User stories focus on user needs, not the underlying architecture.

The user role.

Why it fails: The user role is explicitly stated.

The development team's estimate.

Why it fails: Estimates are typically added during sprint planning.

The role.

Why it fails: The role is identified as 'a user'.

To replace the need for daily team communication.

Why it fails: A roadmap communicates direction and sequencing, not daily task coordination; stand-ups and backlog refinement serve that purpose. It is tempting because roadmaps do align stakeholders, but replacing daily communication is not a primary goal — the roadmap operates at release and outcome level, not sprint-level team synchronisation.

To act as a contract that cannot be changed.

Why it fails: A roadmap is a living, adaptive artefact; treating it as an unchangeable contract contradicts agile responsiveness to feedback. It is tempting because roadmaps do set expectations with stakeholders, but that commitment is directional, not contractual — scope and timing are revised as learning occurs, which a fixed contract would forbid.

To provide a list of every single line of code.

Why it fails: A roadmap expresses themes, outcomes and timeframes, not source code; code listings belong in version control. It is tempting because roadmaps list planned features, which can be mistaken for exhaustive detail, but the artefact deliberately stays at a high level and never enumerates every line of implementation.

Allow developers to decide the new vision.

Why it fails: Developers lack the stakeholder access and product accountability to set direction; the Product Owner owns the vision and its validation. Delegating suits technical implementation decisions within a sprint, not market-facing strategy, which requires customer and business input.

Wait until the end of the project to change the vision.

Why it fails: Deferring revision until project end means every intervening sprint delivers against an obsolete vision, compounding rework. Agile expects the Product Owner to adapt the vision as market evidence emerges; waiting suits fixed-scope predictive projects with frozen requirements and no market volatility.

Ignore the shift and continue with the original plan.

Why it fails: Ignoring the market shift leaves the team building toward a vision customers no longer value, wasting sprint capacity. The Product Owner owns the vision and must revalidate it with stakeholders; ignoring suits stable markets where the vision still aligns with validated customer needs.

The sprint will end earlier than expected.

Why it fails: Sprint length is fixed by the timebox, not by story clarity; absent acceptance criteria cause scope ambiguity, rework and failed reviews rather than early completion. It tempts because unclear stories may be estimated lower, but that would only hold if the team intentionally shortened the sprint, which Scrum forbids mid-sprint.

The velocity will artificially increase.

Why it fails: Velocity measures completed work against the definition of done; missing acceptance criteria make completion ambiguous, so velocity becomes unreliable rather than artificially higher. It tempts because unverified stories might be marked done prematurely, but that would only occur if the team deliberately relaxed its quality standard, not as an automatic effect.

The story will be too small to estimate.

Why it fails: Missing acceptance criteria does not shrink a story; it removes the shared definition of done, so developers cannot confirm scope or know when work is complete, causing rework and disputes. It tempts because vague stories can be estimated quickly, but that would only apply if the team deliberately deferred detail, not because criteria are absent.

The sprint burndown chart.

Why it fails: A burndown chart tracks remaining effort against time within a sprint; it records progress, not the authoritative list of work. It is tempting because it does reflect team workload daily, and would be the right artefact for forecasting sprint completion or spotting scope creep mid-iteration.

The communication plan.

Why it fails: A communication plan defines who receives which information, when and through which channel; it contains no work items. It is tempting because it governs stakeholder engagement across the project, and would be correct when the question concerns information flow, reporting cadence or escalation paths.

The project charter.

Why it fails: The project charter authorises the project and names the sponsor and high-level objectives; it does not enumerate development tasks. It is tempting because it is a foundational, formally approved document, and would be correct when asked what empowers the project manager to proceed.

The story must be at least 10 pages long.

Why it fails: Length is not a readiness criterion; user stories are intentionally concise, with detail captured in acceptance criteria or conversations. It is tempting because thorough documentation feels safe, but INVEST favours small, negotiable stories, and a ten-page story would fail the small and estimable tests.

The story must be approved by the CEO.

Why it fails: CEO approval is an organisational sign-off unrelated to story readiness; the team needs INVEST and acceptance criteria to estimate. It tempts because executive endorsement matters for prioritisation and funding, and would be the correct gate before committing budget to a large initiative.

The story must be assigned to a specific developer.

Why it fails: Assigning a developer before estimation contradicts collective ownership; the team estimates together, and assignment happens during sprint planning or task breakdown. It is tempting because accountability feels concrete, but readiness criteria concern clarity, acceptance criteria, and independence, not pre-assigned ownership.

Archive the entire backlog and start a new one.

Why it fails: Archiving everything discards the historical record and prioritisation context the team still needs, and the new backlog immediately grows again. It is tempting as a clean-slate reset, and it would be correct for a genuinely obsolete backlog being formally retired, not one that simply needs refinement and ordering.

Increase the number of items per page in the tool.

Why it fails: Showing more rows per page does not reduce the backlog's size or add structure, so relevant items stay buried in a longer list. It is tempting because it is a quick tool configuration change that superficially increases what is visible, and it would help if the problem were excessive pagination rather than poor backlog organisation.

Delete all old user stories to clear the clutter.

Why it fails: Deleting old stories destroys value, traceability and audit history, and removes items that may still be prioritised later. It is tempting because it instantly shrinks the list, and it would be acceptable only for items confirmed as duplicates or permanently out of scope, not as general clutter control.

Reject the request because it was not in the roadmap.

Why it fails: A roadmap is a directional artefact, not a contractual baseline, so refusing outright ignores the product owner's remit to re-prioritise the backlog as value emerges. Rejection fits a fixed-price predictive contract where scope is baselined and change control governs additions.

Immediately add the feature to the current sprint.

Why it fails: Adding work mid-sprint undermines the sprint goal and the team's agreed commitment, since scope is fixed for the sprint's duration. This instinct suits urgent production defects, where an interrupt is negotiated with the product owner rather than assumed.

Refer the request to the project manager for approval.

Why it fails: In agile, the product owner owns and prioritises the backlog, so routing change requests to a project manager bypasses that authority. Escalation suits predictive governance, where a change control board or sponsor approves scope changes against a baselined plan.

Mark the story as blocked and move to the next sprint.

Why it fails: Marking the story blocked defers the problem without splitting it, so the team still cannot forecast delivery and the sprint goal remains at risk. Blocking suits external dependencies, not oversized scope; the story must be decomposed into smaller slices that fit within one sprint.

Extend the sprint duration to accommodate the story size.

Why it fails: Extending the sprint breaks the fixed timebox that makes velocity predictable and disrupts the cadence of reviews and retrospectives. Sprint duration is held constant precisely so scope flexes; extending it would be considered only in rare, organisation-wide circumstances, never for one oversized story.

Ask the developers to work overtime to finish it.

Why it fails: Overtime masks the sizing defect rather than correcting it, and sustained overtime degrades quality and velocity. It is tempting because deadlines feel urgent, but overtime suits short, exceptional recovery efforts, not routine planning of a story that simply exceeds sprint capacity.

The sprint duration is too short.

Why it fails: Sprint length governs feedback cadence, not whether the backlog addresses customer needs; shorter sprints deliver the wrong increments faster. It is tempting because frequent reviews expose misalignment, and shortening sprints would be correct where feedback loops are too slow to catch requirement drift.

The team is lacking a project manager.

Why it fails: Velocity measures output volume, not whether that output satisfies customer needs; a project manager would not align backlog items to value. The role is tempting because traditional projects centralise coordination there, and it would be correct where cross-team dependencies and scheduling lack an owner.

The team is not using enough automated tests.

Why it fails: Automated test coverage affects defect detection and regression safety, not whether delivered increments match customer needs; high velocity with poor fit points to weak product backlog refinement or absent customer feedback. It tempts because testing underpins quality, but here the gap is requirements validation, not verification.

To replace the need for sprint planning.

Why it fails: Release planning schedules which features reach users in a given version; it does not supersede sprint planning, which still decomposes and commits to work each iteration. It is tempting because release plans do sequence deliverables across sprints, but that coordination role never removes the need for sprint-level planning.

To dictate the exact daily tasks for each developer.

Why it fails: Release plans operate at feature and version level across sprints; assigning individual daily tasks is the remit of the team's sprint planning and daily coordination. It is tempting because release plans do allocate work to iterations, but that coarse sequencing never descends to dictating each developer's daily tasks.

To guarantee that all features will be completed on time.

Why it fails: A release plan forecasts scope and timing against the roadmap, but it is a planning artefact, not a guarantee; discovery and changing priorities routinely shift content. It is tempting because release plans do set target dates, yet that forecast is deliberately revisable rather than a contractual commitment to on-time completion.

The Project Sponsor.

Why it fails: The Project Sponsor funds the initiative and champions it at executive level, but does not maintain or order backlog items. It is tempting because sponsors represent business interests, yet translating those interests into a prioritised backlog is the Product Owner's continuous responsibility, not a funding or governance activity.

The Scrum Master.

Why it fails: The Scrum Master coaches the team on Scrum and removes impediments, but does not own backlog content or prioritisation. It is tempting because the role sounds like a general coordinator, yet ordering and refining items to reflect stakeholder needs belongs to the Product Owner, who alone owns the backlog.

The Lead Developer.

Why it fails: The Lead Developer owns technical design and code quality, contributing estimates and feasibility input, but not stakeholder-facing backlog content. It is tempting because developers refine and clarify items daily, yet deciding what the backlog should contain and its order is the Product Owner's accountability, not a technical lead's.

To list every feature to be built in the product.

Why it fails: A feature list is a product backlog or roadmap artefact; the Product Vision states the overarching goal and target customers that give features their direction. It is tempting because visions eventually decompose into features, but enumerating every feature replaces strategic intent with tactical inventory.

To track the budget spent on the development team.

Why it fails: Budget tracking belongs to finance or the product owner's investment decisions, not the Product Vision, which articulates the desired future state and value the product delivers. It is tempting because visions justify funding, yet cost accounting is a separate governance activity.

To provide the specific daily meeting agenda.

Why it fails: The Product Vision communicates the long-term purpose and target outcome of the product; daily meeting agendas belong to the Scrum Master or team's facilitation of the Daily Scrum. It is tempting because visions guide day-to-day priorities, but scheduling mechanics sit outside their scope.

The Product Owner is now responsible for the annual budget.

Why it fails: Product-based funding shifts investment decisions to persistent value streams; the Product Owner still prioritises the backlog and defines outcomes rather than owning the annual budget. Budget ownership is tempting because funding becomes continuous, but it would be correct only where the role formally holds financial accountability.

The Product Owner no longer manages the backlog.

Why it fails: Product-based funding keeps backlog ownership with the Product Owner, since continuous value delivery still requires prioritisation against outcomes. Dropping backlog management is tempting when funding shifts from projects to products, but it would be correct only if the role were redefined away from product direction entirely.

The Product Owner now reports to the finance department.

Why it fails: Product-based funding changes how investment is allocated across value streams, not the Product Owner's reporting line into finance. Reporting to finance is tempting because funding decisions become continuous, yet it would be correct only if the organisation restructured the role's governance and line management accordingly.

Force the team to work overtime to ensure completion.

Why it fails: Overtime does not reduce the identified risk; it masks schedule pressure while increasing defect and burnout likelihood, and the Product Owner lacks authority to compel it. It tempts because deadline pressure feels actionable, but overtime suits short capacity gaps on low-risk work, not high-risk features needing spikes or renegotiation.

Delegate the task to a junior developer to save costs.

Why it fails: Reassigning to a junior developer addresses cost, not the identified risk; reduced experience raises the probability of failure on a high-risk task. It tempts as a resourcing shortcut, yet delegation suits routine, well-understood work where a junior can safely deliver with mentoring.

Agree to the request to satisfy the stakeholder.

Why it fails: Agreeing satisfies the stakeholder but ignores the team's risk assessment, committing to a date the team cannot support and hiding the trade-off. It tempts because stakeholder harmony feels productive, yet accepting a request is right only when capacity and risk allow, following backlog refinement and transparent negotiation.

It is required by the project management office.

Why it fails: PMOs may prefer hours, but agile teams prefer points.

It makes it easier to track individual performance.

Why it fails: Story points deliberately obscure individual effort, supporting collective ownership; tracking individual performance contradicts agile principles and distorts estimates. Hours suit individual productivity measurement, whereas points are correct when the team forecasts capacity collaboratively rather than appraising members.

It ensures that every story takes exactly the same amount of time.

Why it fails: Story points measure relative size across dimensions including complexity and uncertainty, so identical durations are never implied. Fixed equal durations describe hours-based estimation with standardised tasks, which is why points avoid false precision when velocity varies between teams.

To the personal notepad of the Scrum Master.

Why it fails: A personal notepad hides the bug from the product backlog, so it cannot be prioritised, estimated or tracked on the burndown chart, and it is lost if the Scrum Master is absent. Personal notes suit an individual's private reminders, not work the team must collectively schedule and deliver.

To a separate bug-tracking document outside of the product tool.

Why it fails: A bug-tracking document outside the product tool breaks the single source of truth, so the item is invisible to sprint planning, burndown tracking and daily stand-up. It is tempting because external logs suit audit trails or compliance records, not active sprint work that must be prioritised and estimated alongside other backlog items.

To the project charter.

Why it fails: The project charter captures high-level scope and authority at project initiation; it is not a work-tracking artefact. A small bug found mid-sprint belongs in the product backlog for the Product Owner to prioritise. The charter would be correct only for recording project-level objectives or constraints.

Building the entire product first and asking for feedback later.

Why it fails: Building the whole product before gathering feedback inverts elicitation: requirements must be captured before construction, not inferred from a finished artefact. It is tempting because iterative delivery does welcome late feedback, yet that feedback refines an existing backlog rather than eliciting initial stakeholder needs.

Guessing the requirements based on past projects.

Why it fails: Extrapolating requirements from prior projects substitutes assumption for direct stakeholder engagement, so it captures no current need. Historical data legitimately informs estimating and analogous planning, but elicitation demands techniques such as interviews, workshops or observation with the actual stakeholders.

Waiting for the stakeholders to send an email.

Why it fails: Passively awaiting an email yields no structured dialogue, no follow-up probing and no clarification of ambiguous needs. It is tempting because written correspondence creates a record, but effective elicitation requires active techniques such as interviews, workshops or observation that draw requirements out directly from stakeholders.

The team finishes all stories in the sprint.

Why it fails: Completing all committed stories indicates effective sprint execution and stable scope, not weak refinement. Poor refinement appears as oversized, vague items the team cannot estimate or split. Finishing work is the outcome refinement supports, so it cannot be the symptom sought.

The backlog is sorted by priority.

Why it fails: Priority ordering is exactly what refined backlogs exhibit, so it signals healthy refinement rather than poor practice. Poor refinement shows as large, unestimated, unordered items lacking acceptance criteria. The option fails because it describes the desired state, not a defect.

The product owner is involved in refinement.

Why it fails: Product owner participation is central to good refinement, since they clarify value and order items. Poor refinement shows as the product owner absent, leaving stories ambiguous. The option describes the healthy practice, so it cannot be a sign of poor refinement.