EXIN Agile Scrum Product Owner cheat sheet

The Agile Manifesto (2001) lists four values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan.

The Manifesto's twelve principles include delivering working software frequently (weeks rather than months), welcoming changing requirements even late in development, and self-organizing teams.

Scrum is an empirical process-control framework resting on three pillars: transparency, inspection, and adaptation. The three Scrum pillars are assessed at each Sprint Review and Retrospective.

Empiricism holds that knowledge comes from experience and decisions are based on what is observed; it replaces predictive, plan-driven control for complex work.

The five Scrum values are commitment, courage, focus, openness, and respect; they guide behavior but are not roles, events, or artifacts.

Iterative-incremental delivery shortens feedback loops: each Sprint produces a potentially releasable Increment, so value is delivered early and risk is reduced.

Scrum is deliberately incomplete: it defines roles, events, and artifacts but leaves engineering practices (TDD, CI, refactoring) to the team.

The Product Owner is one person, not a committee; the Scrum Team consists of one Product Owner, one Scrum Master, and Developers (typically ten or fewer).

Timeboxing fixes a maximum duration for each event: Sprint (one month or less), Sprint Planning (max 8 hours for a one-month Sprint), Daily Scrum (15 minutes), Sprint Review (max 4 hours), Sprint Retrospective (max 3 hours).

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team; the role is one person, and the PO may delegate work but remains accountable.

The PO owns and manages the Product Backlog: clearly expressing items, ordering them to best achieve goals, and ensuring the backlog is visible, transparent, and shows what the Scrum Team will work on next.

The PO is the sole authority for ordering the Product Backlog and for accepting or rejecting work against the Definition of Done; Developers do not reorder priorities unilaterally.

The PO is one of the three Scrum accountabilities and participates in Sprint Planning, Sprint Review, and refinement; the PO need not attend the Daily Scrum unless helping the Developers.

The PO must be available to the Developers to answer questions and clarify requirements; unavailability is a common cause of rework and Sprint failure.

Stakeholder management is a core PO duty: gathering input, communicating progress, and shielding the Developers from mid-Sprint scope changes.

The PO does not micromanage technical solutions; how items are built is decided by the Developers, while what and why are the PO's domain.

In scaled settings the PO may work with proxies or stakeholders, but final ordering authority and single accountability remain with the PO.

The Product Backlog is an emergent, ordered list of what is needed to improve the product; it is the single source of work undertaken by the Scrum Team.

Backlog refinement is the ongoing act of breaking down and further defining items into smaller, more precise ones; it typically consumes no more than 10 percent of team capacity.

Ordering rules commonly used: value, risk, dependency, cost of delay, and learning; the highest-order items are usually the most valuable, clearest, and smallest.

User stories follow the form 'As a , I want so that ' and are supported by acceptance criteria that define when the story is done.

INVEST is a quality checklist for backlog items: Independent, Negotiable, Valuable, Estimable, Small, Testable.

The Definition of Ready is an optional team agreement describing when an item is ready for Sprint Planning; it is not prescribed by the Scrum Guide.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product; it applies to every backlog item.

Estimation commonly uses relative story points and Planning Poker; velocity (points completed per Sprint) supports forecasting but is not a performance target.

The Product Goal is a long-term objective for the Scrum Team recorded in the Product Backlog; it provides focus and is replaced when achieved or abandoned.

The Stacey matrix places work by agreement on what (requirements) and how (technology): close to agreement is simple or complicated, far from agreement is complex or chaotic; Scrum suits the complex zone.

Cynefin distinguishes clear, complicated, complex, and chaotic domains; in the complex domain cause and effect are only visible in retrospect, so probe-sense-respond applies.

In complex work the plan is emergent: the Product Backlog is reordered as learning occurs, and the Sprint Goal gives short-term stability within that change.

The cone of uncertainty narrows estimates as a project progresses; early forecasts carry wide ranges and should be expressed as such.

Empirical forecasting uses past velocity and backlog size to project dates or scope; it is a forecast, not a commitment, and should be re-run as data changes.

Dependencies and risks are made visible on the backlog (for example as risk items or spikes) and addressed by ordering, splitting, or a timeboxed investigation.

Splitting large items (epics) into smaller stories reduces uncertainty and improves flow; vertical slicing delivers a thin end-to-end increment rather than a technical layer.

Scrum does not eliminate documentation or contracts; it favors just enough documentation and collaborative contracting that accommodates change.

Value is the outcome delivered to the customer or organization, not the number of features or story points produced; the PO maximizes value, not output.

The value formula in practice: prioritize items with the highest value relative to cost and risk; cost of delay divided by duration is a common ranking heuristic.

The Kano model classifies features as must-be, performance, attractive, indifferent, and reverse; must-be features prevent dissatisfaction but do not create delight.

MoSCoW prioritization labels scope as Must have, Should have, Could have, and Won't have this time; Must items must all be delivered for the iteration to succeed.

The Minimum Viable Product is the smallest version that allows validated learning from real users; it is a learning instrument, not a low-quality release.

Early and frequent releases generate feedback and revenue sooner; releasing every Sprint is enabled by a strong Definition of Done and automation.

Return on investment and total cost of ownership inform ordering: a cheap high-value item outranks an expensive high-value item when capacity is limited.

Value is validated by evidence such as usage metrics, customer feedback, and Sprint Review outcomes; unvalidated assumptions remain hypotheses on the backlog.