Self-management and what it does not mean

Three decisions, and where they moved to

Self-management is not a culture or a maturity level somebody awards. It is a named transfer of three decisions into the team, and the Guide states it in one line: "They are also self-managing, meaning they internally decide who does what, when, and how." Learn the three and a whole family of exam questions answers itself, because every option that puts a name against a task from outside the Scrum Team is wrong however reasonable the outsider's motive is. A team lead balancing the load across individuals is the arrangement most organisations really run, and it is the one Scrum replaces: the people doing the work are given the authority to move it rather than somebody above them being appointed to allocate it.

The same transfer is stated a second time about Sprint Planning, and the second statement is the one the exam prefers, because it is where an expert can plausibly be put in the room. How the selected items become an Increment is, in the Guide's words, "at the sole discretion of the Developers". So an architect who arrives with a task breakdown, or a payments specialist who knows the integration nobody on the team has touched, is offering an input. The Scrum Team may invite other people to Sprint Planning for advice, which means the presence is fine and only the instruction is not. Advice that cannot be declined is an instruction, and a candidate who can hold that distinction gets both halves of the question — banning the outsider from the event is as wrong as letting them decide.

The boundary with the Product Owner is the other one worth carrying, and it is a split rather than a hierarchy. The Product Owner owns what is worth doing and in what order; the Developers own how much it costs and how it will be built, which is why the Developers who will be doing the work are responsible for sizing and why a Product Owner rewriting their estimates downward is reaching across the line. It runs both ways: Developers who want the top ten items reordered argue for it and try to convince the Product Owner, and the decision still stays where it was. Overcorrecting — the Product Owner may not discuss sizes at all — is its own wrong answer, because influencing a judgement by explaining trade-offs is not the same act as setting the number.

Scope is the sharpest edge, because it is shared. When the Developers find on day six that a selected item is far larger than they thought, deleting it quietly is wrong even when dropping it is the right outcome: they collaborate with the Product Owner to renegotiate the scope of the Sprint Backlog without affecting the Sprint Goal, and they do it when the discovery is made rather than at the Sprint Review. And none of this works at all unless the team holds the skills. Cross-functional and self-managing are said in the same breath because a team waiting four days on a separate testing department does not actually decide when its work gets done — it has handed that decision to whoever owns the queue.

Container and method: what the team may not change

The reliable test for any "may a self-managing team change this" question is to ask whether the thing is a container or a method. The containers — the events, their cadence, their timeboxes, the three accountabilities, the artefacts and their commitments — are fixed by the framework. What happens inside them is the team's to fill in, and that is a large freedom rather than a consolation prize: Scrum is deliberately incomplete about techniques, formats and tools precisely so that the people doing the work supply them.

The Daily Scrum shows both halves in one event. The Developers may select whatever structure and techniques they want, so walking the board right to left instead of asking three questions each is entirely theirs — and note that the 2020 Guide names no format at all, so a team still running three prescribed questions is following a habit rather than a rule. The freedom is bounded by a purpose and an output rather than by a format: whatever the Developers choose has to focus on progress toward the Sprint Goal and leave them with an actionable plan for the next day, which is also why raising impediments and re-planning the coming day are theirs to run. What is not theirs is that the event happens every working day and that it lasts fifteen minutes. Skipping it in a quiet week is dropping an event, and a forty-five minute Monday session is a perfectly good conversation that is not the Daily Scrum.

Scale that up and the answer does not change. A team that votes unanimously in its Retrospective to stop holding the Sprint Review has not exercised self-management, and the strongest distractor preserves the purpose while dropping the event — the Product Owner will gather stakeholder feedback another way. Scrum is explicit that implementing only parts of it is possible and that what results is not Scrum. Unanimity is not the test, no Scrum Master approves a process change, and a three-Sprint trial does not convert an omitted event into a practice.

The structure of the team is a container too. Nine people who have organised themselves into a front-end group and a back-end group, each with its own stand-up, its own slice of the Sprint Backlog and a nominated senior who speaks for it, have re-created the reporting lines the framework removed. Scrum states flatly that a Scrum Team contains no sub-teams and no hierarchies, and gives the reason in the next breath: it is a cohesive unit focused on one objective at a time. A shared Definition of Done would not repair that split, and splitting into two Scrum Teams is not the fix either — nine is not too large, and two teams on one product would share a Product Goal, a Product Backlog and a Product Owner rather than halving one Sprint between them.

What self-management never buys

It buys no exemption from transparency, and that is the misreading this lesson exists to kill. A team that stops keeping its Sprint Backlog current and tells a stakeholder it will show the result at the Sprint Review has confused owning its plan with hiding it. The Sprint Backlog is a plan by and for the Developers and a highly visible, real-time picture of the work, and the emergent work has to be visible to the people performing it as well as the people receiving it. The Developers are the first ones an out-of-date artefact misleads, because it is what they inspect their own progress against each day. The fix is not a daily report from the Scrum Master, which leaves the artefact untrustworthy and turns the Scrum Master into a reporting channel.

The same principle refuses a freeze. A delivery manager who wants the Sprint Backlog fixed at Sprint Planning and every change routed through her is trying to protect a report by destroying the thing the report describes; the Sprint Backlog is updated throughout the Sprint as more is learned, and it is the Sprint Goal that is the commitment, not the item list. The compromise teams actually reach — a frozen public board and an accurate private plan — is the worst of the options, because the inspected artefact is then a fiction. It also refuses an interrogation: a functional manager working down the Daily Scrum asking each Developer what they did yesterday has turned fifteen minutes of re-planning into a status report, and the Developers begin addressing her rather than each other. Scrum sets no attendance ban on the event, so the answer is to meet her real need from the artefacts, not to police the door. Presence there follows the work rather than the job title: a Product Owner or Scrum Master who is actively working on Sprint Backlog items takes part as a Developer.

It buys no exemption from the quality bar either. Developers who agree among themselves to skip the security review and the regression suite for the last three days have not produced two more Done items, they have produced two items that go back to the Product Backlog: the Developers are required to conform to the Definition of Done, and during the Sprint quality does not decrease. Telling the Product Owner does not authorise it, because the Product Owner cannot grant that exemption either, and there is no Scrum Master approval of reduced checks anywhere in the framework. Where the team does have room is upward only. The Guide says that where a Definition of Done is an organisational standard, "all Scrum Teams must follow it as a minimum" — so adding accessibility testing and a rollback plan in a Retrospective still complies, and dropping a clause that does not suit this product does not. Where the organisation publishes no standard the Scrum Team writes one appropriate for the product — it is nobody else's to set, and least of all the Product Owner's — and several teams on one product must mutually define and comply with the same one.

And it buys no exemption from accountability. The Developers are always accountable for four things — creating the Sprint Backlog, instilling quality by adhering to a Definition of Done, adapting their plan each day toward the Sprint Goal, and holding each other accountable as professionals — and the last of those is the answer to every claim that a self-managing team has nobody who may be challenged. A Developer who has taken no work for two Sprints is the team's conversation to have. Escalating to a line manager hands the team's own accountability back to somebody outside it, and the Product Owner has no authority over team membership whatever value is being lost. Removing the manager did not remove the accountability; it moved it into the team.

The organisation grants it, and the Scrum Master protects it

Self-management is not something a team declares. The Guide puts the obligation on the organisation: "They are structured and empowered by the organization to manage their own work." That single sentence is the whole of the second half of this lesson, because it means an organisation that pulls a Developer out on day four for another product's escalation is undoing something it set up. The move to remember is neither of the two that come naturally. Absorbing the loss quietly hides the cost from the only person who could have weighed it, and a Scrum Master has no authority to veto a manager and would only be swapping one command relationship for another by trying. What is left is the useful move: work through the impact on the Sprint Goal with the department head and the team, and coach the organisation on why it empowered the team in the first place. Cancelling the Sprint is not on the table either — that is the Product Owner's alone, and the trigger is a Sprint Goal that has become obsolete rather than one that has become harder.

A withheld grant of authority also breaks empiricism in a way that is invisible from inside the team. Transparency enables inspection and inspection enables adaptation, and an organisation can sever the last link while leaving the first two intact. Teams six months into an adoption that still need a governance board to release and an architecture forum for every technical choice will inspect diligently in every Retrospective and change almost nothing, and the Guide names the mechanism: adaptation becomes more difficult when the people involved are not empowered. Reworking the Retrospective format attacks the part of the loop that is already working, and escalating each blocked improvement one at a time makes the Scrum Master a permanent intermediary while the structure that generates the blockages stands.

The Scrum Master serves self-management rather than exercising it, and the exam's favourite version of that is a team stalling on the awkward integration work until the Scrum Master starts saying each morning who should take what. The team runs smoothly and the arrangement is still wrong, because coaching the team members in self-management is the accountability and supplying their decisions is the opposite of it. Stopping once the team is experienced enough is the most seductive wrong answer on this material: a team handed its decisions daily never develops the habit, so the handover date never arrives. Nor does moving the same directive act from the Daily Scrum to Sprint Planning change who decided.

The distinction that settles these is between removing an impediment and removing a decision. Causing the removal of impediments to the team's progress is squarely the Scrum Master's work; deciding who takes the unpleasant task is the Developers', and the useful response to a team asking the Scrum Master to decide is to make the decision easier to take rather than to take it. The same line explains why becoming the permanent expediter of an external testing queue is wrong even though it looks like removing an impediment — it entrenches the handoff instead of removing it, and the dependency was the impediment.