Imagine that a stakeholder asks your team to make user onboarding faster. The tempting response is to open a ticket and start coding. A more effective team pauses first. Where are users getting stuck? What outcome would count as an improvement? What is the smallest change that could test the team's assumptions?
Only then does implementation begin.
That sequence matters even more now that AI can generate plans, interfaces, code, tests, and documentation in minutes. Faster production is useful only when the team understands the problem. Otherwise, AI simply helps it build the wrong thing sooner.
This is where Scrum remains valuable. Its fundamentals do not change because the tools become faster. Make the work visible, deliver in small increments, inspect the result, and adapt. AI can support every step, but a person must remain accountable for every product, technical, and release decision. That boundary reflects the NIST AI Risk Management Framework, which emphasizes defined human roles, oversight, and responsibility for AI risks.
What follows is my interpretation of how Scrum works best in software teams. The framework is deliberately lightweight, so each team must complement it with the engineering and product practices its context requires. For the formal definition, read the Scrum Guide.
Scrum in Brief
Scrum is a framework for solving complex problems through short learning loops. Work happens in fixed-length Sprints of one month or less. During each Sprint, the team creates at least one usable Increment. This is a concrete step towards the Product Goal that meets an agreed Definition of Done.
Scrum is built on three ideas.
- Transparency makes the goals, work, and quality of the product visible.
- Inspection asks the team and its stakeholders to examine progress and results frequently.
- Adaptation means changing the plan when the evidence shows a better path.
A Scrum Team typically has 10 or fewer people. It is cross-functional, which means it collectively has the skills needed to create value, and self-managing, which means its members decide how to perform the work. Scrum defines three accountabilities.
- The Product Owner is accountable for maximizing product value and managing the Product Backlog effectively.
- The Scrum Master establishes Scrum and helps the team improve its effectiveness.
- The Developers create the usable Increment and adapt their plan towards the Sprint Goal.
In Scrum, "Developers" does not mean software engineers alone. It includes everyone needed to produce the Increment, which might include designers, researchers, quality engineers, security specialists, data scientists, or operations engineers.
Larger products can be served by several cohesive Scrum Teams sharing the same Product Goal, Product Backlog, and Product Owner. Scaling frameworks exist, but the principle is more important than the framework. Add teams without fragmenting the product's direction.
Scrum intentionally does not prescribe how to conduct product discovery, design an API, test software, or deploy it. The workflow below combines formal Scrum events with complementary practices I have found useful. I will make the distinction clear as we go.
1. Understand the Problem
Before planning a Sprint, understand the outcome the product should create. Speak to users and stakeholders. Examine existing data. Record the constraints, open questions, and evidence that would change your mind.
AI is useful here as a research assistant. It can summarize interview notes, group recurring complaints, compare findings across sources, and suggest questions the team has not asked. This can reduce the time spent sorting information, but it does not turn weak evidence into strong evidence. The DORA AI Capabilities Model likewise identifies user focus as a condition that improves the effect of AI adoption on team performance.
Always return to the source material. A summary can omit an inconvenient detail or flatten a minority view into the dominant theme. Sensitive customer or company data should only be used with tools your organization has approved. The NIST Generative AI Profile recommends verifying sources and citations in generated outputs. That is good everyday advice for product work too.
The Product Owner remains accountable for the Product Goal and the ordering of the Product Backlog. AI can help organize the evidence, but it cannot decide what customers value or which trade-off the business should make.
2. Shape a Rough Solution
Once the problem is understood, shape enough of a solution to expose its difficult parts. This might mean sketching a user journey, mapping a data flow, defining an API contract, or building a disposable prototype.
Design reviews, technical planning sessions, and technical spikes can help with this work, but they are complementary practices rather than formal Scrum events. Their purpose is not to produce a perfect specification. It is to discover expensive assumptions before the team commits to implementation.
AI can propose alternative designs, generate a prototype, identify edge cases, or challenge an architecture. Ask it to explain the trade-offs between options rather than simply requesting the "best" answer. Its recommendations are only as reliable as the context it receives, and it will not understand undocumented constraints.
A human should choose the design, record the important trade-offs, and decide when the team knows enough to proceed. The goal is a shared direction, not false certainty.
3. Plan the Sprint
Sprint Planning answers three questions.
- Why is this Sprint valuable?
- What can be completed during it?
- How will the selected work get done?
The whole Scrum Team defines the Sprint Goal. The Developers select the Product Backlog items and create the delivery plan. This matters because the people doing the work have the clearest view of its complexity, their capacity, and the Definition of Done.
AI can flag vague backlog items, missing acceptance criteria, hidden dependencies, or work that may be too large for one Sprint. It can suggest a first decomposition, but it should not make commitments on the team's behalf. A plausible estimate from a model is not evidence that the team can deliver it.
Before introducing AI, automate the predictable coordination. At Glints, I connected GitLab, Jira, and Lark so that creating a branch moved its Jira card to implementation. Assigning a reviewer moved the card to review and sent that person the relevant links. This follows the familiar trigger-and-action model documented by Jira automation and GitLab webhooks.
That workflow was not AI, and that is the point. A deterministic rule is cheaper, easier to audit, and more reliable when the same input should always produce the same result. Start there. Add AI when the task requires interpretation, such as finding ambiguity in a story or summarizing a long discussion.
4. Build and Coordinate
During the Sprint, the Daily Scrum gives the Developers 15 minutes to inspect progress towards the Sprint Goal and adapt their plan. It is not a status report to a manager, and Scrum does not require everyone to answer three fixed questions. The team can use any format that produces an actionable plan.
AI can prepare a digest of changes, blockers, failed builds, and open reviews before the Daily Scrum. That saves gathering time, but the digest should not replace the conversation. A blocker that never appeared in a tool will never appear in its summary.
During implementation, AI can help draft code, tests, documentation, migration plans, and review comments. The leverage is real, but so is the verification cost. DORA's 2025 research describes AI as an amplifier of an organization's existing strengths and weaknesses. Teams with clear workflows, fast feedback, and strong testing can benefit. Teams with fragile practices can create technical debt faster.
Keep changes small enough to understand, test, and review. DORA identifies working in small batches as a way to shorten feedback loops and reduce the instability associated with AI-assisted delivery. Generated code must meet the same Definition of Done as human-written code. Quality engineers remain essential. AI can help execute checks, while people decide what risks matter and whether the evidence is sufficient.
5. Review and Release
The Sprint Review is a working session with stakeholders. The team inspects the outcome, discusses what has changed, and adapts the Product Backlog. It should not be reduced to a polished demonstration in which feedback arrives too late to matter.
AI can draft release notes from verified changes, prepare a first summary of the Increment, and organize stakeholder feedback after the session. A person should confirm every claim against what actually shipped. The team should also read the original feedback. Clustering comments is convenient, but an unusual observation may contain the most important insight.
An Increment may be released before the Sprint Review. The review is a feedback opportunity, not a release gate. Release decisions still belong to the people accountable for product value, engineering quality, security, and operations.
6. Reflect and Improve
The Sprint Retrospective closes the Sprint by examining how the team worked and planning ways to improve quality and effectiveness. A useful retrospective moves beyond listing what went well and badly. It identifies a change the team can try, an owner, and a way to tell whether the change helped.
AI can group anonymous notes, compare themes across several Sprints, and draft possible actions. It must not become an authority on team dynamics. Summaries can erase disagreement, and sensitive reflections should not be sent to an external model without the team's knowledge and consent.
The team chooses the improvement and follows through. An AI-generated action list with no owner is merely faster paperwork.
AI Does Not Change the Point of Scrum
The aim is not to make every activity faster. It is to shorten the path to reliable feedback.
Scrum gives a team a goal, a small batch of work, a usable result, and regular opportunities to inspect and adapt. Product discovery and rough design help the team start in a sensible direction. Engineering practices make the Increment safe to release. Deterministic automation removes routine coordination, while AI assists with work that benefits from synthesis, critique, or generation.
None of these tools removes accountability. AI may research, draft, summarize, challenge, and check. People still decide what matters, what is true, what is safe, and what ships.
Scrum is not the right framework for every team, and following its events mechanically will not create agility. Its value lies in disciplined learning. Build something small, confront reality, and change course while change is still affordable. That principle becomes more important, not less, when software can be produced at unprecedented speed.