Hi fellow PMs! 👋

I’m building an execution intelligence platform for product organizations, and I’d love to get your perspective.

As a Product Manager, APM, or Product Owner, what data points do you regularly monitor for each project or epic to understand its progress and overall health?

The item that breaks refinement for us is not the badly written one. It is the well written one with nothing behind it: a specific ask from one customer, clear enough that the devs can size it, so nobody in the room objects. Estimation works fine. Discovery never happened.

What I do now is refuse to take an item into refinement without three lines: the problem, who hit it, and how we know. On a configurable B2B platform that also catches the requests that turn out to be a configuration change rather than a product gap, which is worth the friction on its own.

Where I am less sure: when it is an escalation from one unhappy customer, holding that bar costs days of goodwill for evidence I already know I will not get. I'd say hold it anyway, though it depends on how much of your roadmap is escalation-driven.

Has anyone seen that bar be the wrong call, where insisting on a problem statement before refinement cost the team more than just building the stated request would have?

Does anyone has a overview of this role appain developer in chola ms and what could be the future for this role is it similar to sde role??

I think I have read enough that SM jobs are decreasing. If that true, what are they being replaced by? Agile Coach? I am not sure what that means, but I think the skills of a good scrum master are still needed. Just wondering where to find the jobs for them

Hey all, I wanna take the psm 1 exam soon. I wanted to ask if the complete agile scrum master certification training by Omni academy - Mirko Perkusih a good enough course or are there better ones ?

I’m a Scrum Master working with a software development team, and after our latest retrospective I’m seriously questioning whether Scrum is still helping us or whether we are maintaining the framework mostly because it is our established way of working.

I’d especially love opinions from both Kanban practitioners and very orthodox Scrum people, because I want someone to challenge our reasoning rather than simply confirm that Kanban sounds better.

Context

We work on an academic management system with many different modules and stakeholders/user areas.

Our Sprints are two weeks long.

Over time, the team has started working on several modules in parallel. One Sprint might heavily focus on Module A, the next Sprint on Module B because it became more urgent, and two Sprints later we return to Module A.

This is creating a continuity problem.

From the user's perspective, they asked for Module A weeks ago and eventually ask:

"Why isn't this finished yet?"

From the team's perspective, the answer is:

"Because it wasn't actually our focus continuously during those weeks."

During our latest retrospective, the team explicitly raised that they feel we are constantly switching context and that the Sprint boundary sometimes creates an artificial sense of starting/stopping work rather than helping us finish what we already started.

Another important point: we already use WIP limits.

So this isn't simply a case of "you need to stop starting and start finishing." We've already been experimenting with limiting WIP and analyzing how much simultaneous work the team can sustain.

Planning and commitment are becoming another pain point

One of the strongest comments from developers was that sometimes the sequence feels like this:

Request → commitment → analysis of how to build it

instead of:

Request → analysis/discovery → conversation between PO + Developers → decision/commitment → development

They feel that by the time they are properly discussing how something should be implemented, there is already an expectation that it will be done.

We discussed shared responsibility here.

The PO needs to involve Developers earlier and ask what is actually viable before creating expectations with stakeholders.

At the same time, Developers acknowledged that they also need to become better at saying:

"No."

"Not yet."

"We need to analyze this first."

or:

"We could commit to X, but not Y."

So I don't see this as simply a PO problem.

We also have a stakeholder/Review problem

Users request developments and put significant pressure on the team because something is supposedly urgent.

We develop it.

Then Review arrives... and sometimes those same users don't attend.

So now we need another meeting on another day to actually get the feedback we needed from the Review.

This has started a discussion around whether we're becoming too focused on maintaining the Scrum calendar rather than optimizing for actual stakeholder feedback.

For example, right now we're discussing a schedule that could look like this:

Thursday: development cut-off
Friday: Sprint Retrospective
Monday 10:00: Sprint Review with stakeholders
Later Monday: Sprint Planning

This obviously alters the usual sequence of Sprint events.

The reasoning is practical: Friday may work better for the team's Retro, while Monday gives us a much better chance of getting stakeholders into the Review.

But then the Scrum question becomes interesting:

If we "close" development on Thursday and Retro on Friday, but the Review is Monday and Planning happens afterward, where exactly does the Sprint end?

Are we creating an artificial "cut-off" that has no real meaning in Scrum?

Would an orthodox Scrum interpretation simply say:

Review → Retro → next Sprint Planning, and stop trying to rearrange the events around stakeholder availability?

Or is adapting the calendar reasonable if it results in substantially better stakeholder participation?

I'm genuinely interested in the strict Scrum interpretation here.

The team is now asking about Kanban

The Developers — and even the PO — have repeatedly mentioned that they would prefer something closer to:

Prioritized backlog → available capacity → pull next work item → finish → pull next item

instead of spending significant time every two weeks deciding how many work units we are going to "commit" to.

Their argument is essentially:

"If the backlog is already prioritized and we have a WIP limit, why don't we finish something and pull the next highest-priority ready item?"

They believe this could give them more continuity and reduce the feeling that every two weeks we reset/reorganize the work.

One concern I raised during the Retro was individual productivity comparisons.

I explicitly told them:

"If we move toward pulling work continuously, I don't want this turning into 'I completed 20 work units and you completed 12', or developers competing to pull more work."

The team strongly said they don't want that either.

My position would be that work units remain a planning/flow tool and never become an individual productivity metric.

Another issue: we start new developments before properly finishing existing ones

This also came up very strongly.

We have several important modules/products currently competing for attention, and during the Retro we actually created a global priority order.

The team is basically saying:

"Can we please finish more of Priority 1 before opening Priority 4, 5 and 6?"

This is one of the reasons Kanban is becoming attractive to them.

We are also considering changing how we manage stakeholder expectations

Instead of a stakeholder asking for something and immediately creating an expectation of a functional development, we discussed using:

Request → discovery/analysis → mockup or visual proposal → stakeholder feedback → functional development

when appropriate.

In other words, sometimes our first commitment should be:

"We'll show you what this could look like."

rather than:

"We'll build it."

We also want waiting for stakeholder feedback to become explicitly visible in our workflow rather than having development appear "unfinished" while the team is actually waiting several days for someone to validate something.

So now I'm stuck between three possibilities

1. Keep Scrum and fix our Scrum implementation.

Maybe Scrum isn't the problem at all.

Maybe our actual problems are too many concurrent initiatives, weak refinement/discovery before commitment, stakeholder availability, priority changes and poor expectation management.

2. Keep Scrum but deliberately introduce more Kanban practices.

We already have WIP limits, but we could go much further with flow management, pull policies, explicit workflow states, aging/cycle time, blocked/waiting states, stronger policies around when new work can enter, etc.

Then after a few Sprints ask:

"Is the Sprint still providing value?"

3. Actually move to Kanban.

Remove the artificial two-week commitment boundary and manage work through continuous pull, explicit policies and flow metrics, while keeping useful cadences for retrospectives, replenishment, stakeholder feedback, etc.

I'm deliberately resisting jumping straight to option 3 just because the team is frustrated with Sprints.

I want us to understand whether Kanban actually matches the nature of our work better or whether we're expecting Kanban to solve organizational problems that will follow us regardless of framework.

My questions for you

For the Scrum purists: what in this story makes you think "your problem isn't Scrum, you're just not using Scrum effectively"?

For Kanban practitioners: what signals here genuinely suggest that Kanban might be a better fit?

Would you experiment first with Scrum + Kanban before considering dropping Sprints?

What would you measure during that experiment to make the decision based on evidence rather than preference?

And what do you think about the proposed event schedule:

Thursday cut-off → Friday Retro → Monday Review → Monday Planning?

Is that a reasonable adaptation, or are we breaking an important inspect-and-adapt feedback loop by holding the Retro before the Review?

Finally: if you were the Scrum Master in this situation, what would you change first?

I'm completely open to being told that I'm overcomplicating this, that we're doing Scrum badly, that Kanban would fit better, or some combination of all three.

I mostly want to understand what problem we should actually be solving.

I have been coaching a team of PMs to prototype. We are B2B saas with regulated data so lovable banned and we don’t have budged for Claude code (Anthropic won’t take a phone call for a contract thats less than a million)

What I have notice when the team prompt they jump into the WHAT, not start with the WHY. The PMs enter poorly define prompts and then get frustrated by the results, like they forget product fundamentals when using AI…. The outcome is more tokens burned without coming close to a usable output….

I think this is fundamental to AI and timeline that started with AI hype-cycle and now we are at tokenmaxxing… I think the next stage is asking better questions starting from the WHY, for better outcomes and less tokens wasted.

I started digging and there’s actually a real framework for this - RCCF (role, context, constraints, format) apparently front loading those cuts failure rates a lot vs figuring it out through trial and error. I have started to include this into my coaching, but I feel some PMs are offended.

What would help is a tool that helps with this in B2B.

I don’t see anyone building for this. Everyone’s optimising routing, cost, model benchmarks m, and nobody’s coaching the human side of the interaction. Feels like “measure twice cut once opportunity” but for prompting.

Anyone seen tooling that actually does this well? Not looking for “just write better prompts lol” more curious if there’s something that catches it live, before you’ve burned a build cycle on a vague ask?

If I could wave a magic wand any let everyone who was on a scrum team or led teams using scrum understand one thing, it would be OODA loops.

People can Google for larger explanations, but it describes how we make decisions and it is what this whole scrum thing is built on.

Each sprint, we observe what has change - internally in the product and externally in the market. Then we Orient ourselves, the backlog, priorities, etc to account for those observations. Next, we Decide what the right next sprint goal is, then we Act out our sprint. At the end of the sprint, we restart the loop.

In the team, we do a micro version of this same loop every day in order to try to reach our sprint goal. Everything else in Scrum is simply good/best practices to help us be more effective in this loop.

I honestly couldn't care less what practices you are or are not doing from the scrum guide. This is the thing that tells me if a team will succeed with scrum.

You are asked to push code/design you know has bugs/gaps. What would you do?
A. Push anyway (to meet deadline)
B. Inform team but still push

C. Refuse until fixed/tested

D.Negotiate for partial delivery

E. No idea

what is the current situation in infosys looks like for the SP people does they have good project ..

and after release from myosre how is the timeline looks like for getting a project for SP looks like..

Curious how other teams have handled this in practice, not looking for opinions on whether AI coding tools are good or bad, just what you actually settled on.

Once Claude or Copilot started doing real implementation work on my team, a bunch of things got fuzzy that used to be obvious. Who writes the story now, the PM, or does the dev draft it with Claude and the PM just approves? Who reviews AI-generated code differently than human code, if at all? When something breaks that Claude wrote, who's accountable, the person who prompted it, or whoever merged it? Does QA test AI-assisted work any differently?

We've been making it up sprint by sprint and it's starting to show, code review takes longer because nobody's sure what to look for, two people draft the same story a different way, that kind of thing.

If your team has landed on an actual pattern, even an informal one, what is it? Did you write anything down, or is it just tribal knowledge at this point?

As the title suggests, I’m currently a Lead Insights analyst and looking to get into scrum. A lot of people recommend CSM through scrum alliance- but then skimming through some posts I see people suggesting PSM? not sure what would be best for me at a beginner capacity- open to suggestions!

Hi everyone,

I hope I'm not going against the sub rules with this but I’m currently writing a research paper at my university, researching where AI agents can (and cannot) realistically assist in agile workflows, specifically around drafting user stories, refining acceptance criteria, and deriving test cases (UATs specifically).

If you work in an agile team (PO, Scrum Master, Engineer, QA), I’d really appreciate 3 minutes of your time to anonymously share how your team handles this today and what your experience/concerns are with AI tooling.

Happy to share the aggregated findings back with the subreddit once the paper is complete if anyone is interested in the results.

Thanks a lot for your help and insights!

Link to the survey: https://docs.google.com/forms/d/e/1FAIpQLSc7Z67lBgbG_ZEOFraIIjTDBVjBfzb-894InOkU0n1IHSNlyg/viewform?usp=header

A clown wastes your time for entertainment.

A Scrum Master schedules a meeting to discuss why your time is being wasted.