AIND covers only the approach to development – from need through specification to reviewed code – but not who takes on which tasks, what is agreed and released, how sprints are planned, and how the task backlog is managed. This coordination takes place where teams organize it: in Jira or a comparable tool. Nevertheless, coding agents change not only the implementation but also the teamwork.

What Becomes of Scrum?

Coding agents will undoubtedly change agile collaboration. When a larger part of implementation shifts to agents, the cadence, the roles, and the shape of tasks change fundamentally. How strongly and in which direction, however, no one can predict precisely today.

For precisely this reason, it would be a mistake now to impose a new, AI-focused coordination mode from above. The better path is evolutionary: dock onto existing collaboration, supply it with better information, and observe where the collaboration model actually changes. That is the agile principle applied to itself.

The Bottleneck Moves to Coordination

When coding agents accelerate implementation, the shares of the work shift. The effort for code generation decreases, while the effort for specification, coordination, and review takes up relatively more space. This changes the granularity of collaboration. Tasks must be specified more clearly and prepared in a more decision-ready state before an agent can sensibly build code. Acceptance criteria, assurances, dependencies, and open questions must be clarified earlier. A ticket that was previously sharpened by experienced developers during implementation now must be understood more thoroughly before implementation.

This change is not culturally trivial. Many developers have so far drawn their productivity precisely from solving technical problems in concentrated fashion over a longer period. Now, a larger share of their value creation lies in communicative work – specifying, clarifying queries, documenting decisions, reviewing.

Precisely for this reason, AI must not stop at code generation, but must also support collaboration – not as a substitute for coordination, but by preparing it, condensing it, and making it more decision-capable. What this looks like in the individual Scrum ceremonies is shown by the next section.

The Focus of Scrum Shifts

Scrum ceremonies do not become superfluous with coding agents either, but their weight lies differently.

In Refinement, AI can help identify unclear tickets and clarify questions such as: is the domain intent clear? Are acceptance criteria missing? Are there open decisions? Is the task described in such a way that an agent can sensibly work with it? And above all: AI must support conveying the relevant information comprehensibly, at a level of abstraction that is appropriate for the new approach. No longer at the level of technical details, but at a conceptual level.

In Planning, AI can mirror the planned work against dependencies, risks, and specification maturity. It does not decide what goes into the sprint, but it makes visible which tasks are not yet decision-ready or which assurances are missing.

In the Daily, AI can generate concise work status from AIND artifacts, status changes, and commit messages: what has been begun, what is blocked, which decision is missing? The Daily serves less as a status inquiry than for clarifying blockers.

In the Review, AI can bring together what is otherwise laboriously gathered: which requirement was the basis? Which assurances were implemented? Which code change was committed? Which deviations did the reconciliation find? Review is therefore more strongly bound to specification and reviewability.

In the Retrospective, AI can make patterns visible from actual work data: where were requirements too soft? Where did unnecessary correction loops arise? Which tickets were cut too large? Where did the agent have to rework repeatedly?

Humans decide what is important – but on better prepared information.

AIND Docks Onto Team Coordination

So that this finer coordination does not lead to additional maintenance effort, it has to arrive where teams work: in the backlog, in the sprint, in the issue. AIND therefore does not replace Jira or comparable tools, but supplies them with information. To this end, an AIND artifact – for example a component or an implementation task – is linked with a Jira issue. From then on, the connection can be maintained largely automatically:

• The status moves along in the Jira workflow: when work on an artifact begins or ends, the associated issue moves with it.
• The system writes a concise status comment into the issue, short and readable, without anyone having to maintain it by hand.
• The commit message with which a change is taken into the code carries the intent of the issue with it. In this way, the connection between domain task and technical change is preserved.
• Review and deviation information can be fed back into team coordination: what has been implemented, what is still open, where is a decision needed?

The team therefore continues to work in Jira as before, and AIND feeds this coordination level. That is at least how the Jira integration we are currently working with is designed.

Controlled Boundary and Data Sovereignty

The integration is deliberately designed so that, firstly, it is mediated via a controlled boundary: the agent does not get indiscriminate access to all issues, but works via a defined, reviewed interface. According to the same logic as described in the previous parts, the agents always receive only limited, controlled capabilities.

Secondly, the integration is data-sovereign: all developers act with their own identity. Status changes and comments appear under the person who is responsible for the work, and not under an anonymous automaton. In this way, traceability and accountability are preserved, which is precisely what matters in the collaboration model. When AI generates a status, prepares decisions, or makes blockers visible, responsibility must not become blurred. AI can prepare and condense coordination, but the team still must decide and take responsibility.

Changing Teamwork Based on Experience

The real benefit lies in the fact that proven collaboration remains in place and evolves in ongoing practice: a team introduces AI-supported development without overturning its coordination mode, and learns in operation where processes change. Scrum therefore carries this development along, rather than standing in its way: it allows the team, with the help of AI, to steer and handle in a controlled way the coordination processes required so that specification, decision, and review can keep up with the faster building.

The remaining question is where the journey is heading. Today, agents are still tools that are detached from the methodology; tomorrow, they will be embedded more deeply within it. That is the subject of the final part in this chapter.