The daily standup is fifteen minutes. It is the shortest ceremony in the sprint cycle and the one with the highest ratio of complaints to duration. Most of the complaints are legitimate, and they cluster around three patterns that are distinct enough to be worth naming separately. The first is the status report disguised as a standup. Each team member addresses the scrum master or manager rather than the team, describes what they did yesterday and what they will do today, and waits for the next person to do the same.

The conversation about AI in software development tends to collapse into two positions: either AI will replace developers, or AI is just a faster autocomplete. Both positions avoid the more interesting question, which is about the specific category of decisions that cannot be delegated and why. Some decisions remain irreducibly human not because the technology is insufficient but because the decision requires accountability, context, and judgment that exist outside the codebase.

The definition of done is one of the more underrated concepts in agile practice. A shared, explicit, team-level agreement on what it means for a story to be complete is the mechanism that prevents the slow accumulation of almost-done work that eventually freezes a sprint. Without it, done means different things to different people, and the gap is always paid for later. AI-assisted development introduces a new category of questions that most teams’ definitions of done do not yet address.

The product owner in scrum is responsible for maximizing the value of the product resulting from the team’s work. The Scrum Guide is admirably concise on this point and deliberately silent on how it is achieved, because how it is achieved depends entirely on the product, the organization, and the market. What the definition does not convey is the difficulty of the role when it is done correctly. The product owner must maintain a clear product vision, own a prioritized backlog that reflects that vision, be available to the team for clarification during the sprint, and make decisions about scope and trade-offs in real time.

The scrum master role is routinely reduced to meeting facilitation and impediment tracking. The scrum master runs the standups, schedules the retrospectives, maintains the board, and removes blockers that the team surfaces. Done well, this produces smooth ceremonies and a team that is not visibly impeded. It does not produce the organizational change that agile practice requires to sustain value over time. The Scrum Guide defines the scrum master as responsible for the team’s effectiveness and for helping everyone understand scrum theory and practice, both within the team and across the organization.

The sprint goal is a single objective that the team commits to achieving through the sprint. It gives the sprint coherence — a reason the sprint backlog is the particular collection of items it is, rather than an assortment of the next highest-priority tickets. It gives the team a basis for decision-making during the sprint when unexpected complexity arises. And it gives stakeholders something to understand about what the sprint is for beyond a list of story numbers.

The sprint review is consistently misunderstood as a presentation event. The team demonstrates what was built, stakeholders applaud or raise concerns, and everyone moves on to the retrospective. Run this way, the review produces polished demos and no feedback that the team can act on. It is theater with a product backlog. The sprint review is a working session. Its purpose is inspection and adaptation at the product level: the team shows what was built, stakeholders engage with it substantively, and the conversation that follows informs the backlog.

The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives. Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened.

Velocity was designed to answer one question: given what this team has delivered in recent sprints, how much should we expect it to deliver in the next one? It is a forecasting input, calibrated to a specific team’s specific definition of a story point. It is not a measure of productivity, engineering quality, team health, or business value delivered. Using it as any of those things produces outcomes that are reliably bad.

Velocity was always a flawed proxy for progress. Teams learned to game it, inflate it, and defend it in ways that had little to do with delivering value. AI-assisted development has not fixed the underlying problem — it has made it worse, and in doing so forced a more honest conversation about what sprint planning is actually for. When individual developer throughput increases significantly — and for many teams working with AI coding tools, the increase in raw output is real — the assumptions baked into story point estimation break down.