The Professional Scrum Master level III (PSM III) (PSM-III)

The Cone of Uncertainty describes how the level of uncertainty in a product’s requirements, technology, and value is highest at the beginning of a product’s lifetime and gradually decreases as knowledge is gained. This concept strongly influences the type of work a development team performs throughout the product’s development lifecycle and aligns well with Scrum’s empirical approach.

Early Stage: High Uncertainty and Discovery Work

At the start of a product’s development lifetime, many unknowns exist. These may relate to customer needs, technical feasibility, usability, or business value. According to Scrum’s empirical nature, teams should not assume certainty where it does not exist. Therefore, early development work focuses primarily on discovery .

During this stage, the Development Team works to reduce uncertainty by:

Conducting research and experiments,

Building prototypes or spikes,

Testing assumptions with users,

Validating technical and business hypotheses.

This type of work helps the team learn quickly and avoid premature commitment to detailed solutions. The goal is not maximizing feature output, but maximizing learning and reducing risk.

Middle Stage: Reduced Uncertainty and Feature Development

As important unknowns are discovered and addressed, the Cone of Uncertainty narrows. The team gains confidence in what to build and how to build it. At this point, work increasingly shifts toward delivering functional stories and features that provide direct value to users.

Development during this phase focuses on:

Building usable, integrated product increments,

Expanding functionality based on validated learning,

Refining features through feedback and inspection.

Scrum supports this transition by enabling frequent inspection and adaptation through Sprints, ensuring that learning continues while value delivery accelerates.

Late Stage: Low Uncertainty and Operational Work

Toward the end of a product’s development lifetime, most significant uncertainties have been resolved. According to Evidence-Based Management (EBM) , Unrealized Value becomes low , while Current Value is high . At this stage, the volume of new feature development typically decreases.

The team’s work becomes more operational in nature, such as:

Maintenance and optimization,

Improving performance or stability,

Addressing technical debt,

Supporting existing users.

Investment decisions increasingly focus on sustaining value rather than discovering new opportunities.

In Scrum, team structure significantly impacts the ability to deliver value. Two commonly discussed structures are component teams and feature teams . Although the Scrum Guide does not explicitly define these terms, it strongly favors the characteristics of feature teams through its definition of a Scrum Team.

Component teams are organized around technical specialties or system components, such as database, frontend, or middleware teams. Their work typically represents partial contributions to a product feature, requiring coordination and handoffs across multiple teams to deliver customer value. As a result, component teams often introduce dependencies, delay integration, and struggle to produce a usable Increment independently within a Sprint.

Feature teams , in contrast, are organized around delivering complete product features or Product Backlog Items. They are cross-functional and possess all the skills required to design, build, test, and deliver a “Done” Increment of value. Feature teams minimize dependencies and can independently deliver customer-facing functionality each Sprint.

From the Scrum Guide perspective , feature teams align more closely with Scrum principles:

The Scrum Guide states that Scrum Teams are cross-functional , which directly supports feature teams and challenges component team structures.

Scrum requires each Sprint to produce a usable Increment . Feature teams can meet this expectation, while component teams usually cannot without reliance on other teams.

Scrum is based on empiricism (transparency, inspection, and adaptation). Reduced dependencies in feature teams improve transparency and enable faster inspection and adaptation.

Scrum emphasizes value delivery and accountability . Feature teams maintain clear ownership of outcomes, whereas component teams fragment accountability across technical silos.

While component teams may exist due to legacy structures or technical constraints, they represent organizational impediments rather than an ideal Scrum implementation. From a Professional Scrum Master III perspective, moving toward feature teams supports agility, improves value delivery, and better enables Scrum as defined in the Scrum Guide.

Ordering the Product Backlog is a key accountability of the Product Owner and is essential for maximizing value through empiricism. The ordering reflects continuous inspection of multiple variables, not a single prioritization rule.

1. Value and Outcomes

The primary variable is value . The Product Owner considers:

Customer and user value,

Business impact and outcomes,

Alignment with the Product Goal .

Items that deliver higher or more urgent value are generally ordered higher.

2. Risk and Uncertainty

Items that reduce risk or uncertainty are often ordered earlier. This includes:

Technical risk,

Market or usability risk,

Integration or dependency risk.

Early learning enables better decisions and reduces long-term cost.

3. Dependencies

The Product Owner considers dependencies between backlog items and teams. Items that unblock other work or reduce dependencies may be ordered higher to improve flow and reduce coordination overhead.

4. Effort, Complexity, and Feasibility

While Developers estimate effort, the Product Owner uses this information to balance value against cost, complexity, and feasibility . High-value items that are feasible within near-term constraints are often prioritized.

5. Feedback and Learning

Ordering reflects feedback from Sprint Reviews , user testing, and market response. Items may move up or down based on what has been learned from previous Increments.

6. Time Sensitivity and Opportunity Cost

Some items are time-critical due to:

Regulatory deadlines,

Market windows,

Competitive pressure.

Delaying such items may reduce or eliminate their value.

Technical systems are often decomposed into smaller elements such as activities, workflows, functions, features, or components to manage complexity. While decomposition is necessary for understanding and building large systems, it has significant implications for Scrum Teams , especially in scaled environments .

1. Risk of Component-Centric Team Structures

When system decomposition drives team structure, organizations often create component or specialist teams aligned to technical layers or functions. In scaled Scrum, this increases:

Dependencies between teams ,

Coordination overhead,

Integration risk.

Such structures make it difficult for teams to deliver end-to-end, integrated Increments each Sprint, weakening empiricism and delaying feedback.

2. Impact on Value Delivery and Inspection

Scrum relies on frequent inspection of working product Increments . If work is decomposed into narrowly defined technical components, individual teams may only deliver partial outputs rather than usable value. This reduces transparency and makes meaningful inspection at the product level harder, especially when multiple teams are involved.

3. Preference for Feature-Oriented Decomposition

Scrum favors decomposing work into vertical, value-oriented slices (features or capabilities) rather than horizontal technical layers. This allows each Scrum Team to be:

Cross-functional ,

Capable of delivering usable Increments independently,

Less dependent on other teams.

In scaled projects, feature-oriented decomposition reduces dependencies and improves flow.

4. Effects on Integration and Empiricism

Poor decomposition increases the cost of integration and often leads to late or infrequent integration. Scrum requires that integration happens early and often , as unintegrated work is not “Done.” In scaled Scrum, decomposition choices directly influence whether integration is continuous or deferred, with major implications for risk control.

5. Organizational and Learning Implications

System decomposition also affects learning and adaptability. When teams own complete features rather than isolated components, they gain a better understanding of:

Customer needs,

System behavior,

Trade-offs across the product.

This broader understanding improves decision-making and supports continuous improvement across the system.

From a Scrum Master’s perspective, replacing the Daily Scrum with a weekly update meeting is not consistent with Scrum and would significantly weaken the team’s ability to inspect and adapt effectively, regardless of the Sprint length.

First, Scrum explicitly defines the Daily Scrum as a required event . The Scrum Guide states that the Daily Scrum is a 15-minute event held every working day of the Sprint for the Developers. The length of the Sprint—whether one week or one month—does not change the purpose or necessity of this event. Therefore, by choosing not to have a Daily Scrum, the team would no longer be practicing Scrum , but rather a Scrum-like process.

Second, the Daily Scrum is not a status meeting . Its primary purpose is to allow the Developers to inspect progress toward the Sprint Goal , synchronize their work, and adapt the Sprint Backlog as needed. A weekly meeting dramatically reduces the frequency of inspection and adaptation, delaying the discovery of issues such as integration problems, misalignment, or risks to the Sprint Goal.

Third, removing the Daily Scrum negatively impacts transparency , one of Scrum’s three pillars of empiricism. Without daily synchronization, important information about progress, impediments, and discoveries becomes stale or hidden. This reduced transparency increases the likelihood that work will drift away from agreed standards, fail to integrate properly, or no longer support the Sprint Goal by the end of the Sprint.

Fourth, the argument that a one-month Sprint justifies less frequent inspection reflects a misunderstanding of empiricism. Longer Sprints increase risk , which makes frequent inspection and adaptation more important, not less. The Daily Scrum provides a regular opportunity to realign the team and respond early to emerging problems, thereby reducing waste and rework.

Finally, as a Scrum Master, my role is to teach and coach the Scrum Team on the purpose and value of Scrum events. Rather than removing the Daily Scrum, I would help the Developers improve how they use it—for example, ensuring it focuses on progress toward the Sprint Goal and actionable planning for the next 24 hours, instead of turning into a reporting session.

A key way a Product Owner applies validated learning is by adapting the Product Backlog and Product Goal based on evidence from real outcomes , not assumptions.

Through inspection of:

The Product Increment during the Sprint Review,

Stakeholder and user feedback,

Measured outcomes such as usage, value, or risk reduction,

the Product Owner assesses whether assumptions about value, users, or direction are valid. This learning becomes validated only when it is reflected in changed decisions , such as:

Reordering Product Backlog items,

Adding or removing backlog items,

Adjusting or even abandoning a Product Goal.

In other words, validated learning is applied when the Product Owner uses results to change what is built next , ensuring that future work is based on evidence rather than speculation.

From a Scrum Master’s perspective, this situation must be approached by balancing respect for Scrum accountabilities , protection of empiricism , and long-term value delivery , rather than reacting solely to short-term urgency.

First, it is important to reaffirm that the Development Team owns the Sprint Backlog . According to the Scrum Guide, once the Sprint has started, changes to the Sprint Backlog are negotiated only between the Product Owner and the Development Team , and the Development Team has the final say on whether additional work can be taken on. Therefore, the Product Owner cannot unilaterally force the urgent item into the Sprint, even if it represents the highest customer priority. If the Development Team believes it can incorporate the item without jeopardizing the Sprint Goal, it may choose to do so—but this remains their decision.

Second, the Scrum Master should help the Product Owner understand that not all priorities are equal within a Sprint . The Sprint Goal provides focus and stability, and work that is not related to the Sprint Goal introduces risk. While satisfying the customer is important, Scrum explicitly values sustainable improvement and learning . The process improvement goal agreed upon during the Sprint Retrospective represents a deliberate investment in the team’s effectiveness. Sacrificing this improvement for short-term delivery may create a local optimization that harms long-term customer value .

Third, the Scrum Master should coach both the Product Owner and the Development Team on the systemic impact of slowing process improvements . Continuous improvement is a core expectation of Scrum, and the Scrum Guide states that the Scrum Team should plan ways to increase quality and effectiveness. When improvement goals are repeatedly deprioritized, delivery predictability, quality, and morale eventually decline—directly affecting customers. Therefore, the Product Owner’s argument that customer needs always outweigh improvement work reflects a short-term mindset that the Scrum Master should challenge through education and coaching.

Fourth, this situation should be inspected during the Sprint Retrospective . The team should reflect on why urgent, unplanned work appears late in the Sprint, whether it represents a recurring pattern , and how this impacts Sprint Goals and improvement commitments. The Scrum Master should facilitate this discussion to ensure transparency and learning, rather than blame.

Finally, if this behavior becomes a pattern, the Scrum Master must take a more active stance. This includes teaching and reminding the Scrum Team that at least one improvement from the Sprint Retrospective should be planned into the upcoming Sprint . This protects the intent of the Retrospective and ensures that improvement is not treated as optional or expendable work.

Scrum is fundamentally based on Empiricism , also referred to as Empirical Process Control . This means that Scrum recognizes that complex work, such as software development, cannot be fully understood or predicted upfront. Instead, decisions are made based on experience, observation, and evidence , forming a continuous closed feedback loop .

Empirical Process Control rests on three pillars: Transparency, Inspection, and Adaptation . Scrum provides a structured framework of roles, events, and artifacts that explicitly support and reinforce each of these pillars.

Transparency

Transparency ensures that all significant aspects of the process and product are visible to those responsible for the outcome. In Scrum, transparency is created through clearly defined artifacts such as the Product Backlog, Sprint Backlog, and Product Increment , each governed by a shared Definition of Done. Scrum Events further enhance transparency by creating regular opportunities to share progress, challenges, and current state. Without transparency, inspection would be misleading and ineffective.

Inspection

Scrum prescribes frequent and regular inspection of both the product and the process. Each Scrum Event serves as an inspection point:

The Daily Scrum inspects progress toward the Sprint Goal,

The Sprint Review inspects the Increment and adapts the Product Backlog,

The Sprint Retrospective inspects the team’s ways of working.

These inspections are intentionally timeboxed and lightweight to avoid excessive overhead while still enabling timely feedback.

Adaptation

Inspection is meaningful only if it leads to adaptation . Scrum explicitly enables adaptation by allowing changes to plans, processes, and backlog content based on what is learned. The Sprint Backlog may be adapted during the Sprint, the Product Backlog is adapted after the Sprint Review, and team practices are adapted following the Sprint Retrospective.

Closed Feedback Loop

Together, transparency, inspection, and adaptation form a closed feedback loop . Scrum’s short iterations (Sprints) ensure that learning occurs frequently, enabling the Scrum Team and stakeholders to respond quickly to change, reduce risk, and improve outcomes over time.

When a Development Team is distributed across different physical locations and faces logistical overhead just to start the Daily Scrum , this situation represents an impediment to effective inspection and adaptation . As a Scrum Master, the appropriate action is to enable the team to inspect and adapt more effectively , not to control or manage logistics on their behalf.

1. Help the Team Establish a Stable and Simple Daily Scrum Setup

The Scrum Master should work with the Development Team to inspect and improve how the Daily Scrum is conducted . This may include:

Agreeing on a fixed time and virtual location ,

Standardizing tools (e.g., always the same conferencing solution),

Reducing setup effort so the event can start on time and remain within its 15-minute timebox.

This supports transparency and reduces unnecessary waste.

2. Remove or Reduce Organizational and Technical Impediments

If logistical difficulties stem from organizational constraints—such as lack of proper tooling, inadequate rooms, or unreliable communication infrastructure—the Scrum Master should address these as impediments . This may involve working with IT or management to provide stable tools that enable smooth collaboration.

3. Coach the Team Toward Self-Management

Rather than running the Daily Scrum or handling logistics personally, the Scrum Master should coach the Developers to self-manage how they organize the event. The goal is for the team to own and continuously improve the Daily Scrum in a way that fits their distributed context.