The 2020 Scrum Guide got shorter by removing rules

Three accountabilities, one container event

The current Scrum Guide, released in November 2020 according to the guide's own download page, as retrieved on 16 September 2026, defines Scrum tightly. Ken Schwaber and Jeff Sutherland, who the guide's own site says 'co-developed the Scrum process' together 'in the early 1990s,' still author the document. The 2020 text names three accountabilities inside a Scrum Team — Developers, Product Owner and Scrum Master — stating plainly that 'there are no sub-teams or hierarchies.' Scrum 'combines four formal events for inspection and adaptation within a containing event, the Sprint': Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Three artifacts complete the framework, each paired with a commitment: the Product Backlog with a Product Goal, the Sprint Backlog with a Sprint Goal, and the Increment with a Definition of Done.

What the 2020 edition removed

The guide's own revision history lists what changed from the 2017 edition, and most of it is subtraction. The three prescribed Daily Scrum questions are gone, replaced with open language about inspecting progress. The separate 'Product Owner and Development Team' structure was folded into a single Scrum Team with three accountability sets rather than two tiers. The guide also swapped 'self-organizing' for 'self-managing,' extending the team's choice from who and how to also what it works on, and added the Product Goal as a new, longer-range commitment. The result, by the guide's own account, fits in 'fewer than 13 pages' — a document that got shorter and less prescriptive at the same time it added a new artifact commitment.

What that brevity leaves for tools to decide

Nowhere in the guide's own definitions of these events and artifacts do the terms 'story point,' 'velocity' or 'burndown chart' appear. Estimation technique, capacity planning and progress charts are left entirely to the team, which is precisely the gap that project-tracking software fills, usually by defaulting to one convention — points and a burndown line — presented as though it were part of Scrum itself. A backlog tool can faithfully hold a Product Backlog and Sprint Backlog without ever surfacing a Sprint Goal or a Definition of Done, since the guide requires the commitment, not a specific field for it; whether a team actually uses the goal to decide what belongs in the sprint depends on habits the software cannot enforce.

• Does the tool require a Sprint Goal before work can be added to a sprint, or is the field optional and often blank?
• Is 'velocity' being used to forecast, or quietly to evaluate the team?
• Which of the three artifact commitments does the tool actually check for, rather than just store?

A framework that fits in thirteen pages leaves most of the detail to the team using it. The detail that software adds by default is not in the guide; it is a convention the market settled on afterward.