PSM I Product Value and Stakeholders: Maximizing Value with Customers

Product value in Scrum is the benefit a product creates for the people and organization it serves, shown by what changes for them when they use it. The 2020 Scrum Guide makes the Product Owner accountable for maximizing the value of the product that results from the Scrum Team's work, and it deliberately does not say how: practices differ widely across teams, products and organizations.

Three ideas from the Guide shape how value is handled:

• Scrum exists to deliver value. Every Sprint produces at least one useful Increment, and the Product Goal describes the future state of the product the team is working toward.
• Value is discovered empirically. Scrum rests on transparency, inspection and adaptation, so what customers value is learned from experience rather than settled in advance.
• The Product Owner decides, visibly. The Product Owner's value decisions show in the content and order of the Product Backlog and in the usable Increment inspected at the Sprint Review, and the whole organization must respect them.

Value is not the same as doing more work. A team can finish many items quickly and still deliver little value if the items do not change anything for users. The next section makes that distinction precise.

Value is evidenced by outcomes (what customers and users achieve, and how the organization benefits), not by output (how much work the team produces). Output measures can rise while value stays flat, so they are weak evidence on their own.

A few consequences follow:

• Velocity is not a value measure. The Scrum Guide does not mention velocity at all. Some teams use their own past throughput to forecast, but treating it as a target tends to inflate estimates rather than improve the product. Any count of completed work, in whatever unit, is still output.
• Done is a quality standard, not proof of value. An item that meets the Definition of Done is usable, but whether it helps anyone is learned only from real use.
• Opinion is not evidence of use. Feedback from people who watch a demonstration is valuable input, but it does not show what users actually achieve with the product in their own work.
• Attention is not a result. Downloads, sign-ups or clicks show that people noticed something; the outcome is the change the product was meant to produce for them.

Part of the Scrum Master's service to the organization is helping managers and stakeholders understand an empirical approach, which includes moving from output-based judgements to measuring outcomes.

Evidence-Based Management (EBM) is Scrum.org's framework for measuring and improving value, and it groups evidence into four key value areas. It is not part of the Scrum Guide, but it is the vocabulary of the Product Value focus area.

The first two describe market value (value now and value still to capture). The last two describe the organization's capability to deliver value. Individual measures such as lead time or customer satisfaction sit inside an area; they are not areas themselves.

Read the areas together, because they can move in opposite directions. Strong Current Value says nothing about how quickly the organization can learn: if ideas take longer and longer to reach users, Time to Market is worsening, and the real cost is slower validation and later adaptation. Growing technical debt that pulls capacity into maintenance lowers Ability to Innovate even while today's users are content. And a product that serves its current users well but leaves large groups of potential customers unserved shows high Unrealized Value: an opportunity, not a fault in Current Value.

EBM also encourages teams to set goals at several levels (a long-term strategic goal, intermediate goals, and immediate tactical goals such as a Sprint Goal) and to treat progress toward them as a series of experiments, which links directly to the hypothesis-driven approach later in this lesson.

What counts as value depends on who the product serves and what the organization is trying to achieve; revenue is only one possibility. EBM notes that organizations define value differently:

• Commercial products: value often shows in revenue, retention and customer satisfaction.
• Public-sector services: value shows in outcomes for citizens and the agency, for example how quickly people get a decision or how many no longer need to visit an office. A service that earns no revenue can still be highly valuable.
• Non-profits and charities: value is measured against the mission, that is, what changes for the people or cause the organization exists to serve.
• Internal products: the users are employees, and value shows in what the product does for their work, such as time saved, fewer errors or faster service to their own customers.

In every case the same rule applies: pick measures of the result the product exists to produce. Cost alone, feature counts or hours spent do not show value in any of these settings, and having no external customers does not make value unmeasurable.

A stakeholder is a person outside the Scrum Team with a specific interest in and knowledge of the product, whose input the team needs for incremental discovery. Scrum.org's glossary describes stakeholders this way, and the Scrum Guide says a product has known stakeholders and well-defined users or customers.

Stakeholders typically include:

• Customers: the people or organizations who buy the product or decide to adopt it.
• Users: the people who actually work with the product.
• Business functions with an interest in it, such as sponsors, support, sales, compliance, operations and management.

The Product Owner, Scrum Master and Developers are members of the Scrum Team, so they are not its stakeholders. Being a stakeholder also carries no formal power in Scrum: stakeholders do not approve Increments, set the team's priorities or accept its work. Their influence comes from the information and feedback they provide.

Customers and users are often different groups, especially in business-to-business products. A school district may buy a learning platform that teachers and students use every day: the district is the customer, the teachers and students are users, and all are stakeholders. Their views can diverge. A satisfied buyer is not proof of value if the people meant to use the product avoid it; that gap is evidence the Product Owner needs to investigate with the users themselves.

The Product Owner is one person, not a committee, who may represent the needs of many stakeholders in a single Product Backlog. Anyone who wants the Product Backlog changed does so by trying to convince the Product Owner. For the Product Owner to succeed, the whole organization must respect their decisions.

Representing many stakeholders means weighing competing requests against the Product Goal and the evidence of value, then deciding and making the decision visible. That decision belongs to the Product Owner; it cannot be handed to a formula, to the team or to someone higher up without losing the single point of accountability Scrum relies on. A good ordering is also stable enough to plan around: it changes when evidence or circumstances change, not in response to whoever applied pressure last, otherwise neither the Developers nor the stakeholders can rely on it.

The Scrum Master helps by serving the Product Owner (for example with techniques for Product Goal definition and Product Backlog management, and by facilitating stakeholder collaboration as requested or needed) and by serving the organization, for example by removing barriers between stakeholders and Scrum Teams and helping stakeholders understand an empirical approach, which includes why the Product Owner's decisions must be respected. The Scrum Master coaches; the Scrum Master does not order the Product Backlog for the Product Owner.

Making value decisions transparent

The Product Owner's decisions are visible in the content and ordering of the Product Backlog, and the Product Owner is accountable for ensuring it is transparent, visible and understood. That transparency is how stakeholders learn where their requests stand and why.

• The Product Backlog is the one place that orders future work. Its order is the best available signal of what is likely to be worked on sooner or later; other artifacts and records describe the current Sprint, quality or team improvement, not product priorities.
• An openly visible backlog is self-service. Stakeholders can check what has been captured and where it sits for themselves, which keeps the Developers focused.
• Transparency includes the reasoning. When a stakeholder questions the order, the Product Owner explains the value reasoning and stays open to new evidence. Asserting authority without explanation is accountable but not transparent, and changing the order just to appease someone is transparent but no longer a value decision.

Detailed Product Backlog techniques (refinement, sizing, ordering methods) are covered in the Product Backlog management lesson; the point here is that an open backlog is the main tool for stakeholder trust.

The Sprint Review is the Scrum event built for stakeholder collaboration. Its purpose is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents its results to key stakeholders and progress toward the Product Goal is discussed. Together they review what was accomplished in the Sprint and what has changed in their environment, and based on that the attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.

The Sprint Review is a working session, not a presentation, and it is not a gate: stakeholders do not approve each item before release. Requests raised there are input to the Product Owner, who weighs them against everything else in the Product Backlog and decides what, if anything, changes in the order.

Events are regular opportunities, not limits. A stakeholder can bring a new idea to the Product Owner at any time; the Product Backlog is emergent and the Product Owner can add or reorder items whenever that adds value. When stakeholder input starts arriving through an event that has a different purpose, the Scrum Master's job is twofold: keep the event serving its purpose, and make sure the input still reaches the Product Owner, because the feedback itself is valuable.

Stakeholders therefore influence what the team builds next through collaboration with the Product Owner and participation in the Sprint Review. The Sprint Backlog belongs to the Developers and the ordering of the Product Backlog to the Product Owner, so influence works through conversation and evidence, not by directing the team's work.

Sprint Planning is mainly a Scrum Team event, but the Scrum Guide says the team may invite other people to attend to provide advice. Inviting a domain expert directly is often the fastest way to get the knowledge a Sprint depends on. The advice improves the plan; it transfers no decision. The whole Scrum Team still defines the Sprint Goal, and the Developers still select the work and plan how to do it.

The first Sprint Planning topic is why this Sprint is valuable. The Product Owner proposes how the product could increase its value and utility in the Sprint, and the whole Scrum Team collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. That makes the Sprint Goal the natural answer whenever someone outside the team asks what a Sprint will achieve for them.

The Sprint Goal is a single objective. It also gives the Developers flexibility in the exact work needed to achieve it: if the work turns out different than expected, they negotiate the scope of the Sprint Backlog with the Product Owner without abandoning the goal. Both purposes depend on the goal being stated as an objective. A goal that merely lists work items communicates no value to stakeholders and removes the flexibility, because every listed item becomes the goal itself.

Yes. The Scrum Guide sets no rule against Developers talking directly to users and stakeholders, and doing so shortens feedback loops. Routing every question through the Product Owner or the Scrum Master is folk Scrum: it is workable, but slower, and it was never a requirement. Limiting contact to Sprint Reviews is equally unfounded.

What direct contact does not change is accountability for the Product Backlog. The Product Owner remains accountable for its content and order even when others do the work. A simple way to apply this:

• Clarifying existing work is part of the Developers' job; they can go to the source and keep the Product Owner informed.
• New ideas and changed priorities are Product Backlog decisions, so they go to the Product Owner, who decides if and where they belong.
• Evidence about value that Developers gather is an asset for everyone. Sharing it openly with the Product Owner is how it changes the order; acting on it unilaterally, or ignoring it, wastes it.

Releasing usable Increments to users early and often maximizes value because feedback from real use tells the Product Owner what to build next. Scrum's empiricism holds that knowledge comes from experience, so until users have a feature, its value is an assumption, however confident the stakeholders or however carefully it was sized.

Some facts to keep straight:

• The Scrum Guide requires a Done, usable Increment every Sprint and allows an Increment to be delivered to stakeholders before the Sprint ends. It does not require a release to users every Sprint; whether to release is a business decision.
• The longer a product waits to reach users, the longer its assumptions about value stay untested and the longer users go without value they could already have.
• Internal demonstrations produce useful feedback, but only real use produces evidence of what users achieve.

A hypothesis-driven approach makes this deliberate:

1. State the expected outcome before building (for example, a simpler sign-up form should raise the share of visitors who finish registering).
2. Release the smallest version that can test it.
3. Measure the outcome the change targets, not only activity around it.
4. Adapt: let the result change the Product Backlog, whether that means continuing, changing direction or dropping related items.

Release planning and forecasting techniques themselves are covered in the forecasting and release planning lesson.