Scrum Theory, Accountabilities and Team Design

Introduction

Scrum is a lightweight framework for developing, delivering and sustaining complex products. It is not a project-management methodology with a complete sequence of prescribed activities. Rather, Scrum establishes a small set of accountabilities, events, artefacts and rules within which a product team can learn through action and adjust its work.

For product managers, Scrum is important because product development involves uncertainty. Customer needs change, technology may behave unpredictably, competitors respond, and early assumptions are often wrong. A plan prepared at the beginning of a long initiative cannot reliably specify every valuable outcome. Scrum addresses this condition through empiricism: knowledge is built from experience and decisions are based on what is observed.

The Scrum framework rests on three formal pillars—transparency, inspection and adaptation—and is supported by five values: commitment, focus, openness, respect and courage. Its effectiveness also depends on team design. A Scrum Team must contain the capabilities needed to create a usable product increment and must have sufficient authority to make day-to-day decisions about its work.

This chapter examines Scrum theory, the accountabilities of the Product Owner, Scrum Master and Developers, and the design of empowered, cross-functional and self-managing teams. It also evaluates common implementation failures and considers how product leaders can create the organisational conditions in which Scrum can work.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain empiricism and its pillars of transparency, inspection and adaptation.
2. Distinguish Scrum accountabilities from job titles and organisational positions.
3. Evaluate the responsibilities of the Product Owner, Scrum Master and Developers.
4. Design a cross-functional, focused and appropriately sized Scrum Team.
5. Diagnose dysfunctions involving authority, dependencies, quality and team boundaries.
6. Apply Scrum principles to a realistic product-development situation.
7. Critically assess the limitations and organisational prerequisites of Scrum.

1. Scrum as an Empirical Framework

1.1 Complexity and uncertainty

A complex product-development problem is one in which the relationship between an action and its result cannot be predicted with confidence. A product team may know the customer problem but not which solution will work. It may understand the desired outcome but not the technical effort required. Consequently, the team benefits from short learning cycles rather than relying exclusively on long-range prediction.

Scrum responds by creating a repeating pattern:

make work visible → inspect evidence → adapt the product or the way of working → repeat

The purpose of this pattern is not simply to increase delivery speed. It is to improve the probability that the team will deliver something useful, usable and aligned with a valuable product direction.

1.2 The three pillars

Transparency means that important aspects of the process must be visible to those responsible for its outcome. In Scrum, the Product Backlog, Sprint Backlog and Increment provide important forms of transparency. Transparency also includes shared definitions: for example, everyone should understand what it means for work to be complete.

Inspection means that Scrum participants regularly examine Scrum artefacts and progress toward a goal. Inspection should occur often enough to detect undesirable variance but not so frequently that it becomes disruptive surveillance. The Sprint Review inspects the product and its direction; the Daily Scrum supports inspection of progress toward the Sprint Goal; the Retrospective inspects the team’s way of working.

Adaptation means changing the product, plan or process when inspection indicates that the current approach is no longer appropriate. Adaptation is not failure. In an uncertain environment, refusal to adapt is often a greater risk than changing direction. Adaptation must nevertheless be disciplined: it should respond to evidence, preserve valuable commitments where possible and remain consistent with the product goal.

These pillars are interdependent. Work that is not transparent cannot be meaningfully inspected; inspection without authority or willingness to adapt produces ritual rather than learning.

1.3 Scrum values

The five Scrum values describe behavioural conditions that make empiricism possible:

Values are not slogans. For example, a team cannot claim openness while concealing quality problems, nor claim respect while allowing a manager to dictate every technical decision to Developers.

2. Scrum Elements and Their Relationships

Scrum defines three accountabilities, five events and three artefacts. The elements form a coherent system rather than a menu from which an organisation may select convenient practices.

The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team’s effectiveness. The Developers are the people in the Scrum Team who are committed to creating any usable Increment each Sprint.

The events create regular opportunities for inspection and adaptation:

• The Sprint is the container for all other events and lasts one month or less.
• Sprint Planning establishes why the Sprint is valuable, what can be done and how the chosen work will be completed.
• The Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt their plan.
• The Sprint Review inspects the outcome of the Sprint with stakeholders and considers future adaptations.
• The Sprint Retrospective identifies improvements to quality and effectiveness.

The artefacts and their commitments are:

The Product Backlog is not merely a requirements document. It is an evolving product-management instrument. Items may be refined, reordered, split, clarified or removed as more is learned. Product Backlog refinement is an ongoing activity, not a formal Scrum event.

The Sprint Goal provides a coherent objective for the Sprint. It gives Developers flexibility in the exact work selected while preserving a shared purpose. The Definition of Done establishes the quality state required for work to be considered part of the Increment. It is a formal description of the state of the Increment when it meets the quality measures required for the product.

3. Scrum Accountabilities

3.1 The Product Owner

The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team. This accountability includes effective Product Backlog management, which involves:

• developing and explicitly communicating the Product Goal;
• creating and clearly communicating Product Backlog Items;
• ordering Product Backlog Items; and
• ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may perform this work personally or delegate aspects of it to others, but accountability remains with the Product Owner. Delegation is not abdication.

#### Product value and ordering

Ordering is not identical to ranking items by revenue. A Product Owner may consider customer value, risk reduction, learning value, regulatory urgency, technical dependencies, operational resilience and strategic fit. The key requirement is that the ordering expresses a reasoned view of what should be addressed next.

A Product Owner needs access to evidence and stakeholders but should not become a committee. When multiple executives collectively control the backlog, priorities can become contradictory and slow. The Product Owner needs a clear mandate to make product decisions, while remaining accountable to the wider organisation for outcomes.

#### Product Goal

The Product Goal describes a future state of the product that serves as a target for the Scrum Team. It gives coherence to individual Sprints and helps prevent a backlog from becoming an unconnected list of requests. A Product Owner should be able to explain:

• the user or organisational problem being addressed;
• the target users or customers;
• the expected product outcome;
• the principal assumptions and risks; and
• how progress toward the goal will be evaluated.

A Product Goal is not necessarily a fixed feature list. It should remain sufficiently stable to guide learning while allowing the solution to evolve.

#### What the Product Owner is not

The Product Owner is not simply a requirements secretary, a proxy for every stakeholder, or the sole author of all backlog text. Nor is the Product Owner the manager of Developers. Product management includes strategic discovery, positioning, customer understanding and outcome accountability; Scrum specifies the Product Owner accountability but does not define an organisation’s entire product-management profession.

3.2 The Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team’s effectiveness. The Scrum Master is a true leader who serves the team and the organisation.

Service to the Scrum Team includes:

• coaching team members in self-management and cross-functionality;
• helping the team focus on creating high-value Increments that meet the Definition of Done;
• facilitating stakeholder collaboration when useful; and
• helping remove impediments to the team’s progress.

Service to the Product Owner includes helping establish effective Product Goals and Product Backlog management, supporting empirical planning and facilitating stakeholder collaboration.

Service to the organisation includes leading, training and coaching the organisation in Scrum adoption; planning and advising on implementation; helping employees and stakeholders understand empirical approaches; and removing barriers between stakeholders and Scrum Teams.

The Scrum Master does not function as a task dispatcher or administrative coordinator. Facilitation does not mean taking responsibility away from the people who own the decisions. A Scrum Master may facilitate an event, but Developers remain responsible for their plan and the Product Owner remains accountable for product value.

3.3 The Developers

Developers are the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. The term includes all specialist skills required to create the product Increment; it does not mean only software programmers.

Developers are accountable for:

• creating a plan for the Sprint, the Sprint Backlog;
• instilling quality by adhering to the Definition of Done;
• adapting their plan every day toward the Sprint Goal; and
• holding one another accountable as professionals.

Developers decide how selected work will be transformed into an Increment. This does not eliminate collaboration with the Product Owner or Scrum Master. It does mean that detailed technical and execution decisions should not be imposed by an external project manager who lacks the relevant context.

The Developers’ commitment is to the Sprint Goal and quality, not to producing a maximum number of tasks. A Sprint may finish with fewer selected items than initially expected while still succeeding if the Sprint Goal is achieved. Conversely, completing many items that do not meet the Definition of Done is not successful delivery.

4. Team Design: Empowerment, Cross-Functionality and Self-Management

4.1 One Scrum Team

A Scrum Team consists of one Scrum Master, one Product Owner and Developers. It has no sub-teams or hierarchies. The team is a cohesive unit of professionals focused on one Product Goal at a time.

The Scrum Guide recommends a Scrum Team small enough to remain nimble and large enough to complete significant work within a Sprint. A useful rule is 10 or fewer people in the Scrum Team, including the Product Owner and Scrum Master. If a team becomes too large, the organisation should consider reorganising into multiple cohesive Scrum Teams working on the same product, with the same Product Goal, Product Backlog and Product Owner. Simply splitting a department into separate functional groups does not create multiple effective Scrum Teams.

4.2 Cross-functionality

A cross-functional team has all the skills necessary to create value during a Sprint. Cross-functionality does not require every person to possess every skill. It means the team collectively contains the capabilities needed to produce a usable Increment without depending routinely on an external department.

For a digital product, capabilities may include product discovery, interaction design, software engineering, data analysis, security, quality assurance, accessibility, operations and domain expertise. For a physical or regulated product, they may include industrial design, engineering, compliance, manufacturing, testing and supply-chain expertise.

Cross-functionality reduces handoffs and waiting time, but it can create challenges. Specialists may fear loss of professional identity; some skills may be scarce; and teams may become overloaded with too many responsibilities. Team design should therefore distinguish between capabilities that must be continuously available and capabilities that can be accessed periodically through a genuine collaboration model.

4.3 Self-management

A self-managing team decides internally who does what, when and how. Self-management is not the absence of leadership, standards or accountability. The team remains accountable for quality and Sprint commitments, while the Product Owner remains accountable for product value and the Scrum Master for Scrum effectiveness.

Self-management requires decision rights. A team cannot be self-managing if a manager approves every technical choice, reassigns work daily or overrides the Sprint Goal without an explicit organisational decision. Leaders should define boundaries—such as regulatory controls, architecture principles, budgets and strategic objectives—then allow the team discretion within those boundaries.

4.4 Team topology and dependencies

Team design should minimise dependencies that prevent a team from creating a usable Increment. Common dependency types include:

• skill dependency: a required specialist belongs to another department;
• component dependency: several teams must modify the same system component;
• approval dependency: progress waits for an external manager or committee;
• environment dependency: testing or deployment requires a separate operations group; and
• customer-access dependency: the team cannot directly learn from users.

Dependencies are not automatically defects. Some are unavoidable in large, regulated or safety-critical environments. However, each dependency should be made visible and managed deliberately. Excessive dependencies weaken the empirical loop because the team cannot inspect a complete outcome within the Sprint.

5. Applying Empiricism in Product Management

Empiricism is strengthened when teams connect activities to evidence. A Product Owner can make assumptions explicit and order work that tests the most consequential uncertainties. Developers can use technical spikes, prototypes, automated tests and operational experiments to generate evidence. Stakeholders can inspect a working Increment rather than relying solely on status reports.

A useful distinction is between output, outcome and impact:

• An output is something produced, such as a feature or release.
• An outcome is a change in user behaviour or experience, such as reduced abandonment.
• Impact is the broader organisational or customer consequence, such as increased retention or reduced service cost.

Scrum directly produces Increments, but product leadership should connect those Increments to outcomes and impact. A completed Sprint does not prove that the product is valuable. It creates an opportunity to learn whether the product is becoming more valuable.

Evidence-informed ordering

Suppose a Product Owner is choosing among three backlog items. A disciplined decision may consider:

1. the strength of evidence that the customer problem exists;
2. the expected contribution to the Product Goal;
3. the cost and risk of delay;
4. the learning likely to result; and
5. the feasibility of producing a usable Increment.

This is not a universal numerical formula. It is a decision framework. Organisations should avoid pretending that uncertain estimates are precise measurements. Relative ordering, explicit assumptions and frequent inspection are usually more honest than false precision.

6. Case Study: Rebuilding a University Enrolment Portal

The following is an illustrative case.

Background

A university operates an online enrolment portal. Students report that selecting modules is confusing, the system becomes slow during peak registration, and accessibility support is inconsistent. The university initially creates three functional groups: a business-analysis team, a software-development team and a testing team. A programme manager coordinates a six-month feature plan.

Problem

After three months, many requirements have been documented, but no complete student journey is usable. The business analysts wait for decisions from academic departments; Developers wait for test environments; testers receive partially completed work; and the Product Manager is unable to reorder priorities because the programme steering group approves every change. The project reports high task completion but student satisfaction remains poor.

Analysis

The arrangement lacks cross-functionality and creates handoffs. Transparency is weak because a “completed” analysis document is treated as progress even though it cannot be inspected as a product outcome. The team has no shared Sprint Goal and no common Definition of Done. Accountability is also confused: the programme manager assigns tasks, the steering group effectively acts as Product Owner, and no person has clear authority to maximise product value.

Approach

The university establishes one Scrum Team for the enrolment experience, with a Product Owner who has authority to order the Product Backlog. The team includes product discovery, design, engineering, testing, accessibility and platform capabilities. A Scrum Master works with the organisation to remove the environment dependency and coach academic stakeholders in the Sprint Review.

The first Product Goal is: “Enable new undergraduate students to complete module selection accurately and accessibly without administrative intervention.” The Definition of Done includes accessibility checks, security review, automated regression tests, performance criteria and deployment to a representative environment.

The first Sprint Goal is deliberately narrow: “Students can find, compare and select an eligible module through a usable end-to-end journey.” The team interviews students, prototypes the journey, builds a thin vertical slice and tests it with representative users. At the Sprint Review, evidence shows that students understand the selection screen but frequently misinterpret prerequisite information.

The Product Owner reorders the backlog to address the prerequisite problem before adding optional personalisation. Developers adapt the design and technical plan. The Scrum Master raises the continuing approval delay with the university’s leadership and helps establish a delegated decision boundary for routine product changes.

Outcome

The team does not deliver every originally requested feature in the first release. It does, however, establish a usable journey, expose an important usability risk early and reduce the number of handoffs. Later Sprints address performance and accessibility findings using evidence from real users. The university learns that improved team structure, not merely increased effort, was necessary to improve outcomes.

Learning points

1. A backlog controlled by a committee weakens Product Owner accountability.
2. Functional departments can produce substantial activity without producing a usable Increment.
3. A narrow Sprint Goal can create more learning than a large feature commitment.
4. The Definition of Done must include product quality, not only coding completion.
5. Organisational impediments may be more significant than team-level process problems.

7. Common Failure Modes and Critical Limitations

Scrum as a status-reporting ceremony

Daily Scrums sometimes become meetings in which each person reports to a manager. This undermines the event’s purpose. Developers should inspect progress toward the Sprint Goal and adapt their plan; the event is not designed primarily for managerial surveillance.

The Product Owner as a backlog clerk

When the Product Owner merely records stakeholder requests, product strategy is displaced by demand accumulation. Effective Product Ownership requires product understanding, prioritisation authority and willingness to make trade-offs.

The Scrum Master as a project administrator

A Scrum Master who only schedules meetings may leave systemic impediments untouched. The accountability includes coaching, organisational change and improving team effectiveness.

“Done” meaning development complete

If testing, security, accessibility, documentation or deployment are deferred, the Increment may not be genuinely usable. This creates hidden work and weakens transparency.

Velocity as a performance target

Velocity is a local planning measure based on a team’s historical work-sizing convention. It is not a universal productivity unit and is not valid for comparing teams. Turning velocity into a target encourages inflation of estimates and can reduce quality. Outcome measures, cycle-time patterns, quality indicators and customer evidence are generally more useful for management decisions.

Scrum in unsuitable conditions

Scrum is not automatically the best framework for every type of work. Highly repetitive operational work may benefit from flow-based methods; urgent incident response may require different coordination; safety-critical environments may require extensive governance alongside iterative development. Scrum can coexist with regulatory controls, but compliance obligations must be integrated into the Definition of Done, planning and evidence practices rather than treated as an external afterthought.

Scaling without solving basic problems

Adding coordination layers does not solve unclear ownership, poor quality or excessive dependencies. Scaling should follow a demonstrated need for multiple teams working on one product, not precede basic team effectiveness. Shared Product Goals, compatible quality standards, transparent dependencies and coherent product ownership are more important than adopting a branded scaling process.

8. Governance, Ethics and Contemporary Practice

Product teams exercise power over users through choices about data, access, defaults and automation. Empirical delivery does not justify experimenting without ethical safeguards. Teams should consider privacy, accessibility, security, discrimination, explainability and the possibility of harm. A fast learning cycle can accelerate harmful outcomes if the problem definition or success measure is ethically inadequate.

In regulated contexts, the Product Owner and Developers should make compliance work visible in the Product Backlog and Definition of Done. Evidence such as audit trails, validation records and security tests should be produced as part of the Increment where feasible.

Artificial intelligence can support backlog analysis, code assistance, test generation, customer research synthesis and forecasting. However, AI-generated content is not automatically correct, secure or unbiased. Human professionals remain accountable for product decisions, intellectual-property compliance, privacy protection, model evaluation and the quality of the Increment. AI should strengthen inspection and learning, not conceal uncertainty behind confident automated outputs.

Contemporary product teams increasingly combine Scrum with discovery practices, continuous delivery, hypothesis testing, service design and outcome measurement. Such combinations can be useful when they preserve the essential logic of empiricism and do not turn Scrum into an unexamined collection of ceremonies.

Best-Practice Principles

1. Establish one clearly understood Product Goal.
2. Give one Product Owner genuine authority to order the Product Backlog.
3. Keep the Scrum Team small enough for close collaboration and large enough to create a usable Increment.
4. Build cross-functionality around the capabilities required for the product outcome.
5. Define “Done” to include all quality and compliance conditions necessary for release or use.
6. Use Sprint Goals to create focus while allowing Developers to adapt detailed plans.
7. Treat the Sprint Review as a product-inspection and decision-making session, not a ceremonial demonstration.
8. Use Retrospectives to address systemic causes, not merely individual behaviour.
9. Measure outcomes and product quality rather than comparing teams by velocity.
10. Make organisational impediments visible and assign leadership responsibility for addressing them.

Chapter Summary

Scrum is an empirical framework for complex product development. Its three pillars—transparency, inspection and adaptation—enable teams to learn from evidence and respond to uncertainty. The Scrum values provide the behavioural foundation for this learning.

The Product Owner is accountable for maximising product value through effective Product Goal and Product Backlog management. The Scrum Master is accountable for establishing Scrum and improving the Scrum Team’s effectiveness through service, coaching and organisational change. Developers are accountable for creating a usable Increment, planning their Sprint work, maintaining quality and adapting toward the Sprint Goal.

A Scrum Team should be cohesive, cross-functional, empowered and self-managing, with no sub-teams or functional hierarchy. Effective design minimises dependencies and gives the team authority within clear organisational boundaries. Scrum does not guarantee value, eliminate uncertainty or replace product strategy. Its benefits depend on honest transparency, meaningful inspection, real adaptation, appropriate governance and leadership that supports team autonomy.

Key Terms

Empiricism: Decision-making based on observation, experience and evidence.

Transparency: Visibility of important aspects of work and progress.

Inspection: Regular examination of artefacts, progress and outcomes.

Adaptation: Adjustment of a product, plan or process in response to inspection.

Scrum value: A behavioural principle supporting effective Scrum, such as focus or openness.

Product Owner: Accountability responsible for maximising product value.

Scrum Master: Accountability responsible for establishing Scrum and improving team effectiveness.

Developers: Scrum Team members committed to creating a usable Increment.

Product Goal: A future state of the product that serves as a target for the team.

Product Backlog: An ordered and evolving list of what is needed to improve the product.

Sprint Goal: The objective that gives a Sprint coherence and focus.

Sprint Backlog: The Sprint Goal, selected backlog items and an actionable plan.

Increment: A usable, concrete stepping stone toward the Product Goal.

Definition of Done: The formal quality state required for work to be part of the Increment.

Cross-functionality: Collective possession of the skills needed to create value.

Self-management: The team’s ability to decide internally who does what, when and how.

Impediment: An obstacle that limits progress, effectiveness or value delivery.

Outcome: A change in user behaviour, experience or condition resulting from an output.

Product value: The usefulness and beneficial impact created by a product for relevant stakeholders.

Review Questions

Short Answer Questions

1. What are the three pillars of empiricism in Scrum?
2. What is the purpose of a Sprint Goal?
3. State two responsibilities of the Product Owner.
4. Why should the Definition of Done include more than coding completion?
5. What does cross-functionality mean in a Scrum Team?

Long Answer Questions

1. Explain how transparency, inspection and adaptation operate as an interdependent system.
2. Compare the accountabilities of the Product Owner, Scrum Master and Developers.
3. Discuss why self-management requires clear decision rights and organisational boundaries.
4. Explain how dependencies between functional departments can weaken empirical product development.
5. Evaluate the risks of using velocity as a performance target.

Analytical / Application Questions

1. A Scrum Team regularly completes many backlog items, but customers report little improvement. Diagnose the likely problems using output, outcome and empiricism concepts, and recommend actions.
2. Design an appropriate Scrum Team for a regulated digital health product. Identify required capabilities, decision boundaries, quality conditions and likely external dependencies.
3. An executive committee insists on approving every Product Backlog change and assigning tasks to Developers. Analyse how this affects Scrum accountabilities and propose an organisational intervention.

Multiple Choice Questions with Answers

Question 1

Which statement best describes empiricism in Scrum?

A. Following a fixed plan without changing scope

B. Making decisions based on observation and evidence

C. Delegating all decisions to senior management

D. Measuring success only by completed tasks

Correct Answer: B. Making decisions based on observation and evidence

Question 2

Who is accountable for maximising the value of the product resulting from the work of the Scrum Team?

A. The Scrum Master

B. The Developers

C. The Product Owner

D. The stakeholders collectively

Correct Answer: C. The Product Owner

Question 3

Which commitment is associated with the Product Backlog?

A. Definition of Done

B. Product Goal

C. Sprint Goal

D. Release checklist

Correct Answer: B. Product Goal

Question 4

What is the primary purpose of the Daily Scrum?

A. To provide a status report to a manager

B. To estimate the entire Product Backlog

C. To inspect progress toward the Sprint Goal and adapt the plan

D. To approve changes to the product strategy

Correct Answer: C. To inspect progress toward the Sprint Goal and adapt the plan

Question 5

Which activity is an accountability of Developers?

A. Ordering the Product Backlog

B. Establishing Scrum throughout the organisation

C. Creating the Sprint Backlog and maintaining quality

D. Approving every stakeholder request

Correct Answer: C. Creating the Sprint Backlog and maintaining quality

Question 6

A cross-functional Scrum Team is one that:

A. Contains only software engineers

B. Has all skills collectively needed to create a usable Increment

C. Uses a separate department for every major activity

D. Requires approval from specialists outside the team for every item

Correct Answer: B. Has all skills collectively needed to create a usable Increment

Question 7

What does self-management mean in Scrum?

A. The team has no accountability to stakeholders

B. The Scrum Master assigns every task

C. The team decides internally who does what, when and how

D. The Product Owner performs all technical planning

Correct Answer: C. The team decides internally who does what, when and how

Question 8

Which statement about the Definition of Done is correct?

A. It describes the quality state required for work to be part of the Increment

B. It is a private checklist maintained by the Scrum Master

C. It applies only to items that are released externally

D. It can be ignored when a Sprint is nearly complete

Correct Answer: A. It describes the quality state required for work to be part of the Increment

Question 9

Why is comparing teams by velocity problematic?

A. Velocity is always measured in monetary units

B. Velocity is a local planning measure and is not a universal productivity unit

C. Velocity cannot be calculated for any Scrum Team

D. Velocity measures customer satisfaction directly

Correct Answer: B. Velocity is a local planning measure and is not a universal productivity unit

Question 10

Which situation most directly weakens Product Owner accountability?

A. Developers adapt their plan during the Sprint

B. Stakeholders inspect a usable Increment at the Sprint Review

C. A committee must approve every Product Backlog ordering decision

D. The Product Owner discusses evidence with customers

Correct Answer: C. A committee must approve every Product Backlog ordering decision