Scrum, day 50: checking misconceptions

Today's objective: examine a familiar Scrum claim by identifying its source, current meaning, and consequence for a real decision.

Read alongside: Mastering Professional Scrum, appendix B, with the November 2020 Scrum Guide available for comparison. The examples below are original and are not reproductions of the book's appendix. Allow roughly five minutes for this companion, plus the reading.

Familiarity can make a local rule sound official

A new colleague joins the fictional ShiftSwap team and hears that Scrum requires story points, prohibits changes during a Sprint, and makes the Scrum Master responsible for assigning tasks. Each claim has been repeated confidently somewhere in the organization.

Correcting the wording is useful, but the larger opportunity is to examine the decision each claim influences. A mistaken rule can prevent a necessary scope conversation, hide a quality gap, or make the team dependent on permission it should not need.

The team needs a habit of checking claims against their source while discussing the practical purpose involved.

“Everything selected is an unconditional promise”

The Developers select work based on current understanding and commit to a Sprint Goal. When they learn more, they may need to negotiate scope with the Product Owner while preserving that goal and quality.

For ShiftSwap, deferring an automatic filter while finishing a dependable pending-request flow can be a responsible adjustment if the goal remains achievable. Quietly weakening verification to preserve every original feature would be a different decision.

The useful correction therefore includes both flexibility and responsibility. The team should not treat selected work casually, and stakeholders should not interpret every initial item as immune to new evidence.

“The Review is the release approval meeting”

The Review supports inspection of the Sprint's outcome and discussion of future adaptations. It does not have to be the first moment stakeholders can receive a usable Increment.

ShiftSwap may deliver a Done slice earlier and bring observations from its use into the Review. That can make the conversation more informative. A release process may include legitimate organizational decisions, but those should not be confused with a Scrum rule that all value must wait for the event.

The distinction affects planning. If the team assumes only one release is allowed per Sprint, it may postpone useful feedback unnecessarily. The relevant reference is the Guide's Increment section.

“Story points tell us how much value was created”

A team's sizing approach may help it discuss effort, complexity, or uncertainty. Completing more points does not establish that users experienced a better outcome.

ShiftSwap could deliver a large notification settings feature that managers rarely need, while a smaller clarification resolves a persistent misunderstanding. Product value requires evidence about the user's situation and the organization's aims.

Story points are also an optional technique. The team should understand what its chosen approach helps it decide and avoid treating its local scale as a universal unit for comparing unrelated teams.

“The Scrum Master must solve every problem personally”

Radu helps the team expose and address an access obstacle, but the relevant operations colleague grants access and the policy owner decides whether the process can change. His contribution may be connecting the right people and helping the organization understand the consequence.

If every ordinary conversation must pass through him, the team acquires another dependency. A useful intervention can leave people better able to act directly next time.

This does not make the Scrum Master passive. It distinguishes active service and accountability for effectiveness from personally performing every action needed to improve the team's environment.

“Self-management means there are no boundaries”

The Developers can adapt their delivery plan within the framework and relevant organizational constraints. They do not gain unlimited authority over funding, product priorities, or access controls.

Clear boundaries make autonomy usable. If ShiftSwap knows which implementation decisions it can make, which product trade-offs need Elena, and which organizational changes need another decision-maker, it can act more promptly and responsibly.

The opposite misconception is equally limiting: that any external constraint means the team cannot self-manage at all. The team can exercise real authority within a boundary while working to improve conditions that unnecessarily restrict it.

Check the source and the version

The two older books in this reading plan predate the current Guide. Terminology and some descriptions reflect their publication periods. A statement may also come from a course, a company policy, a tool template, or a local agreement rather than from Scrum itself.

When a claim matters, locate its source and date. Read the relevant current section in context. Then explain whether the claim describes a framework requirement, an optional technique, an organizational constraint, or an outdated description.

This is more constructive than using the Guide to win a vocabulary argument. The goal is a better decision and a shared understanding of the purpose involved.

Examine one confident statement

Choose a Scrum claim you have heard often. Write it exactly, identify the decision it affects, and locate the best available source. Explain what the current framework actually requires and where local choice remains.

Use a concrete example to show the consequence of the distinction. If the local practice still helps, retain it for that reason. If it obstructs the purpose, propose an experiment to improve it.

Reflection: which rule does your team follow mainly because “we have always done it that way”? What would change if you could explain its purpose and source clearly?

Next, day 51 begins the organizational reading companions for Software in 30 Days.