Scrum Team, Accountabilities and Leadership

Introduction

Scrum is an empirical framework for developing and sustaining complex products. Its effectiveness depends less on ceremonies or software tools than on how people make decisions, collaborate, inspect results, and adapt their work. The Scrum Team is the primary unit of delivery. It is not a temporary committee assembled around a project manager, nor is it a collection of specialists who work independently and hand work from one department to another. It is a cohesive, focused group accountable for creating a valuable, useful and usable product increment.

The current Scrum Guide describes three accountabilities within the Scrum Team: Product Owner, Scrum Master and Developers. “Accountability” is deliberately stronger than a job title or a list of activities. It identifies an outcome for which a person is answerable, while allowing flexibility in how that outcome is achieved. An organisation may use different employment titles, but it should not dilute or combine accountabilities in ways that create conflicts of interest or obscure decision rights.

This chapter explains the three accountabilities, the principles of self-management and cross-functionality, servant leadership, common misconceptions, and the practical conditions required for effective Scrum teamwork.

Learning Objectives

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

• distinguish Scrum accountabilities from conventional job descriptions;
• explain the responsibilities of the Product Owner, Scrum Master and Developers;
• describe how self-management and cross-functionality support empiricism;
• apply servant-leadership behaviours in a Scrum environment;
• identify common role misconceptions and their consequences; and
• analyse a practical situation involving competing priorities, impediments and team autonomy.

1. The Scrum Team as a Value-Creating Unit

A Scrum Team consists of one Product Owner, one Scrum Master and Developers. There are no sub-teams or hierarchies inside the team. The team is cross-functional, meaning that it collectively possesses the skills needed to create a valuable product Increment during a Sprint. It is also self-managing: team members internally decide who does what, when and how.

These characteristics are connected to Scrum’s empirical foundation. Empiricism means that knowledge is developed from experience and that decisions are based on observation. Scrum supports this through three pillars:

• Transparency: important aspects of the process and product are visible to those doing the work and those affected by it.
• Inspection: progress and results are examined frequently enough to detect undesirable variations.
• Adaptation: the process or product is adjusted when inspection reveals a problem or a better course of action.

A team cannot inspect and adapt effectively if information is concealed, if decisions are reserved for distant managers, or if members lack the skills required to respond. Consequently, accountabilities, self-management and cross-functionality are not independent features; together they form an operating system for empirical product development.

Accountabilities and activities

An accountability describes what a person or group must ensure. An activity describes something they may do. For example, the Product Owner is accountable for maximising product value; maintaining the Product Backlog is an important activity that supports this accountability. The Product Owner need not personally write every backlog item, but cannot transfer ultimate accountability for value to a committee.

This distinction is useful when organisations assign roles mechanically. A person may be called a business analyst, delivery manager or technical lead while holding one of the Scrum accountabilities. The relevant question is not the label but whether the individual has the authority, focus and capability to fulfil the accountability.

2. The Product Owner

The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team. Product value is not identical to the volume of features delivered. It may involve customer benefit, risk reduction, regulatory compliance, revenue, operational efficiency, learning or strategic positioning. The Product Owner therefore makes decisions about what should be pursued and in what order.

Product Backlog accountability

The Product Owner is accountable for effective Product Backlog management. This includes:

1. developing and communicating the Product Goal;
2. creating and clearly communicating Product Backlog items;
3. ordering Product Backlog items; and
4. ensuring that the Product Backlog is transparent, visible and understood.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is not necessarily a complete contract or a fixed requirements catalogue. Items can be refined as more is learned. Ordering should reflect value, risk, dependencies, learning opportunities and the cost of delay—not merely the loudest stakeholder request.

The Product Owner may delegate backlog-related work to others, such as business analysts or Developers, but remains accountable. Delegation is different from abdication: the Product Owner must retain the authority and knowledge needed to make or confirm ordering and value decisions.

Product Goal and stakeholder engagement

The Product Goal describes a future state of the product that can serve as a target for the Scrum Team’s planning. The Product Owner communicates this goal and helps stakeholders understand the product direction. Stakeholders may provide valuable information, but they do not each receive a private priority queue. Requests are evaluated through the Product Owner’s product perspective and the Product Goal.

An effective Product Owner is accessible to the team. When questions about value, scope or trade-offs remain unresolved, Developers may make technically sound progress in the wrong direction. Accessibility does not mean accepting every interruption. It means establishing clear decision channels and providing timely clarification.

Product Owner misconceptions

Several misunderstandings are common:

• “The Product Owner is the customer.” The Product Owner represents product value and integrates stakeholder perspectives; the role is not necessarily held by the end user.
• “The Product Owner writes all requirements alone.” Collaboration is expected. The accountability concerns clarity and value, not solitary authorship.
• “The Product Owner assigns tasks.” Developers decide how selected work is accomplished and who performs it.
• “The Product Owner can change the Sprint Goal whenever a stakeholder asks.” Changes to product direction are possible, but disruptive changes during a Sprint should be handled through Scrum’s inspect-and-adapt mechanisms. The Sprint Goal provides stability for focused work.
• “The Product Owner is a project sponsor.” A sponsor may provide funding or organisational support, while the Product Owner makes ongoing product-value decisions. One person may hold both positions, but the accountabilities are different.

3. The Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for helping the Scrum Team and the organisation understand Scrum theory and practice. The role is one of leadership and service, not administrative command.

The Scrum Master serves the Scrum Team by:

• coaching team members in self-management and cross-functionality;
• helping the team focus on creating high-value Increments that meet the Definition of Done;
• causing the removal of impediments; and
• ensuring that Scrum events occur and remain positive, productive and within their timeboxes.

The Scrum Master also serves the Product Owner by helping establish effective Product Goal definition and Product Backlog management, supporting empirical planning in complex environments, and facilitating stakeholder collaboration when useful. The Scrum Master serves the organisation by leading, training and coaching Scrum adoption, removing barriers between stakeholders and Scrum Teams, and helping people understand empirical product development.

Facilitation, coaching and impediment removal

A Scrum Master does not automatically facilitate every event. Facilitation is used when it improves the group’s ability to achieve an outcome. Coaching may involve asking questions, making assumptions visible, demonstrating a technique or helping a team examine its working agreement. Teaching provides explicit knowledge about Scrum and empiricism.

An impediment is anything that limits the Scrum Team’s ability to achieve its goals. Examples include an unavailable test environment, unclear authority for security decisions, excessive organisational approvals or unresolved technical debt. The Scrum Master may remove an impediment directly, coordinate its resolution or help the team escalate it. The role is not to become a permanent ticket-routing service; the longer-term aim is to improve the system’s capacity for self-management.

Scrum Master misconceptions

• “The Scrum Master is a project manager.” Project management may involve schedule, scope and resource control through managerial authority. The Scrum Master instead enables empiricism, team effectiveness and organisational learning.
• “The Scrum Master owns the process and enforces compliance.” The Scrum Master helps people understand why Scrum practices exist and supports their effective use; mechanical compliance without inspection is not agility.
• “The Scrum Master is the team secretary.” Booking rooms or recording decisions may occasionally be useful, but administrative service is not the essence of the accountability.
• “The Scrum Master removes every problem personally.” The Scrum Master causes impediments to be removed while strengthening the team and organisation to address recurring causes.
• “The Scrum Master must be a technical expert.” Technical understanding can help, but the essential capability is enabling effective Scrum and organisational change. Technical authority should not undermine Developer self-management.

4. Developers

Developers are the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. “Developer” is used broadly. It includes programmers, testers, designers, analysts, data specialists, technical writers and other professionals who contribute to the product.

Developers are accountable for:

1. creating a plan for the Sprint, the Sprint Backlog;
2. instilling quality by adhering to the Definition of Done;
3. adapting their plan each day toward the Sprint Goal; and
4. holding each other accountable as professionals.

The Sprint Backlog is owned by Developers. It is a plan by and for them, although it is informed by the Product Goal, Product Backlog, Sprint Goal and ongoing discovery. Developers decide how to turn selected Product Backlog items into a usable Increment. They may seek advice from the Product Owner or specialists, but task assignment by an external manager weakens self-management.

Quality and the Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the required quality measures. It creates a shared standard rather than allowing “finished” to mean “coded,” “tested by someone else later” or “ready for a future hardening Sprint.” If a Product Backlog item does not meet the Definition of Done, it is not part of the Increment and is not presented as complete.

Quality is not solely a testing department’s responsibility. Developers build quality into the work through practices such as automated testing, peer review, secure coding, accessibility checks, observability and documentation appropriate to the product. The exact practices vary, but the accountability for a usable Increment remains collective.

Developer misconceptions

• “Developers only code.” The accountability includes all work needed to create a usable Increment.
• “Each specialist has an individual mini-backlog.” The Sprint Backlog is a shared plan; specialisation may exist, but ownership is collective.
• “Developers are merely task executors.” They make technical decisions and organise their work within the product and Sprint constraints.
• “A specialist cannot be a Developer.” Anyone contributing directly to the Increment can be a Developer.
• “A Sprint can finish with unintegrated work and still have an Increment.” Work must meet the Definition of Done to be included in the Increment.

5. Self-Management and Cross-Functionality

Self-management

Self-management means that the Scrum Team internally decides who does what, when and how. It does not mean the absence of leadership, goals, constraints or accountability. The Product Owner provides product direction and value ordering; the Scrum Master supports the conditions for effective Scrum; Developers decide how to create the Increment. Self-management operates within these boundaries.

A self-managing team needs:

• a clear Product Goal and Sprint Goal;
• access to relevant information;
• sufficient authority to make day-to-day decisions;
• psychological safety for raising concerns;
• agreed working practices; and
• accountability for results, not merely activity.

Self-management can be undermined by individual task assignment, approval bottlenecks, performance systems that reward local optimisation, or managers who reverse team decisions without explanation. Conversely, “the team decides” is not an excuse for avoiding difficult decisions or ignoring product and organisational constraints.

Cross-functionality

A cross-functional Scrum Team has all the competencies necessary to create value during a Sprint. Cross-functionality is a property of the team, not a requirement that every individual master every skill. A team may include people with deep specialisms while still being collectively capable of delivering a complete Increment.

Cross-functionality reduces handoffs and waiting. It also increases resilience: if only one person can deploy or test a product, work may stop when that person is unavailable. Teams can improve cross-functionality through pairing, mobbing, mentoring, knowledge-sharing, automation, rotating responsibilities and deliberate reduction of bottlenecks.

Cross-functionality does not require eliminating professional expertise. A useful balance combines T-shaped capability—breadth sufficient for collaboration with depth in one or more areas—with respect for complex specialist work.

Self-management and cross-functionality in practice

Consider a team that contains a product designer, two software engineers and a tester. If the team can design, build, integrate and verify a usable Increment, it is cross-functional even though members retain different strengths. If the tester receives completed work only at the end of the Sprint and cannot influence design or development, the team has functional specialists but weak cross-functionality in practice. The remedy is not necessarily to make everyone test identically; it is to collaborate earlier, share quality responsibility and remove the handoff pattern.

6. Servant Leadership and Professional Influence

Servant leadership places the growth, autonomy and effectiveness of others at the centre of leadership. In Scrum, it does not mean passive obedience or unlimited personal sacrifice. It means using influence to improve the team’s ability to create value and to make sound decisions.

A Scrum-oriented servant leader commonly:

• creates clarity without taking away legitimate decision rights;
• makes impediments and system constraints visible;
• protects the team from harmful interruptions while preserving stakeholder transparency;
• encourages constructive disagreement;
• develops capability through coaching and teaching;
• models humility, curiosity and accountability; and
• addresses organisational causes rather than blaming individuals for systemic problems.

Servant leadership is compatible with firm intervention. For example, a Scrum Master may challenge a manager who assigns tasks directly to Developers, escalate a serious quality risk, or insist that an impediment receive executive attention. Service is measured by improved conditions and outcomes, not by avoidance of conflict.

Leadership is also distributed. The Product Owner leads product-value decisions, Developers lead technical execution and quality, and the Scrum Master leads Scrum understanding and improvement. These forms of leadership overlap through collaboration, but none grants unlimited authority over the others.

7. Working Relationships and Decision Boundaries

Scrum accountabilities are interdependent. The Product Owner cannot maximise value without technical insight from Developers. Developers cannot create the right Increment without understanding product value. The Scrum Master cannot improve the system without honest information from both.

A practical decision map is shown below.

This table is not a substitute for judgement. For example, Developers may identify a technical risk that changes the recommended backlog order, but the Product Owner remains accountable for ordering. Similarly, the Product Owner may explain the required outcome, but does not prescribe implementation tasks merely because a stakeholder has requested them.

8. Illustrative Case: The Claims Platform Team

Background

An insurance company creates a Scrum Team to replace a legacy claims portal. The team includes a Product Owner from claims operations, a Scrum Master, three software engineers, a tester and a user-experience designer. A security specialist supports the team part-time.

Problem

After three Sprints, the team reports high activity but little usable value. The Product Owner sends urgent requests directly to individual engineers. A department manager assigns tasks according to job titles. Testing occurs in the final two days, and several items are carried over. The Scrum Master responds by creating a detailed task board and personally chasing every impediment.

Analysis

The team has several accountability failures. Product decisions are being made through informal stakeholder pressure rather than a transparent Product Backlog. Developers are not self-managing because work is assigned externally. Cross-functionality is weak because testing and design occur as sequential handoffs. The Scrum Master is acting as a coordinator rather than developing team and organisational capability. Most importantly, activity is being mistaken for value because the Definition of Done is not consistently applied.

Approach

The team agrees on a Product Goal: enable customers to submit a complete low-complexity claim online. The Product Owner reorders the Product Backlog around that outcome and establishes a predictable channel for stakeholder requests. Developers create the Sprint plan themselves and pair an engineer with the tester during refinement and implementation. The team expands its Definition of Done to include integration, automated regression tests, accessibility checks and deployment to a realistic test environment.

The Scrum Master coaches the manager and Product Owner on decision boundaries, makes the test-environment impediment visible to the organisation and facilitates a retrospective focused on causes rather than blame. The security specialist joins early discussions instead of reviewing work only at the end.

Outcome

After several Sprints, the team delivers a small but usable claim-submission flow. Fewer items are started, but more meet the Definition of Done. Stakeholders receive clearer evidence at the Sprint Review, and technical risks are identified earlier. The Scrum Master gradually reduces direct coordination as the team takes greater ownership of its plan and impediments.

Learning points

1. Product focus is improved by explicit goals and transparent ordering.
2. Self-management requires authority, information and clear boundaries.
3. Cross-functionality is demonstrated through a usable Increment, not by job titles.
4. Quality must be built into the Increment rather than postponed.
5. Servant leadership develops capability instead of creating dependency.

9. Challenges, Limitations and Governance

Scrum does not eliminate organisational power differences, uncertainty or difficult trade-offs. A team may be called self-managing while lacking authority over architecture, environments, staffing or compliance decisions. In such circumstances, leaders should make constraints explicit and work to remove unnecessary ones rather than pretending autonomy exists.

Large products may require multiple Scrum Teams and additional coordination. However, scaling does not justify replacing clear accountabilities with layers of status reporting. Teams still need a coherent product direction, transparent dependencies and mechanisms for integrated inspection.

Governance and regulation are compatible with Scrum when controls are treated as product and process requirements rather than as late-stage gates. Evidence for audit, privacy, security, accessibility and safety can be incorporated into the Definition of Done and backlog. Accountability must not be used to conceal blame: regulated environments should define decision authority, traceability and escalation paths clearly.

Ethically, Scrum leaders should protect user interests, avoid misleading progress claims and surface quality or safety risks even when doing so threatens a short-term target. The Product Owner should not present unfinished work as delivered value; Developers should not hide defects; and the Scrum Master should not manipulate metrics to create an appearance of success. Transparency is an ethical as well as operational requirement.

10. Contemporary Practice and Digital Tools

Distributed Scrum Teams increasingly use digital backlogs, collaborative whiteboards, video meetings, automated pipelines and shared documentation. Tools can improve transparency, but they cannot create trust or replace conversation. A digital board that records tasks while concealing uncertainty is not genuine transparency.

Artificial intelligence can assist with backlog analysis, test generation, code suggestions, summarisation and discovery. Such tools do not transfer accountability. The Product Owner remains accountable for value and ordering; Developers remain accountable for quality, security and the resulting Increment; and the Scrum Master remains accountable for effective Scrum. AI-generated content requires human review for correctness, bias, privacy, intellectual-property risk and explainability. Teams should establish explicit rules about confidential data, approved tools and verification of generated outputs.

Useful measures should support learning rather than rank individuals. Examples include evidence of usable Increments, defect trends, time to resolve impediments, customer outcomes and the team’s ability to meet goals. Counting story points or hours can become a local optimisation if disconnected from value and quality.

Best-Practice Checklist

A Scrum Team is more likely to be effective when:

• one clearly empowered Product Owner is accountable for value and ordering;
• Developers own their Sprint plan and collectively own quality;
• the Scrum Master coaches rather than commands;
• the team has a meaningful Product Goal and Sprint Goal;
• the Definition of Done is explicit and applied consistently;
• stakeholders use transparent channels rather than private task assignment;
• specialists collaborate early enough to avoid late handoffs;
• impediments are addressed at their systemic source; and
• progress is discussed through usable results and evidence, not activity alone.

Chapter Summary

Scrum defines three complementary accountabilities: the Product Owner maximises product value and manages Product Backlog effectiveness; Developers create usable Increments, plan their Sprint work, uphold the Definition of Done and hold one another accountable; and the Scrum Master establishes Scrum, coaches the team and organisation, and causes impediments to be removed. These accountabilities are not interchangeable job descriptions.

Self-management gives Developers authority over how work is performed, while the Product Owner remains accountable for value and the Scrum Master supports effective Scrum. Cross-functionality means the team collectively has the capabilities needed to create a usable Increment, not that every person has identical skills. Servant leadership strengthens autonomy, transparency, learning and system improvement rather than creating dependency. Successful Scrum depends on clear decision boundaries, ethical transparency, stakeholder collaboration and continuous attention to quality.

Key Terms

Accountability: An outcome or responsibility for which a person or group is answerable.

Backlog ordering: Arranging Product Backlog items to express relative value, risk, urgency and other considerations.

Cross-functionality: The team’s collective possession of the skills needed to create a usable Increment.

Definition of Done: A formal description of the quality state required for work to be included in an Increment.

Developer: A Scrum Team member who contributes to creating any aspect of a usable Increment.

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

Increment: A concrete, usable and valuable product step that meets the Definition of Done.

Impediment: Anything that limits the Scrum Team’s ability to achieve its goals.

Product Backlog: An emergent, ordered list of what is needed to improve a product.

Product Goal: The future state of the product that serves as a target for the Scrum Team.

Product Owner: The accountability responsible for maximising product value and effective Product Backlog management.

Self-management: The Scrum Team’s authority to decide internally who does what, when and how.

Servant leadership: Leadership that improves the capability, autonomy and effectiveness of others through service and influence.

Scrum Master: The accountability responsible for establishing effective Scrum and supporting the team and organisation.

Sprint Backlog: The Sprint Goal, selected Product Backlog items and the actionable plan created by Developers.

Sprint Goal: The single objective for a Sprint that provides focus and flexibility.

Stakeholder: A person or group affected by, interested in or able to influence the product.

Transparency: Visibility of important information needed for inspection and adaptation.

Review Questions

Short Answer Questions

1. What is the difference between an accountability and an activity in Scrum?
2. State the four main responsibilities associated with Developers.
3. Why is the Definition of Done important?
4. What does cross-functionality mean at team level?
5. Name two ways in which a Scrum Master serves the organisation.

Long Answer Questions

1. Explain how the Product Owner’s accountability differs from that of a project sponsor or requirements administrator.
2. Discuss how self-management can coexist with product direction, organisational constraints and accountability.
3. Explain servant leadership and compare it with command-and-control management.
4. Analyse the relationship between cross-functionality, quality and the delivery of a usable Increment.
5. Describe five common Scrum role misconceptions and explain their likely consequences.

Analytical / Application Questions

1. A department manager assigns every Developer a separate task and requires daily approval before work begins. Identify the affected Scrum principles and propose a coaching response for the Scrum Master.
2. A Product Owner receives conflicting requests from compliance, sales and operations. Explain how the Product Owner should use the Product Goal, Product Backlog ordering and stakeholder collaboration to make a decision.
3. A team completes coding but leaves integration and security testing for a later Sprint. Analyse whether a usable Increment exists and recommend changes to the Definition of Done and team working practices.

Multiple Choice Questions with Answers

Question 1

Which accountability is responsible for maximising the value of the product?

A. Product Owner

B. Scrum Master

C. Developers

D. Stakeholders

Correct Answer: A. Product Owner

Question 2

Who creates the plan for the Sprint, known as the Sprint Backlog?

A. The Product Owner

B. The Scrum Master

C. Developers

D. The project sponsor

Correct Answer: C. Developers

Question 3

What does self-management mean in Scrum?

A. The team has no goals or constraints

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

C. The Scrum Master assigns all tasks

D. Stakeholders change the Sprint plan directly

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

Question 4

Which statement best describes cross-functionality?

A. Every team member must have identical skills

B. Only programmers may belong to the Scrum Team

C. The team collectively has the capabilities needed to create a usable Increment

D. Specialists work separately and hand work between departments

Correct Answer: C. The team collectively has the capabilities needed to create a usable Increment

Question 5

Which is a responsibility of the Scrum Master?

A. Ordering every Product Backlog item personally

B. Assigning tasks to individual Developers

C. Causing impediments to be removed

D. Approving all technical implementation decisions

Correct Answer: C. Causing impediments to be removed

Question 6

What is the purpose of the Definition of Done?

A. To rank Developers by productivity

B. To describe the quality state required for work to be included in the Increment

C. To replace the Product Goal

D. To list stakeholder requests

Correct Answer: B. To describe the quality state required for work to be included in the Increment

Question 7

A business analyst helps write and clarify Product Backlog items. Who remains accountable for Product Backlog management?

A. The business analyst

B. The Scrum Master

C. The Product Owner

D. The most senior Developer

Correct Answer: C. The Product Owner

Question 8

Which behaviour best demonstrates servant leadership?

A. Assigning each task to maximise managerial control

B. Hiding organisational impediments from stakeholders

C. Improving team capability while preserving legitimate decision rights

D. Making the Scrum Master the permanent coordinator of all work

Correct Answer: C. Improving team capability while preserving legitimate decision rights

Question 9

What should happen when work does not meet the Definition of Done?

A. It is still presented as part of the Increment

B. It is included only if the Product Owner approves

C. It is not considered part of the Increment

D. It automatically becomes a completed item next Sprint

Correct Answer: C. It is not considered part of the Increment

Question 10

Which statement about Developers is correct?

A. They only write production code

B. They are accountable for adapting their plan toward the Sprint Goal

C. They must receive individual task assignments from the Product Owner

D. They are accountable for ordering the entire Product Backlog

Correct Answer: B. They are accountable for adapting their plan toward the Sprint Goal