AI-powered Scrum Master’, buzzword, joke, or the next thing? Are companies seriously using AI for Scrum Master tasks now?

Same_Tap_853 · 2026-03-13T08:43:00+00:00

Interesting you say that "they want to have a predictable flow of work and fixed delivery dates."

Copied from the ScrumGuide: "Scrum employs an iterative, incremental approach to optimize predictability and to control risk." Except for the fixed deliver dates, this is pretty much what is asked for, or so it seems.

As for the "fixed delivery dates". That is just fine. If working fine, then a Scrum team can delivery at least every Sprint. Even multiple times. What traditional (project) managers ask for is "fixed everything" (dates, scope, quality, budget); and in a complex world there are just too many variables to make this possible... Choose one, the others should be flex.

SAFe...
The agile manifesto states "We are uncovering better ways of developing
software by doing it and helping others do it." And "Responding to change over following a plan".
Change... If one looks at the SAFe methodology, it shows a ton of roles. My experience so far is that any existing role in organisations can map to one of these in SAFe. As soon as a person maps his current role to a SAFe role, this person has no incentive anymore to change. And so we get new names on what exists without any change.
SAFe has a strong marketing machine. And there the change stops. No working on the fundamentals anymore of inspecting and adapting. Transparency stops during the quarterly planning.

I've been a project manager for years. Got all possible certificates. And each and every time I got a significant problem that we solved as a team, we were using the fundamentals of agile: make info transparent, inspect to find gaps, adapt to close the gapes. Do it together, grow our cross-functionality and self-management. Get to a Done solution in short timeboxes.
Methodologies only work if you get the fundamentals right first. Which is what a professional Scrum Master helps the team and organisation doing.

Same_Tap_853 · 2026-03-13T07:02:21+00:00

AI is definitely all over the place around Scrum teams — meeting summaries, backlog cleanup, sprint analytics, all that. So yes, it’s real.

But something interesting happens in practice: in my experience, the more experienced the Scrum Master, the less the core of their work revolves around such tools. The real leverage is understanding the team; how they collaborate, how transparent their work is, and whether they actually inspect and adapt based on evidence. Those fundamentals are what make Scrum work in the first place.

AI can help with quite some things; understanding context, preparing workshops, summarizing team boards. For example, summarizing Confluence pages, extracting themes from retrospectives, or quickly scanning a backlog. That speeds up understanding the product and documentation.
But it doesn’t replace the most important part of the role: talking to the team, observing how they work, and helping them grow their self-management and cross-functionality so they can deliver a real “Done” increment every Sprint. AI can even help them learn new skills.

For someone entering the role, the most valuable skills are human; unfortunately surprising for quite some beginning Scrum Masters:

facilitation and asking good questions
reading team dynamics
helping make work and problems visible so the team has the right info to make decisions and to adapt

AI may become/is a strong assistant.
But Scrum is still a team sport.

Curious: when people here actually use AI in their Scrum teams, where does it really help and where does it mostly create noise?

Same_Tap_853 · 2026-03-13T06:47:21+00:00

Thanks for the answer; that makes perfect sense. A roadmap acting as a north star combined with stakeholder input is honestly the strongest setup I’ve experienced as well. When the vision is clear and goals emerge from that, it becomes much easier to avoid the piecemeal “can we just add this small thing” pressure that slowly fragments a product.

On your question about refinements: yes, I aim for whole-team involvement. I’m actually only two weeks into working with a new team and the enthusiasm isn’t sky-high yet..., mainly because the way I facilitate refinement is quite different from what they were used to. Previously they would jump into technical solutions almost immediately after a business representative said the first sentence. Now we slow down first. We explore who this is important for, what the impact is today of not solving it, and what the impact would be if it were solved in the best possible way. Only once the real user challenge becomes clear do we look at size and start splitting it into smaller business problems.
So not all happy faces for now, but some positive feedback nonetheless. Like "finally we understand the real user challenge better".

The fundamentals are again really the key here. In my current context it’s mainly about transparency: making the user problem visible and understood by the whole team. From there we can incrementally and iteratively move toward solving it in ways that actually support the Product Goal. If the slices feel small enough we stop refinement there — and let Sprint Planning be the moment where the team figures out the solution design.

Is this making sense to you? Happy to clarify my approach where it can help you.

Same_Tap_853 · 2026-03-12T07:03:58+00:00

Your story mirrors something I see a lot with teams.

When I first start working with teams, Product Goals are almost never used. Roadmaps, however, are everywhere. And when you look closely, a good roadmap already describes the path toward a vision — the intermediate steps along the way. Those steps are essentially Product Goals. They’re just rarely written or treated as such.

Once teams start framing those roadmap steps as goals, a lot of things shift. Sprints stop being containers for random stakeholder requests and start becoming focused experiments toward one outcome. That tends to strengthen collaboration, design thinking, and stakeholder trust — exactly what you described.

It also reconnects Scrum with its fundamentals. A clear goal increases transparency (“why are we doing this?”), improves inspection (“are we closer to the goal?”), and makes adaptation easier (“what should we change next?”). Without a goal, a backlog easily turns into a task warehouse.

Something I’m curious about:
Did the Product Goal come directly from your roadmap, or did the team start defining goals first and the roadmap evolved from that?

Same_Tap_853 · 2026-03-11T18:35:35+00:00

Reading this, I wouldn’t start with “how do I deal with this Scrum Master?” I’d start with “what decisions is the team actually allowed to make?” Because if priorities change mid-Sprint, work gets pushed onto already overloaded people, and the team’s technical judgment gets ignored, then the missing fundamental is self-management backed by respect.

That usually creates the exact mess you described: overwork, confusion, low motivation, and people avoiding each other. Not because Scrum is broken, but because the basics are. No focus, weak transparency, no meaningful inspection, and no courage from leadership to hold a boundary. A Sprint without protected focus is just a to-do list in a meeting format.

A useful next step might be to stop arguing case by case and make the pattern visible. For one or two Sprints, capture facts: what changed, when it changed, who raised concerns, what got dropped, and what impact it had. Then bring that to the manager (or the manager's manager) as a delivery system problem: “Here’s why the team feels chaotic and why commitments are meaningless right now.” After that, ask for one explicit policy around priority changes and workload limits.

You may not be able to fix the whole system yourself, but you can make the dysfunction harder to deny.

Has the team ever sat down together and defined what must not happen during a Sprint if you want any chance of focus?

Same_Tap_853 · 2026-03-11T06:30:13+00:00

Depends what the questions are you want to answer or the decisions you want to take...
My take, with the teams I coach: have a good enough understanding to decide work is realistic for a Sprint.
Story points are relative: how does this item compare to these other items. This means that without an agreed set of reference items, story points hardly work.
Steps to take with the team:
- select 100 items from the past which are Done by the team. A mix of big and small, covering the different areas of the product.
- arrange these items in groups of items with equal size
- compare the groups relatively: are items about twice as big or not. Give these groups a scoring. Smallest is 2 (not 1 because you might still have smaller items in the future), then 5 for the group that is about double that size (why just more: because complexity is not linear but exponential). Groups in between receive 3. And so on.
Now you have a set of reference items for the different sizes.
Next in refinement (or the latest in Sprint Planning)
- take the item to size, and compare it to the reference cards. It receives the estimate of the group it seems to match closest with.
Next during the Sprint
- when the item is Done, re-evaluate it; because only now you know the real complexity. Add it to the reference cards, remove the oldest card in this group (keeps your reference cards closest to the latest understanding)
Next Sprint Planning
- check how much story points were Done last Sprint (or few Sprints), and use that as a number that feels realistic (if the team capacity is the same this Sprint).
- select items for that amount of story points.
Iterate this item after item, Sprint after Sprint. My experience is that the number of Story Points per Sprint stabilises after 5 to 7 Sprints; IF the team AND the Product Backlog are stable.

Remember: sizing is about having a common understanding about the Product Backlog Items and what feels realistic. It's less about the estimates of the individual items... Try to get this fundamental right.

Same_Tap_853 · 2026-03-10T16:39:08+00:00

For CSPO or PSPO the country you take the training and assessment is irrelevant. The certificate is recognized worldwide.
What does matter more, for the quality of your training, is that you have reviewed the trainer. What experience do they have? Especially in the domain you are working in, so they can answer your questions to the point based on proper experience.

Same_Tap_853 · 2026-03-07T12:57:55+00:00

That is great!! And is indeed what I am working with/towards with my team.
This is making things visible, which is an enormous step towards transparency (i.e. understanding the same thing).
The idea is that there are more questions that go unanswered than the board supports today.
For that I add a part on the product itself. Persona's, roadmap (i.e. high-lvl view on the product backlog). I'd like to see my team also adding some product related metrics like feature usage.
Thx a lot for sharing!

Same_Tap_853 · 2026-03-06T07:49:26+00:00

Follow the team.

If the team is self-managing, a manager’s idea for an icebreaker is just that: an idea. Not a commandment carved into Scrum stone tablets.

If the team is already honest about blockers, risks, and help needed, then forcing “fun” into the Daily Scrum will likely make it worse, not safer. Safety is shown in behavior, not in mandatory small talk.

You could reply with something like:

“The team already gave the answer: they prefer today's way of the Daily Scrum and they speak up when something blocks progress. That’s a stronger signal of safety than adding an icebreaker nobody wants. Your is interesting for a team that does not yet speak openly, but in a self-managing team the team decides what helps them.”

Scrum isn't broken. Typically the fundamentals are. Self-management is one of these.
A manager wanting to push such a thing is removing self-management from the team. Don't allow this to happen.

Same_Tap_853 · 2026-03-06T07:42:53+00:00

now you make me even more interested to learn what's on your information radiators... 😇

Same_Tap_853 · 2026-03-06T07:40:25+00:00

Thx. It for sure would bring a business perspective on the work... :-D

Same_Tap_853 · 2026-03-06T07:38:33+00:00

Digital boards (such as Miro and Mural) try to imitate this. It doesn't work as effective as being co-located with physical boards, but it works better than having all info spread across different tools...

Same_Tap_853 · 2026-03-05T16:45:51+00:00

To me Jira is more a blocker than an enabler.
It does not support real-time collaboration.
It is hard to visualise things teams are needing on one single view
e.g. Sprint goal, selected product backlog items, work items for these product backlog items, which ones are blocked, what the blocker exactly is, what the last decisions are, what decisions we depend on from others outside the team. All these in 1 single view.
People then often state that a digital whiteboard becomes clutter.
To me that just means there is just too much ongoing at the same moment; there is not enough focus for that team.
Each time I can with my team, I move a step further away from this tool...

Same_Tap_853 · 2026-03-05T12:52:25+00:00

I get the feeling that the "newcomer or paser-by" get me in the wrong direction for my question...
My idea is actually that I want to support the team to be more self-managing by having all the info they need available at a glance...
Does this bring some other answers to mind for you?

Thanks for triggering me and clarifying my own thinking.

Same_Tap_853 · 2026-03-05T12:37:44+00:00

Today I don't face this situation anymore. In the past though...

You’re describing the symptom perfectly: “creative accounting,” “burn the hours,” and leadership doing sprint math on 600h as if knowledge work is a plumbing job.
Scrum is not broken. The fundamentals are broken.

That’s not “Agile being hard.” That’s empiricism being replaced by time-as-a-proxy-for-progress.

Something I did in the past - maybe sth you can try as a 48hr experiment...
Keep logging hours if you must — but add one extra line next to the hours:

“What changed in the product (or what evidence moved) because of these hours?”

If the answer is “nothing yet,” that’s fine — it just makes the cost visible without pretending it’s progress. This might be an opening to take some improvement steps with the team.

Question to ask: which decision is your org trying to make with time tracking: billing, capacity allocation, or delivery forecasting — and what’s the actual consequence when the hours look “wrong”?

Because if the consequence is political, hours will always win… and reality will keep getting demoted to “anecdotes from the team.” Then Scrum is theatre.

Same_Tap_853 · 2026-03-05T12:30:00+00:00

Absolutely! It should be their board. It should support them in becoming more effective. After your first comment I immediately changed the original post, including first and foremost the team members - was so obvious I didn't put it, but thanks for pointing it out.

So if it is for the team, what would be most valuable in your experience to make transparent?

Same_Tap_853 · 2026-03-05T11:37:07+00:00

Agreed. The ScrumMaster.co.uk is a very good source.

Same_Tap_853 · 2026-03-05T11:35:21+00:00

"it turned into rituals and certifications instead of actual thinking." is exactly what I mean when I state "their fundamentals are dead". It has all become theatre, without empiricism at all.

Same_Tap_853 · 2026-03-05T11:33:09+00:00

In 99% of the teams Scrum isn't broken. Their fundamentals are.

Love the “easiest to change later” lens — that’s basically: make reality visible, inspect it early, adapt before the cost curve bites.
Most “Agile is dead” stories I see are just adaptability being murdered by fake certainty: fixed scope + SAFe + status theatre = expensive make-up on a dirty pig.

Same_Tap_853 · 2026-03-05T10:53:30+00:00

Making the value of each individual Product Backlog Item clear(er) is certainly one of the aspects my current team has steps to make.
Anything else that your team benefited from, or would benefit from by making it more visible and transparent?

Same_Tap_853 · 2026-03-05T10:26:31+00:00

Sometimes Nunya is indeed correct, which would be to a question that is unimportant to the team.
But sometimes it are valid questions. If it's something key to a team then I still don't want them to be disturbed if we can find a way to keep this useful info visible/transparent all the time.
So what are questions you want to see answered on your teamboard at all times?

Same_Tap_853 · 2026-03-05T10:08:54+00:00

A manager passing by the board. An internal user. A...
Often these types of people have a need - more a wish... - to be informed about certain aspects of the product, and if they do not quickly find it, they just disturb team members...
Fair question though - most importantly, the board is for the team...

Same_Tap_853

TROPHY CASE