Linters catch mistakes the moment you make them. Most agile tools wait until after the sprint to tell you.
Introduction
Your sprint failed three days ago, and the tool knew it the whole time. It just waited to show you in a burndown chart, after the damage was already done.
Every retrospective ends with the same three words: "improve our process." Then the team returns to the same class of tool — one that lets a backlog item fly from To Do straight to Done, that happily saves a sprint with no goal, and that never blinks when you commit to twice what anyone can deliver.
Your editor would never tolerate that behavior. Write const x = 1; x = 2; and a red squiggle appears the instant your cursor moves:
const x = 1;
x = 2; // Assignment to constant variable — caught the moment you type it
A linter does not file a report after you ship the bug. It stops you at the keystroke.
This article is about that contrast — prevention versus recording — and what it looks like when you apply the linter mindset to the way your team runs Scrum.
Two Ways a Tool Can Treat a Mistake
There are two fundamentally different jobs a tool can do when something goes wrong. Understanding the difference is the whole point.
The first job is recording. The tool watches what happens, logs it, and reports back later. A burndown chart is a record. A velocity graph is a record. A retrospective dashboard is a record. These are useful, but they all share one property: they describe the mistake after it has happened.
The second job is preventing. The tool checks each action against a set of rules and refuses to allow the bad thing in the first place. This is what a linter does, and it is a different relationship to failure entirely.
| Recording tools | Preventing tools |
|---|---|
| Tell you what went wrong | Stop it before it happens |
| Visualize the problem afterward | Block the problem at the source |
| Help you react | Help you avoid reacting |
A tool that only records can tell you how much a mistake cost. A tool that prevents stops the cost from ever being incurred. That single distinction changes everything downstream.
The Linter Mindset
A linter works on three principles, and each one maps cleanly onto how a team runs a sprint.
1. Rules are encoded, not remembered. A linter does not rely on the developer to recall the rule. The rule lives in the tool and runs on every action. The equivalent for Scrum is the 2020 Scrum Guide, turned from a document you skim once a year into rules that run on every interaction.
2. Invalid actions are blocked, not flagged. A linter does not let you save the bad code and then remind you about it later. It refuses the keystroke. The same idea applies to workflow: if a card must pass through In Progress, the Done state should simply not be reachable without it.
3. Failure is caught at the cheapest point. The earlier a mistake is caught, the less it costs. At the keystroke, a fix takes seconds. At the end of a sprint, it costs rework and trust. This is why prevention always beats reporting on cost.
Here is what those principles look like as concrete rules:
Before a Sprint can start:
✓ A Sprint Goal exists and is non-empty
✓ Capacity is configured
✓ The backlog is prioritized
Before a backlog item can reach Done:
✓ It passed through In Progress
✓ Every Definition of Done criterion is met
✓ The transition is valid for its current state
Each rule is a guardrail. Together, they turn process adherence from a matter of discipline into a matter of design — and discipline fails quietly, where design cannot.
What Prevention Changes for Each Role
The linter mindset is not abstract. It changes the daily experience of everyone on the team:
- A Product Owner tries to start a sprint without a clear goal — the tool refuses. The goal has to exist and mean something before the sprint can begin.
- A Developer drags a card straight to Done without passing through In Progress — the board says no. The right way to move work is enforced, not suggested.
- A Scrum Master stops policing process in Slack. The guardrails live in the tool, so they get back to coaching.
- A backlog item with no Definition of Done cannot be called finished. Every criterion has to be met before Done is even an option.
The shared effect is subtle but profound: the team's conversation moves from "what went wrong?" to "what should we build next?" That is where the energy belongs.
Applying This Without Changing Tools
You do not need a new tool to start. You can apply the linter mindset to whatever you already use, starting with the cheapest wins:
- Make invalid states unrepresentable. If a card must pass through In Progress, do not make Done reachable without it — enforce it in your workflow configuration.
- Gate the start, not just the end. Require a Sprint Goal and realistic capacity before a sprint begins, not in the retrospective after.
- Automate the Definition of Done. A checklist nobody checks is just a checklist. Make it a blocker on the transition itself.
- Retire the human police officer. When guardrails live in the tool, the Scrum Master returns to coaching instead of chasing cards.
One boundary matters: a linter is not a substitute for conversation. The rules handle the mechanical checks; the humans still own the judgment calls. Prevention is the floor, not the ceiling.
An Example Implementation
If you want to see this mindset built into a tool rather than layered onto one, I should be transparent: I am a maintainer of Scrumooth, a self-hosted, open-source Scrum lifecycle management tool that embeds the 2020 Scrum Guide as executable rules.
It covers the full lifecycle — product goal and backlog with MoSCoW prioritization, sprint planning with capacity enforcement, an interactive Kanban board with valid state transitions, daily scrums, impediments, increments, reviews, and retrospectives — with Definition of Ready and Done checklists gating every transition.
Two quick notes, kept brief because the tool is not the point of this article:
- Try it in your browser: a live demo runs entirely client-side with mock data, no signup required — orbivort.github.io/scrumooth
- Self-host it: it is Apache 2.0 licensed, and the repository ships Docker Compose configuration — github.com/orbivort/scrumooth
Even if you never use it, the underlying idea is worth taking back to your team.
Conclusion
The takeaway fits on a sticky note:
- Tools can either record a mistake or prevent it — and they are very different jobs.
- Linters work because they encode rules, block invalid actions, and catch failure at the cheapest point.
- The same principles apply to Scrum, whether you adopt a new tool or reconfigure the one you have.
Your code has a linter. Your sprints should too. The next time a retrospective ends with "improve our process," ask whether the process is being enforced anywhere — or only discussed afterward.
Frequently Asked Questions
What exactly is "the linter mindset" for Scrum?
It is treating the 2020 Scrum Guide the way a code linter treats style and correctness rules: encode the rules in the tool, run them on every action, and block invalid actions instead of reporting them after the fact.
Do I need a specific tool to apply this?
No. The cheapest changes — gating transitions, requiring a Sprint Goal before a sprint starts, automating the Definition of Done — can be made in most workflow tools. A purpose-built tool helps, but it is not a prerequisite.
How is preventing different from enforcing process?
Enforcement can rely on discipline, which quietly fails. Prevention is structural: the invalid action is not merely discouraged, it is not available in the first place.
Where can I learn more about Scrumooth?
The repository is at github.com/orbivort/scrumooth, and there is a live demo at orbivort.github.io/scrumooth.
