Updated 23 October 2026.
AI can help a team arrive with clearer questions, organised feedback and less repetitive preparation. It can also invent requirements, hide a dissenting observation or turn a tentative suggestion into a delivery promise. The difference depends on the evidence supplied and the people reviewing the result.
Use it to prepare the conversation, then let the people doing the work inspect and adapt together. A generated summary is not evidence that shared understanding exists. If the team spends the meeting repairing the summary, the assistant may have added work.
This guide covers Scrum events, ongoing Product Backlog refinement and Kanban flow conversations. For wider project communication, see the practical AI project management guide. Keep that workflow separate from the team’s preparation and decisions.
Keep Scrum accountabilities with people
The Scrum Guide 2020 is the reference for Scrum. The Scrum Team comprises the Product Owner, Developers and Scrum Master. An assistant is a tool used by those people; it does not hold a Scrum accountability.
The Product Owner is accountable for maximising product value and effective Product Backlog management, including ordering and transparency. Work can be delegated, but accountability stays with the Product Owner. Generated ordering or wording must therefore remain a proposal for consideration.
Developers are accountable for creating a usable Increment each Sprint, creating the Sprint Backlog, instilling quality through the Definition of Done and adapting their plan towards the Sprint Goal. AI cannot make their forecast, determine capacity or agree how the work will be done.
The Scrum Master is accountable for establishing Scrum as defined in the Guide and for the Scrum Team’s effectiveness. Helping people understand a draft or remove an impediment may support that work. Using an assistant to monitor individuals or replace facilitation does not establish effectiveness.
“Ceremony” is common shorthand, but Scrum uses “events”. The Sprint contains the other formal events. Product Backlog refinement is an ongoing activity, not an additional Scrum event. Kanban practices should be considered against the team’s workflow rather than presented as another set of Scrum ceremonies.
Product Backlog refinement: expose questions before polishing wording
Refinement breaks down and further defines Product Backlog items. AI can group permitted feedback by customer problem, suggest story splits and propose acceptance examples. Preserve source identifiers so the team can check whether the grouping reflects the original problem.
The Product Owner remains accountable for effective backlog management and ordering. Developers doing the work are responsible for sizing. People with relevant knowledge must examine feasibility and dependencies. A generated estimate, priority or acceptance example does not become agreed simply because it looks complete.
For example, an illustrative request to change account preferences might be split into viewing current settings and changing a setting. The team must check whether each proposed slice delivers useful value and meets applicable constraints. Splitting text into smaller paragraphs is not necessarily splitting work sensibly.
Using these permitted feedback and backlog records with IDs,
group customer problems and propose questions, possible story
splits and acceptance examples. Reference every source.
Separate evidence from suggestions. Preserve contradictions.
Do not invent requirements, estimates, priority or commitments.
Records: [paste approved material]Review each theme against the original comments, including those left ungrouped. A rarely mentioned accessibility problem may matter more than a common cosmetic request. Check that proposed acceptance examples have not silently widened scope or weakened quality expectations.
Sprint Planning: prepare options without making the forecast
Sprint Planning addresses why the Sprint is valuable, what can be done and how the chosen work will get done. The whole Scrum Team collaborates to define a Sprint Goal. Developers select work through discussion with the Product Owner and plan how to create an Increment that meets the Definition of Done.
AI can prepare a question list from candidate items, identify stated dependencies and highlight missing context. It should not allocate people, calculate an unsupported capacity figure or announce the work selected for the Sprint.
Review these candidate items, product context and known
constraints. List questions and source-backed dependencies
for Sprint Planning. Suggest goal discussion options only.
Do not choose Sprint scope, assign people, estimate work
or promise completion. Mark missing information explicitly.
Approved inputs with IDs: [paste]Developers check dependencies against how the system actually works. The Product Owner clarifies value and trade-offs; the team discusses the Sprint Goal. The Scrum Master helps the event remain useful and within its purpose rather than letting generated detail consume the conversation.
For example, in an illustrative planning discussion, a candidate item depends on access that is not confirmed. The assistant can surface the dependency. The team still decides what is feasible and how uncertainty affects selection. A tidy plan cannot supply missing access or create agreement.
Daily Scrum: support the Developers’ adaptation
The Daily Scrum is for Developers to inspect progress towards the Sprint Goal and adapt the Sprint Backlog, adjusting planned work as necessary. It is not a meeting for an assistant to assess individuals or a manager to collect personal activity scores.
A short preparation note may help if the team already maintains reliable information. AI can identify an unresolved blocker, an item with no recent confirmation or a question about the Sprint Goal. Missing updates are questions to ask, not proof that someone has failed.
From these permitted Sprint Goal and Sprint Backlog records,
list evidence-backed blockers and questions the Developers
may need to discuss. Include source IDs and update dates.
Do not rate individuals, infer effort or prescribe assignments.
Keep unknowns visible. Do not claim the plan has been agreed.
Inputs: [paste]Developers choose how to conduct the Daily Scrum and adapt their plan. They should be able to discard an unhelpful AI note without maintaining a parallel reporting process. If producing the input pack takes longer than preparing directly, remove that step.
An omission matters here: the summary may miss a blocker mentioned in conversation but absent from the tool. Ask whether the maintained records represent current work. Do not assume that connecting more applications creates a complete picture or permission to inspect every message.
Sprint Review: distinguish outcomes, feedback and possible adaptations
The Sprint Review is a working session in which the Scrum Team and stakeholders inspect the outcome of the Sprint and determine future adaptations. It goes beyond a presentation. The Product Backlog may be adjusted as people discuss progress towards the Product Goal and changes in their environment.
AI can organise approved demonstration notes and stakeholder feedback into questions and potential backlog changes. It must distinguish work meeting the Definition of Done from unfinished work and separate observed outcomes from claims about future benefits.
Organise these approved outcome notes and stakeholder comments
for Sprint Review. Separate demonstrated outcomes, unfinished
work, feedback, questions and possible backlog adaptations.
Reference source IDs. Preserve conditions and disagreement.
Do not invent acceptance, approval, value achieved or dates.
Notes and relevant quality evidence: [paste]The Scrum Team and stakeholders inspect together. The Product Owner remains accountable for backlog management, and Developers remain accountable for quality. Do not describe the Review as an AI-mediated acceptance gate or use a generated summary to declare unfinished work complete.
For example, in an illustrative discussion, a stakeholder says a change “could help if the export works”. The summary must preserve that condition. It cannot record that the stakeholder approved the feature or confirmed a benefit.
For status reports, RAG and RAID outside the sprint, see the pillar’s separate reporting guidance. Do not turn Review preparation into another version of that reporting process.
Sprint Retrospective: group observations without judging people
The Sprint Retrospective plans ways to increase quality and effectiveness. AI may group team-provided observations and suggest questions about patterns. Its output should be a discussion aid, with the original observations available for people to challenge the grouping.
The Scrum Team inspects how the Sprint went, including interactions, processes and tools. The Scrum Master supports effectiveness and useful participation. An assistant cannot determine whether people feel safe to disagree, and an apparent theme is not proof of a cause.
Group these permitted retrospective observations into tentative
themes, retaining source IDs and minority views. Separate
observations from interpretations. Suggest questions and
possible small experiments, clearly marked as proposals.
Do not infer emotions, blame, performance or individual scores.
Observations: [paste approved, minimised material]Avoid sending sensitive personal observations to a tool simply because names have been removed. Details may still identify people. Agree what can be processed, whether anything should be retained and who can see it before collecting material.
Check themes with the team. For example, in an illustrative retrospective, repeated waiting may reflect an unclear hand-off rather than poor individual performance. People must investigate the explanation and choose an improvement. Keep a review point for the experiment instead of generating an expanding list of unowned actions.
Kanban: make flow visible without inventing forecasts
The Kanban Guide provides the reference for Kanban. Start with the team’s explicit workflow: where work starts and finishes, its states, work-in-progress controls and policies. A summary cannot make inconsistent board data reliable.
AI can prepare a view of work in progress, recorded blockers and ageing items from a dated snapshot. Give it the team’s definitions and any agreed service level expectation rather than letting it invent thresholds. Keep arithmetic in a dependable calculation method and check the underlying dates.
Using this dated board snapshot and our explicit workflow,
summarise WIP, recorded blockers and ageing work by item ID.
Use supplied calculations and policies; do not invent limits,
elapsed times, causes or completion forecasts. Flag missing
or conflicting dates. Suggest questions for the flow discussion.
Snapshot, calculations and workflow policies: [paste]People managing the workflow decide how to respond. A team may investigate whether to help finish an ageing item before starting more work, but the assistant cannot decide that the WIP policy should be bypassed or move work to “done” to improve the picture.
For example, in an illustrative flow discussion, an old item has no blocker recorded. That does not prove the item is progressing normally. Check whether it is waiting, actively worked or inaccurately represented before drawing conclusions.
Do not infer an individual’s productivity from card counts. Work items differ, collaboration is not always visible and a board may omit essential work. Where forecasting is needed, use suitable historical data and an understood method; generated confidence does not establish predictive accuracy.
Make preparation cheaper than the review it creates
Try one activity first, such as grouping feedback for refinement. Record preparation, drafting, review and correction effort together. Ask whether the next conversation became clearer, not merely whether a document appeared quickly. The pilot scorecard helps keep that evaluation explicit.
Check for hallucinated facts and false source references by opening the cited records. Read the inputs for omitted issues and minority views. Watch for an overconfident tone and conditional language turned into commitments. These failures matter across every activity, even when the output is only a list of questions.
Account for subscription charges, AI credits and usage-based pricing. Include admin and integration effort, access maintenance and prompt repairs. Use the software buyer’s guide before introducing another service to the team’s workflow.
Privacy and confidentiality controls must cover connected records as well as pasted text. Confirm retention, training use and authorised access. Limit inputs to what the chosen activity needs; broad workspace access can add exposure without improving the conversation.
Test data export and keep approved observations and decisions accessible outside the assistant. Vendor lock-in can hide the evidence behind a summary or make the process dependent on one integration. Keep a manual route for outages so the team can still hold a useful event without generated preparation.
When NOT to use AI
Do not process confidential or personal data without approval, including sensitive retrospective comments and customer feedback. If you cannot preserve enough context safely, prepare the material directly with the people involved.
Do not delegate accountable judgement, negotiation or team commitments. The Product Owner, Developers and Scrum Master retain their accountabilities. Stakeholder disagreement requires a conversation; a generated consensus can erase the very difference the team needs to understand.
Avoid summarising unreliable inputs where nobody can check the missing context. Stop when reviewing the draft costs more than preparing directly, or when plausible mistakes repeatedly survive into the discussion. Correct the workflow before making it routine.
Keep legally or contractually binding text within the relevant authorised process. A useful refinement prompt does not justify sending commitments to customers. And don’t use AI to rate individuals or monitor people’s activity. That is surveillance, not event preparation, and it damages the trust these events depend on.
FAQ
Can AI run a Scrum event?
It can prepare permitted material. People still inspect, adapt and hold the Scrum accountabilities; a generated discussion script does not replace that work.
Is Product Backlog refinement a Scrum event?
No. It is an ongoing activity for breaking down and further defining Product Backlog items, rather than an additional formal event.
What is a useful first Kanban application?
Try a reviewable summary of recorded blockers and ageing items from a reliable snapshot, using the team’s explicit workflow and checked calculations.
Put It Into Practice
Pick one thing from this article to try on your next project. If you need a starting point, Resources has free status report, action log and decision log templates. For a difficult conversation, try the People Field Guide.
Get new practical guides by email →
About Paulius
I’m Paulius Petravicius, a project manager with a background in business and data analysis. I share practical ways to make everyday project work a little easier. Read my story →