2026-05-02

Make your standup a planning event again

Following on from A team I keep dreaming about. That piece described the whole team. This one is about one part of it: the daily standup. It is the smallest, most frequent meeting a team has and the one most often done badly. More pieces coming on culture, AI-enablement at every level of the organisation, the bits leaders cannot delegate. Standup first because if a team cannot get fifteen minutes right, the rest is theatre.

A mock-up of what the standup-update-agent posts overnight. Shipped and stalled, sprint goal trajectory, what the team will likely argue about. The single most useful line is the one most teams have never had: whether yesterday's work moved them toward the Sprint Goal or away from it. Generated by Author using Claude.

It is 9:07am on a Tuesday. The product owner is at her desk with a coffee that has gone cold because she has been reading the one-pager the standup-update-agent posted overnight. Plain English. What shipped, what stalled, where the sprint sits against the goal it committed to, what the team will probably argue about in the next fifteen minutes.

The engineering lead reads the same one-pager. So does the scrum master who sits across from them. So does the new graduate who started last Monday. Same view, same numbers, same time. Nobody is asking anyone to walk them through anything.

(Your team's standup might be at 11:30. It does not matter. The hour is not the point. The information landing before the meeting is the point.)

The standup starts at 9:15. Before they go to the work, they go to each other. How was the weekend. Did the surgery go alright. Did the kid sleep. Three minutes of being human, the way Aussie teams actually start the day. Then they go to the work.

Nobody gives a status update. Nobody says "yesterday I…". Everybody already knows what everybody did yesterday because the agent told them, with links to the commits and the tickets and the Slack thread where the support escalation came in at 11pm.

What happens instead is the actual conversation. The pragmatic-brutal-facts-agent has flagged three things in its overnight pass. The time it takes to get a pull request reviewed and merged has been creeping up all week. The work the team agreed to at planning has been changed mid-sprint twice this week: items added, items dropped, scope creeping on a couple of stories. Customer complaints have been piling up since Friday and nobody has been through the queue. The conversation goes straight to those three things.

The scrum master asks one practical question. Not the kind that puts the answer back on the team. "What changed last Tuesday?" The team thinks about it for ten seconds. Someone remembers. A merge policy got tightened to require two reviewers on every change. The merge-time creep tracks exactly to that change. They look at it together. The policy is not wrong, but the second reviewer has become the bottleneck. They agree to widen the reviewer pool today and revisit on Friday. Two minutes, decision made.

By 9:29 they have decided three things. Two front-end developers will pair on the merge-time issue today. The product owner will go and have an awkward conversation with the partner team about scope churn before lunch. The engineering lead will pull the support tail into the next refinement. Owners named, time-box agreed in the room. Nobody asks for a follow-up meeting because there is nothing to follow up on.

At 9:30 they go back to work.

. . .

What the Scrum Guide actually says

Here is the bit most teams have never read carefully. The 2020 Scrum Guide, which is still the canonical text, is direct about what the Daily Scrum is for:

"The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work."

It says it again, this time giving the team explicit permission to run the meeting however they want, as long as one thing comes out of it:

"The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work."

And one more, the line that gets ignored most:

"Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings."

Read those three lines in order. The Daily is a planning event. The team can run it however they like. Done well, it eliminates other meetings. The three-question round-the-room ritual most teams perform every morning, "yesterday I, today I, blockers", is not in the Scrum Guide. It has not been in there for years. It survived a deletion and most teams never noticed.

Notice what the Guide says three times: the Sprint Goal. Not tickets. Not velocity. Not yesterday-today-blockers. The meeting is supposed to inspect progress toward the Sprint Goal and produce a plan to keep the team moving toward it. Most teams have a Sprint Goal sitting somewhere in their planning notes and never look at it again until review. That is the cracked foundation. Everything else in the standup is built on it.

Most teams have never run the Daily as a planning event. They have run it as status theatre with a fifteen-minute timer.

Why it stopped being a planning event

The reason has nothing to do with discipline. It is information.

To produce an actionable plan for the next day of work, the people in the room need to know where the work actually is. They need to know what shipped overnight, what is stuck in review, what broke at 11pm and got patched at 1am, and what the partner team did to the contract while everyone was asleep. Without that information, planning is impossible, so the meeting fills with the only thing left to do: ask each person what they did and what they will do next.

Round-the-room status is not a culture problem. It is a workaround that became the meeting. The information needed to plan is scattered across a dozen tools and owned by different humans. The only way to get it into the room used to be asking each human to read it out. By the time everyone has been heard, the fifteen minutes are gone.

This is where AI agents earn their keep.

The two agents, what they do, what they do not

The team in the scene at the top runs two agents. Both of them sit underneath the standup, not inside it.

The standup-update-agent writes the overnight one-pager. It reads the team's repo, ticket system, and chat. It produces one document before 9am: what shipped, what stalled, where the team sits against the Sprint Goal, what the agent thinks the team will probably argue about today. Plain language. Linked to the commits and tickets. Same document on every desk. The information that used to live in twelve different humans is now in one place before anyone speaks. By 9am the team also knows whether the work of yesterday moved them toward the Sprint Goal or further from it. That single line is the one most teams have never had.

The pragmatic-brutal-facts-agent does the trend work. It does not summarise yesterday. It watches the patterns: merge-time creep, mid-sprint scope changes, the queue of customer issues nobody has touched, the metrics drifting against the team's own baseline. It surfaces what is moving in the wrong direction before the retro would have caught it. By the time the team walks in, the agent has already made it impossible to ignore the things last sprint's standup would have skipped.

The pragmatic-brutal-facts-agent's overnight output. It does not summarise yesterday and it does not list tickets. It watches four kinds of pattern: trends drifting now, anti-patterns repeating across sprints, commitments the team made and quietly dropped, and metrics being optimised the wrong way. Posted before 7am so the team sees it before they walk in. The agent does not raise the alarm. It just makes it impossible to ignore. Generated by Author using Claude.

The agents are only as honest as your data. If your data is gamed, the agents are gamed too. The agents make the team's reality visible by 9am every morning. But if the data going in is gamed, what they show is gamed. If "done" means different things on different tickets, the agent reports the gamed definition. If story points are inflated to make velocity look better, the agent reports the inflated number. If support tickets are closed without anything actually being fixed, the queue looks clean when it is not. The work of agreeing what "done" means, keeping the data clean, and refusing to game the numbers belongs to the humans. The agents just make it harder to do that work badly without anyone noticing. Garbage in, garbage out, just at higher resolution and posted before 9am.

Two agents. Two distinct jobs. No overlap. They are tool-agnostic. You can build them on top of whatever you already use.

What this is not

The agents do not run the standup. They do not facilitate. They do not make decisions. They do not replace the Scrum Master, the delivery lead, the engineering lead, or anyone else with a name and a salary. They write. The humans read, talk, and decide.

That distinction is the load-bearing one. AI replacing the standup would be a worse meeting, not a better one. AI feeding the standup gives the humans back the fifteen minutes the Guide always intended them to use for planning. And if the standup runs to seventeen or eighteen minutes some days because the team is in a real conversation about the Sprint Goal, that is the meeting working, not failing. The fifteen-minute time-box is a guide. It is not a verdict. Which is why what follows is mostly about the humans, not the agents.

A practical framework you can try next sprint

Five steps. Concrete. Doable in two weeks.

Agree your Sprint Goal first, then agree what the standup is for. A standup that does not know where the team is heading becomes a status meeting by default. Read the three Scrum Guide quotes above out loud at your next retro. Ask the team two questions. Do we have a Sprint Goal we can actually measure progress against today? Have we ever produced an actionable plan for the next day of work in our standup? If the answer to either is no or rarely, you have your starting point.

Build the standup-update-agent first, not both at once. Start with this one because the output is the more concrete of the two and the team will trust it faster. It needs read access to your code repo, your ticket system, and your team chat. The output is one short document a day. Keep it simple. The first version will be ugly. Run it for a week before changing anything.

Treat the agents like a team capability, not a side project. This is the line every team gets wrong. One engineer cannot own this on the side. Build it the way you would build your CI pipeline: jointly owned, monitored, on-call when it breaks. If the agent goes down on a Tuesday morning, the standup goes back to status theatre that day. Decide who covers that.

Change one rule in the standup. No status updates. If anyone says "yesterday I…", the meeting moves on. The information is on the page. The meeting is for what the page surfaced. This is the smallest change that produces the biggest effect.

Review on Friday. End of the first week, ten minutes. Did the meeting end with a plan? Did it surface real issues? Did anyone read the agent's update before walking in? Adjust. Do not add anything new in week one. The discipline is the work.

I reckon most teams that try this honestly will know by the end of week two whether it is going to land. You will not get it right the first time and you might not get it right the first few times. Give it a go anyway. Moving in the right direction is the work.

. . .

What you might see and what to look at if you do not

If it is working, the meeting ends with three to five owned actions on most days, the merge-time conversation moves earlier in the week, and the calendar around the standup gets quieter because the follow-up meetings stop getting booked. People stop dreading the standup. They will not say it out loud but you will see it in their faces.

If it is not working, look at three things in order. First, is the agent's update actually good? Read it as a human and ask if it would tell you what you needed to know. If it is generic, the prompt is the problem, not the team. Second, are people reading it before the meeting? If they are reading it during the meeting, the standup is just a slower version of itself. Move the trigger earlier or make the document shorter. Third, are decisions actually getting made? If the team keeps deferring to "let us discuss after the standup", the room does not feel safe enough to decide in front of each other. That is a culture problem, not an agent problem. No tool will fix it. (That is the half I will write about next.)

The team in the scene at the top did not run a transformation program to get there. They did not hire different people. They did not put a poster up. They changed how information moves through their day. The rest of the dysfunction had nowhere to hide.

That standup is buildable. Right now.

Salam.

P.S. If your team is in the middle of trying this and you want a sounding board from someone who is also figuring it out, I am a message away.

P.P.S. With chai and love.