PSM I Self-Managing Teams: Who Decides What in a Scrum Team

A self-managing Scrum Team decides internally who does what, when and how. Nobody outside the team hands out tasks, schedules the work or prescribes the technique; the people doing the work organise it themselves, within the boundaries Scrum sets.

The 2020 Scrum Guide pairs self-management with cross-functionality. A Scrum Team is cross-functional (its members together have all the skills needed to create value each Sprint) and self-managing (it decides how it uses those people and skills). The two depend on each other: authority to decide is of little use without the skills to deliver, and skills are wasted if someone else decides how they are used.

Self-management also means dealing with gaps inside the team. When a skill is scarce, for example only one person knows the database layer and that person will be away, a self-managing team agrees how to cover the work: pairing, sharing knowledge, or learning the skill. It does not wait for a Scrum Master, Product Owner or line manager to choose a replacement and assign the items.

Self-management is not the absence of structure. The team still works inside Scrum's accountabilities, events, artifacts and commitments, which the rest of this lesson maps out.

The 2020 revision moved the idea from a self-organizing Development Team to a self-managing Scrum Team. Earlier editions described a separate Development Team inside the Scrum Team that chose who did the work and how. The 2020 Guide removed the Development Team as a sub-team, refers simply to Developers, and describes the whole Scrum Team (Product Owner, Scrum Master and Developers) as self-managing: it chooses who, how and what to work on.

Adding "what" does not hand the Product Backlog to the Developers. The team decides what together through Scrum's own mechanisms: the whole Scrum Team crafts the Sprint Goal in Sprint Planning, and the Developers select the Sprint's items in discussion with the Product Owner. The Product Owner remains accountable for ordering the Product Backlog. Self-management also gives no licence to change Scrum itself: the events, artifacts and accountabilities are not the team's to remove or redesign.

Self-management distributes decisions to the people closest to the work, but each decision still has a clear owner in the Scrum Guide. Most exam confusion comes from mixing up these owners.

A useful test: if a proposal moves one of these decisions to someone who does not own it (a manager approving tasks, a Scrum Master allocating work, a Product Owner setting the size of an item), it weakens self-management.

The Scrum Guide describes the Scrum Team as a cohesive unit of professionals focused on one objective at a time, the Product Goal, and states that within it there are no sub-teams or hierarchies. A member who can overrule or approve the others' work would recreate the command structure that self-management replaces.

The rule is about authority, not labels: any arrangement that gives one member the final say over the others' work is a hierarchy, whether the role is permanent or temporary, appointed or chosen by the team. An in-team lead who must sign off other Developers' technical decisions is the classic example. Job titles and HR grades may exist in the organization, but they carry no authority inside the Scrum Team.

Experience still matters. Experienced Developers influence decisions through expertise, mentoring and good arguments; they do not hold a veto. The Scrum Master is not a hidden hierarchy either: the Scrum Master is accountable for the team's effectiveness but serves and leads by coaching, not by managing the work. (Team size and composition are covered in the Scrum Team lesson.)

The Scrum Guide makes holding each other accountable as professionals part of the Developers' own accountability, alongside creating the Sprint Backlog, instilling quality by adhering to the Definition of Done, and adapting their plan each day toward the Sprint Goal. Peer accountability is what replaces a supervisor in a self-managing team.

In practice this means problems among Developers are raised by the Developers, directly and promptly:

• If a teammate's finished work does not meet the Definition of Done, the Developers deal with it first; quality is their shared standard, not something an inspector checks afterwards.
• If one person keeps picking only the easy items and the Sprint Goal is at risk, the Developers raise it now and rebalance the work, because the Sprint Goal is at risk today.
• If the Daily Scrum shows that items the Sprint Goal depends on are stuck while people work on items the Goal does not need, the Developers re-plan and move people to where the Goal needs them, even if that means pausing work already started.

Accountability is peer-to-peer, not reporting upward or creating a new layer of control among Developers. The Retrospective is the place to inspect how the team works together, but it is not a reason to delay fixing something that threatens the current Sprint.

Self-management operates inside Scrum's accountabilities and commitments; it does not replace them. The team decides how to reach its commitments, never whether to honour them.

• Product Owner accountability. The Product Owner remains accountable for ordering the Product Backlog and maximising value. The 2020 "what" in self-management does not let Developers reorder the Product Backlog when they disagree; they make their case to the Product Owner, whose decisions the organization is expected to respect.
• The Definition of Done. Every Increment must meet the Definition of Done in full. If the organization's standard requires, for example, a security review, the team may choose how to carry it out, but an Increment that has not met it is not Done, whatever the deadline.
• The Sprint Goal. Once set, the Sprint Goal guides the Sprint. A team that discovers more valuable work mid-Sprint does not swap goals on its own; the idea goes to the Product Owner for the Product Backlog. Only the Product Owner can cancel a Sprint, and only when its goal has become obsolete.
• The timebox. The Scrum Guide makes Sprints fixed-length events of one month or less to create consistency. Unfinished work is handled by renegotiating scope, not by stretching the timebox.
• Scrum itself. A team may choose practices within Scrum, but cannot drop events, artifacts or accountabilities and still call it Scrum.

During the Sprint the Developers own and continually adapt the plan, while scope stays negotiable with the Product Owner and the Sprint Goal, quality and timebox stay fixed. The Scrum Guide states that no changes are made that would endanger the Sprint Goal, quality does not decrease, and scope may be clarified and renegotiated with the Product Owner as more is learned.

Selecting the work. In Sprint Planning the Developers select items through discussion with the Product Owner, using what they know about past performance, upcoming capacity and the Definition of Done. If the Product Owner hopes for more than the Developers forecast they can do, the selection still rests with the Developers, informed by the Product Owner's explanation of value; nobody adds items to their forecast by decree.

When an item is bigger than forecast. The Developers re-plan toward the Sprint Goal and work with the Product Owner to adjust the scope of the Sprint Backlog, for example by reducing or splitting the item. The Sprint Goal, quality and timebox stay fixed; scope is the part that flexes, and it flexes through the Product Owner.

When there is spare capacity or a new request. Work is added to the Sprint by the Developers in collaboration with the Product Owner. A stakeholder's request to one Developer, for example, becomes a conversation between the Developers and the Product Owner about the Sprint Backlog.

Advice from outside. Stakeholders, architects and the Product Owner may offer technical opinions, such as which library to use. The Developers weigh that advice; the choice of how to build the item remains theirs.

The Daily Scrum is the Developers' own event: they inspect progress toward the Sprint Goal and adapt their plan for the next day, and the Scrum Guide says this creates focus and improves self-management. The Developers may use any structure and techniques they want, as long as the event stays focused on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

• The "three questions" format of older Guides is not required in the 2020 Guide. Walking the board, discussing each Sprint Goal item, or any other technique is fine within the event's purpose; no one else's approval is needed to change format.
• If the Scrum Master leads the event, collects status from each Developer and records it, the event has turned into a status meeting run for someone else: the Developers are no longer running their own planning event.
• If the Product Owner or Scrum Master is actively working on items in the Sprint Backlog, they take part as Developers. Taking on development work does not let them run the event; the Developers still choose how it is held.
• The Daily Scrum is not the only time to adapt: Developers adjust their plan whenever they need to during the day.

Similarly, the Sprint Backlog is "a plan by and for the Developers". How they visualise and track it (task board, burndown, or something else) and how finely they break work into tasks is their decision; the Guide prescribes no chart.

The Scrum Master supports self-management by coaching the team members in self-management and cross-functionality, not by allocating, approving or tracking their work. The Guide lists this coaching first among the ways the Scrum Master serves the Scrum Team, followed by helping the team focus on high-value Increments that meet the Definition of Done, causing the removal of impediments, and ensuring events take place and are positive, productive and within their timebox.

• A team used to being directed. If Developers wait each morning to be handed tasks because a previous Scrum Master did that, the new Scrum Master coaches them to choose and coordinate the work themselves; moving the task-allocation job to anyone else would keep the dependency alive.
• A stalled decision. When the Developers ask the Scrum Master to settle a technical dispute, the Scrum Master can facilitate a conversation that helps them reach a decision, but leaves the decision with them, so ownership stays where the Guide puts it.
• Improvements. A Scrum Master with a good idea, such as a work-in-progress limit, raises it with the team and lets the team decide whether to try it; an improvement mandated from outside undermines the self-management it is meant to help.
• The organization. The Scrum Master also serves the organization by helping people understand and enact an empirical approach. When managers want to steer individual work, for example through rankings of individual output, the Scrum Master's job is to help them understand how that conflicts with self-management and what Scrum offers in its place.

Facilitation and coaching techniques themselves are covered in the facilitation and coaching lesson.

The Scrum Guide says Scrum Teams are structured and empowered by the organization to manage their own work. Self-management cannot be declared by a team alone; the organization has to give it both the authority and the capability.

• Authority: let each team decide internally who works on which item and how. Department heads approving every task, managers assigning daily work, or an appointed lead who distributes tasks all contradict that empowerment.
• Capability: make sure each team has, or can gain, the skills it needs to create a valuable Increment, so it does not depend on outsiders for routine decisions.
• Team-level measures: ranking individuals by output or velocity encourages people to optimise their own numbers rather than the Sprint Goal. Scrum looks at the team's Increment and progress toward its goals.
• Respect for accountabilities: the organization respects the Product Owner's decisions about the Product Backlog and the Developers' decisions about how to do the work.

Empowerment is about the team's own work: who does it and how. It is not a licence to change Scrum's framework or to take over decisions the organization holds outside the team.

Improvement is self-managed too: at the Sprint Retrospective the Scrum Team itself identifies the most helpful changes to improve its effectiveness and may add the most impactful ones to the next Sprint Backlog.