Erik van der Pluijm's Post
Erik van der Pluijm · article · 2026-10-08 source ↗ Reader 🖥️
When Claude Code collapses the time to build software, the 2-week sprint (and the ceremonies and metrics built around it) stops fitting, but this doesn't mean Scrum has failed — because Scrum was always about empiricism (tight feedback loops of inspect-and-adapt), not about sprint length, so the right response is to compress the cycle to 2 days, drop effort-based metrics (story points, velocity), and replace them with a recurring value judgment ('should this ship?').
practical · mixed — A LinkedIn post reporting a concrete process change (2-week Scrum sprints replaced with a 2-day cycle) in response to AI-accelerated coding, framed around a general claim about what in Scrum survives that acceleration.
Structure
| Part | Role |
|---|---|
| Problem statement: standups and refinement break down once a team is 'busting bugs and hammering out features' with Claude Code; the 2-week sprint becomes a joke | setup — names the symptom |
| Concrete alternative: a 3-day cycle (Day 0: pick 2-3 objectives, not tickets; Day 1: build, no standup, continuous status; Day 2: demo what IS, feature-gate decision) | evidence — the practical response, presented as 'what we've been trying' |
| Claim: story points and velocity tracking are abandoned; anything measuring human effort dies, anything focused on value judgment survives | generalization from the practice |
| Aphorism: 'Free code is the mother of all feature creep. When building is trivial, discipline becomes the bottleneck.' | diagnosis — names the new bottleneck |
| Reframing: 'Scrum was never about 2-week sprints. It was about empiricism. That doesn't die — it accelerates.' | conclusion — defends Scrum's core while discarding its default cadence |
Key terms
- Feature Gate
A recurring decision point ('should this ship?') that replaces sprint review/retro as the team's governing checkpoint — a value judgment rather than a progress report. - empiricism (in Scrum)
The inspect-and-adapt feedback loop that Scrum was designed to enable, independent of any specific cadence length.
Propositions
- explicitStandard Scrum ceremonies (standups, refinement, 2-week sprints) break down once an AI coding agent accelerates implementation, because the ceremonies were calibrated to pre-AI build speed.conf: high
- explicitA 2-day (3-phase: plan, build, demo/gate) cycle better fits AI-accelerated build speed than a 2-week sprint.conf: highsupportsNo, AI Did Not Kill Agile · p4 — Van der Pluijm's concrete 2-day cycle is a direct practical instance of the claim that the rational response to cheaper building is to iterate more frequently, not to stop iterating.
- explicitMetrics that measure human effort (story points, velocity) stop being useful once AI does most of the building, while metrics focused on value judgment remain necessary.conf: high
- explicitWhen code generation is nearly free, the main risk shifts from being unable to build features to building too many of them (feature creep), making discipline — deciding what NOT to build — the binding constraint.conf: high
- explicitScrum's defining, durable property was never its default cadence (the 2-week sprint) but its empiricist feedback loop (inspect and adapt), and that loop remains valid — indeed becomes more valuable — as build speed increases.conf: highsupportsNo, AI Did Not Kill Agile · p1 — Both independently separate the speed question (how fast you build) from the knowledge/empiricism question (how you learn what to build), concluding AI changes the former without eliminating the need for the latter.
- implicitThe length of a Scrum sprint is a parameter to be tuned against build/learn cycle time, not a fixed convention; a team should choose its cadence deliberately rather than default to 2 weeks out of habit.conf: medium
Arguments
Teams whose build speed has been accelerated by AI coding agents should shorten their iteration cycle and replace effort-based tracking with a recurring ship/no-ship value judgment, rather than either keeping the old cadence or abandoning Scrum's discipline altogether. strength: medium
Explicit premises:
- Claude Code has sped up implementation enough that 2-week-sprint ceremonies no longer fit the pace of work.
- Scrum's actual value was always the empiricist feedback loop, not any particular cadence.
- Effort-measuring metrics (story points, velocity) lose their point once effort itself is no longer the bottleneck.
Implicit premises:
- A shorter cycle (2 days) is itself a form of inspect-and-adapt, just compressed, rather than a departure from Scrum's principles.
- A 'should this ship?' judgment call is a sufficient replacement for effort-tracking as the team's governing control mechanism.
Inferences:
- If build speed keeps increasing (further agentic acceleration), the appropriate cycle length should keep compressing further, with no principled floor other than the time needed to make a meaningful ship/no-ship judgment.
Questions addressed
- ✅ Does AI-accelerated coding make Scrum/Agile obsolete?
No — it makes Scrum's specific cadence (2-week sprints) and effort-based metrics obsolete, while making its empiricist core more relevant, not less. - ✅ What replaces effort-based tracking (story points, velocity) once AI does most of the implementation work?
A recurring value judgment — a 'Feature Gate' asking 'should this ship?' — rather than any new quantitative proxy.
Gaps
- incompleteThe post asserts 'anything focused on value judgment survives' but gives no account of who makes that judgment, on what basis, or how to prevent it from degrading into the same gameable, effort-disguised-as-value proxy that story points became — i.e. it names the right kind of metric (value, not effort) without addressing how to keep a value judgment itself honest and well-calibrated over repeated 2-day cycles.
Read next: Read against the corpus's broader treatment of proxy validity and Goodhart's Law for AI-era engineering metrics (extract-8-engineering-metrics-ai-broke and related) for frameworks on how teams keep qualitative/value-based signals from degrading the way quantitative ones did. - incompleteThe 2-day cycle is presented from the inside of a single, apparently small team ('we've been trying'); the post doesn't address whether a 3-day cadence (plan/build/demo) scales to multiple interdependent teams, where cross-team dependencies, shared architecture decisions, and release coordination historically required longer sprint boundaries to synchronize.
Read next: Cross-read against the corpus's coordination-cost and multi-team scaling material to test whether compressed cycles survive beyond a single small team.
Closes gaps elsewhere
- Running Python code in a sandbox with MicroPython and WASM · g5 — This post is an empirical instance of the exact concern that gap raised (cheaper building makes the discipline problem worse, not better) and supplies the team-level response the earlier material lacked: drop effort metrics, keep a recurring explicit value/ship judgment as the discipline mechanism.