# Do We Still Need Sprints? Agile in the Agentic Era
> Burndown and velocity measured developer effort, and agents have made that meaningless. Which agile ceremonies survive the agentic era, and what they become.

*23 October 2026* · Jamie Taylor


In [the first of these two posts](/blog/measuring-value-in-the-agentic-era/) I argued that we are measuring the wrong thing. When an agent manufactures the code and a person directs it, developer effort stops being a useful measure of anything, and the metric that matters becomes value delivered: useful features in the hands of the people who use the software. If you have not read it, the short version is that an estimate was always a proxy for how clearly the work had been specified, and agents have made that impossible to ignore.

This post is about the wreckage that argument leaves behind. If the estimate has lost its meaning, then so has most of the ceremony we built on top of it. Sprints, burndown charts, velocity, planning poker, the fortnightly ritual of turning work into points and points into a chart: all of it grew up around the assumption that developer effort is the unit you plan and track. Pull that assumption out, and the scaffolding does not stay standing on its own.

So the question I want to answer is a practical one for anyone who runs a team. Which of these rituals survive the agentic era, which need retiring, and what do the survivors turn into? Here are my short answers, which I will spend the rest of the post defending: burndown and velocity should go; sprints and retrospectives survive, but they change shape; and the standard you hold everything to goes back to something the people who wrote the Agile Manifesto would recognise.

## The Ceremony Was Always Scaffolding


It helps to remember what all this ritual was for in the first place, because the purpose tells you what to keep. Most of it, the sprints, the velocity, the planning poker, the retrospective, is Scrum, the framework that became most teams' default way of "doing agile"; so "do we still need sprints?" is really the question of whether we still need Scrum in its current shape.

Agile ceremony exists to answer a small number of real questions. How much can we take on before we overcommit? Are we on track to deliver what we promised? What is getting in our way, and how do we get better at this? Those are good questions, and teams genuinely need answers to them. The trouble is that we answered most of them through a single proxy: estimated effort. Capacity became velocity. "Are we on track" became a burndown chart. The questions were sound; the instrument we reached for was developer time, sliced into story points.

The Agile Manifesto, for its part, never asked us to do that. Its authors were quite specific about what progress was supposed to mean.

> Working software is the primary measure of progress.
>
> — The Agile Manifesto, [Principles behind the Agile Manifesto](https://agilemanifesto.org/principles.html)


Working software. Not points, not velocity, not the area under a burndown curve. Somewhere in the two decades since, a great many teams swapped the primary measure for the proxy, because the proxy was easier to put on a chart and the manufacturing was slow enough that effort and progress looked roughly the same from a distance. Agents have pulled those two things apart, and the gap between them is now too wide to paper over.

## Burndown and Velocity Have to Go


I will start with the two I think are beyond saving, because the case is cleanest there.

Velocity is the average number of story points a team completes in a sprint, and a burndown chart plots that same currency against time. Both depend on story points meaning something, and a story point is a measure of effort and complexity: a rough, deliberately fuzzy expression of how much human work a piece of development represents. That is the number that no longer holds. When an agent does the manufacturing, the effort involved is not human time; it is some mix of how clearly you specified the work and how much model capacity you were willing to spend on it. Ask how a story point is supposed to map onto the number of tokens an agent burns through, and the question answers itself. It does not map at all.

So what does a velocity figure measure once agents are doing the building? At best, nothing useful. At worst, it measures spend, for the reason I set out in the first post: the team that closes the most points is often just the team with the largest inference budget. I called that tokenmaxxing last time, the mistake of treating visible consumption as visible value, and velocity is the metric most likely to smuggle it back in through the side door. Keep score by velocity in an agentic team and you are, in effect, rewarding whoever spent the most while calling it throughput.

There is a softer objection too, which is that these charts were always a little bit of theatre. Plenty of teams already knew their velocity was a number massaged to look reassuringly stable for the people upstairs.

I once worked with a five-person team whose lead ran every estimation session against two hard caps: no more than twenty-one story points in a sprint across the entire team, and no single task larger than eight. He kept a running tally during planning poker, and the moment the total crept past twenty-one, or a task came in at a thirteen, the team re-estimated until the numbers fit. Twenty-one points shared across five people for a two-week sprint comes to a little over four points each; that was the entire budget any one engineer could be estimated against in a fortnight, regardless of what the work in front of them required. Sit with what that does. A piece of work that plainly felt like a thirteen was never sent back to be specified more tightly, which would have been the healthy response. It was re-estimated downward until it read as a seven, because the cap was the rule and the estimate was the thing that had to give. The points had stopped measuring the work and started measuring compliance with an arbitrary ceiling. It is Goodhart's Law in its purest form: the cap became the target, and the measure stopped meaning anything in order to satisfy it. That team has not adopted agentic development yet, which is the part I find telling. The currency was already hollow; agents do not introduce the rot, they only make it impossible to keep ignoring.

Agentic development removes the last shred of pretence that velocity was measuring engineering effort, and leaves you holding a chart that tracks your model bill. Put it down.

## But How Do I Forecast Without Velocity?


The first objection I hear when I say velocity should go is a fair one: it was how we forecast. If a stakeholder asked when something would be done, velocity gave you at least a defensible-sounding answer. Take it away and the worry is that you are left shrugging at the people who fund the work.

I would question how good that forecast ever was. A velocity-based date was an extrapolation from a fuzzy effort number multiplied by a team's recent average, hedged with all the usual caveats about being indicative and subject to change. It felt precise because it arrived with a chart. It was rarely as reliable as the chart implied, and anyone who has watched a "two sprints away" feature slip for a quarter knows the feeling.

What replaces it is less a single number and more a straight conversation about the two things that now drive delivery. The first is how clear the specification is. A feature with a sharp, agreed specification is close to done, because the manufacturing is fast once the intent is settled. A feature that is still vague is not close, however small it looks, because the slow part is the deciding, not the building. The second is decision latency, which I will come back to: how quickly your organisation can answer the questions the work throws up. Forecast against those two and you will be roughly right; forecast against velocity and you will be precisely wrong. For a decision maker, "this feature is one good specification session away from shipping" is a far more useful sentence than "it is five points and our velocity is twenty," because it tells you what to do to bring the date closer.

## Sprints Survive, But the Question Changes


Sprints are a different matter, because the time-box is useful for reasons that have nothing to do with story points.

A regular cadence gives a team a heartbeat. It creates a predictable moment to look up from the work, show what exists, take a decision, and reset direction. Stakeholders get a rhythm they can plan around. None of that depends on counting effort; it depends on having a recurring boundary where you stop and ask how things are going. That boundary is worth keeping.

What changes is the question you ask at it. The old sprint boundary asked "how many points did we complete, and how many can we commit to next time?" The agentic sprint boundary asks something more honest and more useful: "how close are we to shipping this feature, is it turning out to be genuinely useful, and what have we learned that changes the plan?" The unit of the conversation becomes the feature or the epic, exactly as it did for planning in the first post, rather than a column of tickets. You are using the cadence to steer towards useful output, not to reconcile an effort budget.

That reframing changes the texture of planning and review in a way I find healthier. Planning stops being an auction where everyone argues about whether something is a three or a five, and becomes a conversation about which features are worth building next and whether their specifications are clear enough to hand to an agent. Review stops being a demo staged to prove the points were real, and becomes a straight look at whether what shipped helped anyone. The ceremony stays; the accountancy leaves.

## The Standup Changes Too


The daily standup deserves its own mention, because in most teams it has drifted into being a status meeting, and status is the thing agents make least interesting.

The traditional three questions, what did you do yesterday, what will you do today, and what is blocking you, were always partly a progress check: a way of confirming that effort was being spent in roughly the right direction. The first two lose their point when an agent did most of the doing and the doing was fast. Nobody needs a person to stand up and report that the agent built the thing they briefed it on. What remains, and what becomes the entire purpose of the meeting, is the third question. What is blocking you?

In an agentic team the honest answer is usually some version of "I do not have a clear enough decision to brief the agent properly." The standup becomes the place where those blockages surface quickly, while they are still cheap to clear, rather than festering for a fortnight until the retrospective. Run well, it stops being a recitation of activity and turns into a short daily scan for missing clarity and unanswered decisions. That is a meeting worth keeping, because it goes after the new bottleneck at the speed the bottleneck actually moves.

## Retros Matter More, Not Less


If there is one ceremony I would protect and expand rather than trim, it is the retrospective, because it becomes the main engine of learning in a team where the typing is automated.

Retros have always been where a team gets better at its own process. In an agentic team there is far more process to get better at, and most of it is new. How do we write a specification an agent can act on without endless back-and-forth? Which of our guardrails caught real problems, and which just slowed us down? When the agent confidently did the wrong thing, what in our brief led it there? These are teachable lessons, and the retrospective is where you turn one engineer's hard-won discovery into something the whole team knows. I trained the engineers at [Ligentia](/case-studies/higher-quality-shipped-faster-ai-adoption-at-ligentia/) in a spec-driven workflow built on [GitHub's spec-kit](https://github.com/github/spec-kit), and the ones who improved fastest were the ones who treated every awkward result as a lesson about the brief rather than a failure of the tool.

There is a second kind of lesson that matters even more, and it is the one I would build the new retrospective around. It sounds like this: "we pushed back on this feature five times before the specification was clear enough to build." That is not a complaint to be smoothed over. It is the single most valuable piece of process intelligence an agentic team can capture, because it tells you precisely where your intent is failing. A retro that surfaces "we kept going back to the product owner because nobody had decided what archived actually means" has found the real bottleneck, the one I argued in the first post has moved upstream to the people who specify the work.

If I were standing up an agentic team's retrospective from scratch, I would put one recurring question on the board: where did we have to go back and ask for clarity this iteration, and why? Gathered over a few cycles, the answers draw a map of exactly where your specifications keep breaking down, and that map is worth more than any velocity trend ever was.

This is also where the [shift from author to editor-in-chief](/blog/from-author-to-editor-in-chief-the-shift-thats-already-here/) that I have written about becomes concrete. A review that asks "why did the agent make this choice, and was it the right one?" builds exactly the critical thinking I said would become the scarce skill. Retrospectives are where a team practises that habit out loud, together, on purpose. Cut them to save time and you have cut the one meeting that was making you better at the only part of the job that is still genuinely hard.

## What to Track Instead


It is one thing to take two metrics away and quite another to leave a team with nothing to point at, so here is what I would put in their place.

Start with the obvious one, carried over from the first post: useful features shipped. Count the things you put in front of users that helped them, and treat that as the headline figure. It is harder to game than velocity, and it reflects the reason the team exists.

Then add two leading indicators that tell you about the new bottleneck. The first is how often work bounces back for clarification before an agent can start on it. If your engineers are repeatedly returning features to be specified properly, that is not them being slow; it is your intent pipeline showing you where it leaks. Track it as a diagnostic, never as a stick to beat the people raising the flags. The second is decision latency: how long it takes, once an engineer asks a clarifying question, for someone with the authority to answer it to actually do so. In an agentic team that number is often the real constraint on delivery, and almost nobody measures it.

And keep the measures that were never about effort to begin with. The four DORA keys, deployment frequency, lead time for changes, change failure rate, and time to restore service, measure flow and stability rather than human exertion, which is exactly why they come through the transition intact. I have helped teams stand up [DORA dashboards](https://dora.dev/) that gave their leadership an honest read for the first time, and none of that work is undone by agents doing the building; if anything, the case for measuring outcomes over activity only gets stronger. It is the same point I closed the first post on, and it bears repeating: the instruction is to measure differently, not to measure less.

One caution, because it applies to every measure in this post: the moment you turn any of these into a target with a number attached, Goodhart's Law starts working against you again, just as it did with velocity and the point caps I described earlier. Push-back rate is a smell to investigate, not a quota to drive to zero; force it to zero and you will simply teach your engineers to stop pushing back. Hold these numbers loosely, as prompts for a conversation rather than scores to optimise, and they will keep telling you the truth.

## This Is Not Permission to Abandon Process


I want to head off a misreading, because it is the dangerous one. Telling you to retire velocity and burndown is not telling you to drop discipline. It is the opposite. Agentic development without structure is just vibe coding at scale, and I have been consistent that the two are nothing alike; the [foundations of a serious agentic workflow](/blog/agentic-development-foundations/) are about more rigour, not less.

What I am arguing for is to move the rigour to where the risk now lives. Specifications, review, and the quality of decisions need more attention than ever, because they are where the value and the mistakes now come from. Effort accounting needs none, because the effort is no longer the thing at risk. A team that hears "we don't need velocity" and concludes "we don't need process" will get the worst of both worlds: the speed of agents with none of the guard rails to keep that speed pointed somewhere useful. Keep the discipline. Move it to where it earns its keep.

## Ceremony Should Serve the Work


Underneath all of this sits a single principle, and it is one I was repeating to developers long before any of us had an agent to argue with.

We are not hired to write code; we are hired to solve problems using technology. The code was always a means to that end, and so was the ceremony around it. A sprint, a retro, a burndown chart: each is a tool, justified only by whether it helps a team ship useful solutions and have candid conversations about how that is going. The moment a ritual exists to produce a number for a slide rather than to help the work, it has stopped earning its place, and that was as true in 2010 as it is today.

The danger in the agentic era is that we keep the rituals out of habit while the thing they measured evaporates beneath them. A team can carry on running planning poker and updating a burndown long after both have stopped meaning anything, because the calendar invite still exists and nobody has paused to ask why. The healthier move is to treat the agentic shift as a reason to do what we should have done all along: keep the ceremony that serves the work, drop the ceremony that serves the chart, and stay clear-eyed about which is which.

Taken together, the two halves of this argument are simple enough to fit on one line. Stop measuring developer effort, because agents have cut its link to value; start measuring useful work delivered; and let the ceremony reshape itself around that, keeping what helps you steer and discarding what only ever produced a number. The teams that make that shift will spend their meetings talking about whether they are building the right things, which is the conversation that was always meant to matter.

If you are working out which of your team's rituals still earn their place now that agents are doing the building, [a consultation is a good place to start](/schedule-consultation/).