ScrumBut is what you get when a team says “we use Scrum, but…” and drops a part of it to avoid a problem instead of fixing the problem. The daily meeting is “too much”, so it happens once a week. Retrospectives are “a waste of time”, so they stop. The team still calls it Scrum, but the parts that would have shown the problem are gone.
The Scrum Guide is short and easy to read. Following it is harder, and many teams bend the rules without noticing what they lose.
Scrum is a lightweight framework for building products in short cycles. The Scrum Guide, written by Ken Schwaber and Jeff Sutherland and last revised in November 2020, describes it as a framework that “helps people, teams and organizations generate value” through adaptive solutions for complex problems.
The rules fit on a page:
The 2020 Guide is still the official one. In June 2025 Jeff Sutherland, John Coleman and Ralph Jocham published the Scrum Guide Expansion Pack, a companion to the 2020 Guide with practical help, and its “Scrum Guide Expanded” reached version 2026.1 in January 2026. It sits next to the 2020 Guide; it doesn’t replace it.
Scrum.org defines it this way: “ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix.” The ScrumBut keeps the problem and changes Scrum so the problem no longer shows.
Say testing or deployment is a bottleneck. Instead of fixing it, the team calls work “done” without regression or performance tests. Velocity looks fine, and the problem moves to production.
A ScrumBut has a fixed shape: (ScrumBut)(Reason)(Workaround). Scrum.org’s own examples follow this pattern:
What about a short-term change, such as leaving regression tests out of “done” for a few months while the team builds test automation? Scrum.org accepts that organizations sometimes make changes like this to buy time, with transparency restored as quickly as possible.
It still fits the ScrumBut pattern: (We use Scrum, but) (our automated tests aren’t ready,) (so we finish work without them for now.) The difference is how you handle it. Write the exception down, tell everyone who relies on “done”, put a date on it and check it at every retrospective. An exception nobody tracks becomes the new normal.
Three causes come up again and again:
Ken Schwaber, who created Scrum with Jeff Sutherland, recorded ScrumButs: The Dangers of Customizing Scrum about exactly these changes.
Some deviations are normal early on. If you use Scrum but don’t yet practice test-driven development, pair programming or collective code ownership, you may simply be at the start of the agile journey. Those are engineering practices that grow with the team; they aren’t parts of Scrum you removed.
In a mature team, “we use Scrum, but” should raise questions. The cause is rarely a good reason. More often it’s a misunderstanding of how the parts fit together, or a lack of will to face what Scrum exposed.
Researchers have studied ScrumBut directly. Eloranta, Koskimies and Mikkonen interviewed 18 teams in 11 companies and found 14 recurring anti-patterns, each seen in at least three teams (Information and Software Technology, 2016). Some deviations were reasonable. Others were harmful and adopted without understanding the consequences.
A 2023 survey of 42 practitioners checked 35 known anti-patterns. The most common was unfinished tasks at the end of the Sprint. Other frequent ones were Daily Scrums that run long, stories that aren’t refined and no Sprint Goal at planning (Wróbel, Przała and Weichbroth, 2023). A 2022 study went further and treated ScrumButs as process debt that leaves traces in the code itself (Ramirez Lahti et al., 2022).
| ScrumBut | What it hides | The fix |
|---|---|---|
| Daily Scrum once a week | Blockers that sit for days | Keep it daily and to 15 minutes; move problem-solving to after it |
| No retrospectives | The same problems every Sprint | Hold one every Sprint and leave with one change the team owns |
| Sprints longer than a month | Work items that are too big | Split the work until it fits in a Sprint |
| Testing left out of “done” | Defects that reach users | Put tests in the Definition of Done; track any exception with a date |
| Product Owner who isn’t available | Guesswork about priorities | One person who owns the backlog and answers within a day |
| Team split across several projects | Constant context switching | One product per team, or a smaller team |
| Scrum Master who is also Product Owner | Nobody protecting the process | Two people in the two roles |
| No Sprint Goal | A Sprint that is just a list of tasks | Agree on one goal at planning |
The Scrum Guide is blunt about it: “While implementing only parts of Scrum is possible, the result is not Scrum.” Each part is there to expose a problem early. Remove the part, and the problem grows where nobody looks.
The cost is real time. In Atlassian’s 2025 developer experience survey of 3,500 developers and managers, 50% said they lose 10 hours or more a week to organizational inefficiencies, and 63% said their leaders don’t understand their pain points. Retrospectives and reviews are where those pain points are supposed to come out. A team that skips them keeps losing the hours.
AI tools make this sharper in 2026. The 2025 DORA report sums it up: “AI doesn’t fix a team; it amplifies what’s already there.” A team with a loose Definition of Done ships AI-written code faster and breaks things faster. The Scrum Guide Expanded asks teams to treat AI as a supervised partner with clear human accountability for every outcome. “We use Scrum, but AI wrote it, so we skip review” is a new ScrumBut.
We think Scrum fits startups well, because short Sprints let a founder change priorities as the market answers. After 150+ delivered products, we treat it as a set of habits rather than a ritual. On HealthyNikah every Sprint ended with a live demo, so the client watched the app grow and could change priorities as we went. On Koncierge the founders asked for daily deployments, and we shipped every day.
A Sprint is only as good as its backlog. Our project estimate turns your brief into user stories. You confirm what is in scope, and every hour in the budget traces back to a story you kept. Uncheck a story and its hours come off. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour.
Those confirmed stories become the first Product Backlog, and the team sizes them again before the first Sprint, for example with planning poker. It is a planning range, not a fixed quote. You can run your idea through our project estimate in about four minutes.
Scrum is a lightweight framework for building products in short cycles called Sprints, one month or less. A small team with a Product Owner, a Scrum Master and Developers plans each Sprint, meets daily for 15 minutes, shows the result at a Sprint Review and improves its process at a Retrospective.
ScrumBut is a version of Scrum with a part removed to hide a problem the team finds too hard to fix. It follows the pattern “we use Scrum, but (reason), so (workaround)”, for example skipping retrospectives because they seem like a waste of time.
A change that hides a problem is. A short-term change made on purpose, written down, with an end date, can buy time to fix a real gap, such as test automation. Practices Scrum doesn’t require, such as pair programming, aren’t ScrumButs when you skip them.
Holding the Daily Scrum once a week, skipping retrospectives, running Sprints longer than a month and calling work done without tests. A 2023 survey found unfinished tasks at the end of the Sprint to be the most common anti-pattern.
Yes. The Scrum Guide puts a team at 10 people or fewer, and a small startup team can run every event in less time. What matters is keeping all the parts, especially a Product Owner who sets priorities and a Retrospective every Sprint.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.