The agent finished the task yesterday afternoon. The diff looks fine, the test suite ran, and the PR is nearly ready. At standup your turn comes, and someone asks how the item is going. You open git, scroll through the file list and start talking: "I touched the payment service, a DTO, a couple of tests…"
Nobody in the meeting could repeat what changed, and you couldn't either. Reading the agent's commit message out loud isn't a standup update. You're just reading metadata to people.
The habit in this article is small, and you can check whether you did it. Before you push, or before the meeting, close the diff and tell the change once using four fields: intent, area, risk and verification. If you can't do it without reopening the file, you've learned something important. Better to learn it before you open the PR than halfway through the meeting.
What the Daily Scrum actually asks for
The November 2020 Scrum Guide describes the Daily Scrum as "a 15-minute event for the Developers of the Scrum Team." It also states the purpose: "to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work."
None of that asks for a file inventory. The Sprint Backlog holds the Sprint Goal (the why), the selected items (the what) and an actionable plan for delivering the Increment (the how). The Daily Scrum checks progress against those three. A list of the classes the agent touched tells nobody whether the team got closer to the goal.
It isn't a status report for a manager either. The event belongs to the Developers. The Product Owner and Scrum Master take part as Developers only when they're working on Sprint Backlog items. The revisions page shows that this was already an issue in 2013, when that revision reinforced the Daily Scrum as a planning event because teams kept treating it as a status meeting.
You can also retire an old habit. The 2020 version removed the three Daily Scrum questions: what did I do yesterday, what will I do today, and what's blocking me. The same revisions page lists the removal among the changes from 2017 to 2020, under "Even Less Prescriptive." The 2017 Guide offered the questions only as an example. The current Guide lets the Developers pick their own structure and techniques, as long as the Daily Scrum focuses on progress toward the Sprint Goal and ends with an actionable plan for the next day.
Because the team chooses the structure, the template below is an option the team can adopt. It isn't a rule.
A 60-second template for your turn
| Field | Question | What doesn't count |
|---|---|---|
| Intent | What behavior changes, and why, relative to the Sprint Goal? | "The agent touched three classes" |
| Area | Where does the change reach, and where does it not? | A list of file paths |
| Risk | What breaks if your assumption is wrong? | "Probably nothing" |
| Verification | How did you check it, or how will you? | "The agent already tested it" |
The 60 seconds is a DevDojo editorial rule of thumb for one speaker, so the whole team still fits inside 15 minutes. It isn't a Scrum rule, an ISO standard or a study finding. The Daily Scrum is still 15 minutes long. Only your turn is one minute.
Here's a spoken update that covers all four fields:
> "For the stable-checkout Sprint Goal: the intent is to reject a duplicate payment on retry. Area: the checkout capture flow, not fraud detection. Risk: blocking a legitimate order after a timeout. Verification: I reproduced the retry in staging, and the second POST doesn't capture."
That takes about twenty seconds, which leaves time for somebody to ask a question. Look at what it leaves out: class names, the number of files, and the sentence the agent wrote in the commit.
What stays yours when the agent did the typing
The agent writes the code. Four things are still yours:
- the why behind the change;
- the blast radius, meaning what else could be affected;
- verification and rollback: how you know it works, and how you back it out if it doesn't;
- the decision to ship.
The Linux kernel documentation on tool-generated content puts it plainly: "You are expected to understand and to be able to defend everything you submit. If you are unable to do so, then do not submit the resulting changes." That's process guidance for one project, not a legal argument. It's quoted here for one simple point: understand the change and be able to defend it, or don't send it.
Google's engineering practices on CL descriptions ask the description to explain what changed and why, with a first line that makes sense on its own. Your standup turn is the spoken version of that, with risk and verification added. A file list or a pasted agent message is worth about as much as a description that says "Fix bug."
In practice, the sentence you need to be able to say sounds something like this:
> "The diff is the agent's; the decision to open the PR is mine. The risk is a double capture, and the verification I accept is the retry reproduced in staging."
The agent doesn't attend standup for you. When a teammate asks "what if it fails?", the answer has to come from you, without opening the tool's transcript. That question is good at exposing a neat "done" story from someone who can't name the risk yet.
Today's test: say it once before the push
In the piece on reviewing code without rereading on autopilot, the exercise was reading your own diff in silence. This exercise is the reverse: talk through the agent's change with the diff closed.
Before you push, or before the meeting:
- Close the diff, the terminal with git log in it, and the agent conversation.
- Say the four fields once, out loud or to a teammate: intent, area, risk and verification.
You fail if you reopen the diff, list file names, or read the agent's commit message.
You pass if the listener can repeat all four fields without looking at git.
The most common mistake is making standup your first rehearsal. That's when you most want to reopen the diff, with the whole team waiting, so you end up scrolling through files while the round stalls on your name. Practice beforehand. A teammate at the next desk or a two-minute call is plenty.
If your team is still deciding what the agent may do in the repository, that's a separate problem with a separate answer: repository gates before the first agent PR. This habit applies with or without gates, because it's about what you can explain.
When the honest answer is "I'm still investigating"
Sometimes you close the diff and the risk just won't come to you. That doesn't mean you failed the test. Failing means making up a "done" so the round keeps moving.
This line passes:
> "I'm still investigating the retry on timeout; the risk is a double capture; the planned verification is reproducing two POSTs in staging before I open the PR."
All four fields are still there. "Investigating" is your intent and your status, not filler. The team leaves knowing what's missing and can adjust the day's plan, which is the whole purpose of the Daily Scrum. The Guide has names for this among its values: Openness ("The Scrum Team and its stakeholders are open about the work and the challenges") and Courage ("to do the right thing, to work on tough problems"). Knowing that your understanding is incomplete is still information about progress.
DevDojo's recommendation is conditional and firm: open the PR only when you can fill in all four fields without reopening the diff. If you can't, your standup line is "I'm still investigating," and the PR waits. It's the kernel rule applied to a meeting: if you can't defend it, don't submit it.
If your team adopts the template and standup turns into people reciting a form, or it starts running past 15 minutes, drop the template. The Developers choose the structure, and the template is worth keeping only while it helps them inspect progress.
Next step
Today, pick the agent PR that's closest to being pushed. Close the diff and explain the change once to someone. If they can repeat intent, area, risk and verification without looking at git, push it. If they can't, your line for tomorrow's standup is ready: "I'm still investigating."