Scrumooth v3.1 — enforcement, published as a contract

[orbivort]

Scrumooth v3.1 — enforcement, published as a contract

Judge a Scrum tool by the rules it keeps, not by the boards it draws.

Most tools in this category support Scrum, and record it genuinely well. Very few will tell you which rule they will refuse you on. v3.1 is the release where Scrumooth's enforcement stops being a claim in a README and becomes a contract you can read, count, and call from code.

---

The problem, restated once

Most tools are built to record what happened. They give you boards, they log your clicks, they draw accurate charts — after the Sprint is over. Recording is genuinely useful, and those tools do it well. But a record is a description, not a decision.

The 2020 Scrum Guide is full of rules a tool could hold you to. In most tools those rules are advisory: a shared understanding the team is trusted to remember. And a rule you can switch off in a settings panel is not a rule — it is a preference. That is not an oversight on their part; configurability is the product they are selling.

Scrumooth is the other trade-off: a gatekeeper, not a note-taker. Fewer process debates, more time shipping working software.

The one thing v3.1 changes

Every refusal is now machine-readable, classified, and verified in CI.

When Scrumooth refuses an action because it would violate the Guide, the response carries a stable GATE_* code in error.code — no parsing localized message text, no guessing from an HTTP status. There are 68 of them in v3.1, and:

What the contract says	v3.1
Distinct refusals the backend can return	68
Enforcing a rule of the 2020 Scrum Guide	39
Enforcing a complementary practice (the Definition of Ready)	5
Enforcing a process-integrity / transparency boundary	24
How the totals are kept honest	pnpm run gates:verify, run in CI

That last row is the point. The counts above are counted rather than asserted — a CI check (pnpm run gates:verify) fails the build if a gate is unclassified, missing from the published reference, published with a status the contract does not declare, or counted differently in the README. This is why the numbers cannot drift from what the code actually enforces.

And it publishes where the Guide stops and we start

A tool that claims to enforce "the Scrum Guide" should be able to show you the line between the Guide's rules and its own opinions. Ours is drawn at 39 of 68.

• Guide gates (39) — Sprint container rules, Sprint close, roles, sizing, ordering, Definition of Done, Increment integrity, event ordering, Product Goal, Team Group governance.
• Complementary practices (5) — the Definition of Ready. The Guide's artifacts are the Product Backlog, the Sprint Backlog and the Increment; the DoR is none of them. It is labelled as our addition in the interface, and a team that does not want one still meets it, because Scrumooth seeds six sensible default criteria.
• Process-integrity boundaries (24) — our reading of the Guide's transparency and self-management: a team's artifacts belong to that team, and candid material belongs to the role accountable for it.

It would have been easier to call all 68 "Scrum Guide gates" and let the Guide's authority do the work. We separated them, in three tables, so the claim in the first table means exactly what it says.

The same precision applies to what we deliberately do not enforce: the Retrospective Prime Directive is left to the facilitator, and event timeboxes are surfaced through a shared team timer rather than force-closing an event. The Guide asks for self-management in exactly those places, so Scrumooth does not decide for the team.

What else is newly gated

v3.1 closes the lifecycle end to end. Headlines, with the detail in the CHANGELOG:

• Product Goal — one ACTIVE goal at a time, Product-Owner-only, required before a Sprint starts or backlog work is added, and it cannot complete without recorded evidence.
• Product Backlog — a real ordered list with a dense rank, ordering still the Product Owner's alone.
• Sprint Planning — a Sprint cannot open without recorded planning participation (Product Owner + at least one Developer) and a plan that fits recorded capacity.
• Scope change — a goal-endangering change stays pending until the Product Owner acknowledges it.
• Definition of Done / Ready — seeded defaults with stable keys, immutable version history, retrospective reflection before DoD changes apply, and the readiness bar enforced at the Sprint boundary.
• Increment integrity — a written, attributed usability attestation before verify or deliver; a recorded delivery method; terminal states that cannot be rewritten; Sprint completion snapshots that distinguish "not observed" from "zero".
• Daily Scrum — a scheduling commitment that informs cadence without gating, and adaptation that is now mandatory: declare an adjustment, or declare that none was needed.
• Sprint Review & Retrospective — ordering and end-date gates, the Sprint Goal verdict recorded by the team rather than inferred from item completion, and Scrum-Master-only notes with revision history.
• Scrum Master facilitation — organizational barriers, working agreements, a private coaching log, cross-functionality snapshots, and Scrum Values health checks whose results only the owning team's Scrum Master can read.
• Team Groups — several Scrum Teams on one product share one Definition of Done; joining records the adopted version; a non-empty group cannot be dissolved.
• Reports — read-only, team-scoped velocity, sprint history and metrics endpoints.

Also new: the frontend mock now runs on Mock Service Worker at the real HTTP boundary, with one handler registry shared by development, Vitest and Playwright; a supported backend-free demo build (--mode demo); and dev-only pseudo / pseudo-rtl locales for string-expansion and RTL testing.

Upgrade notes — please read before you pull

v3.1 declares two breaking changes.

1. Gate refusals are now machine-readable. If you integrated against Scrumooth by branching on HTTP status codes or on message text, switch to the GATE_* codes. The canonical list is the gate rejections reference.
2. Team groups own a shared Definition of Done. A team that belongs to a group can no longer edit its own DoD (GATE_DOD_GROUP_GOVERNED), and definition_of_done."teamId" is no longer mandatory now that a DoD may belong to a group.

Two more things worth knowing:

• The readiness bar is now enforced at the Sprint boundary. A team whose items do not satisfy its own Definition of Ready will be refused (GATE_DOR_REQUIRED, GATE_DOR_NOT_READY, GATE_DOR_NOT_VERIFIED). New teams get six defaults seeded; existing teams get them the first time the agreement is read. This is the intended behaviour of a change that adds enforcement, but it is a change you should schedule rather than discover.
• Legacy routes and the in-app mock are gone. The old Scrum Master dashboard, DoD/DoR settings and privacy-data URLs remain only as redirects, and the service-layer mock was removed in favour of the MSW handlers — which also strips a verified 40 KB gzip leak out of production bundles. Mocks are now explicit opt-in: VITE_USE_MOCK_API must be exactly true.

What v3.1 deliberately does not do

There is no setting that disables a Guide gate. Scrumooth is not also a general-purpose project tracker, and there is no scaled-agile mode, no SaaS tier, and no per-person skill inventory — cross-functionality is recorded as team-level snapshots, because the Guide asks for it at the level of the team, not as an inventory of individuals. Coaching notes are recorded in the audit log by length only, never by body.

The roadmap is unchanged in shape: deeper enforcement, not a wider product. Next up is a per-Sprint conformance report and an exportable evidence pack — the evidence your auditor asks for, generated from gates that already fired.

Try it

• Live demo, no install: https://orbivort.github.io/scrumooth/ — runs entirely in your browser on a fictional universe of invented teams and products.
• Self-host: docker compose up -d from the Quick Start.
• Read the contract: the gate rejections reference.

Tell us where the contract is wrong

The most useful bug report you can send us is one of these two:

• a 2020 Scrum Guide rule we do not enforce, or
• something we enforce that the Guide does not actually say — and which we have not labelled as our own addition.

Both are defects in the contract rather than feature requests, and both get fixed. Comments here, or open an issue.