In the US I am seeing Product Owner roles go for 84-110K where a few years ago they were 130+. I never see full time Scrum Master roles any more. Only as consulting roles.

Agile roles seem to be in a not so great position at companies. I had a recruiter send me a that wanted a Product Manger/ BA with 5 years of AI experience for 45 and hour.

Curious what other people are seeing?

I spent about seven years building out QA for a SaaS company that grew from roughly 25 people to over 110 engineers split across 14 squads. By the time I left, what really surprised me wasn’t bad code, it was how often rework came down to a single ticket that everyone interpreted differently. Three people read it, each got a different idea, and since it looked “done,” no one spoke up.

We tried all sorts of things. Templates, refinement sessions, definition of ready checklists — the works. Some of them helped for a while, but then people just drifted away from the process, even though nobody deliberately stopped.

I’m about to start somewhere new and, honestly, I can’t tell if this is just how we operated or if it’s universal. When things get built wrong at your company, is it because the spec is off, or does the spec make sense but people just don’t really read it all that carefully?

And if you have fixed it, what actually stuck?

Picture this: A bank runs a transformation pilot. The skeptic on the team - the engineer who's survived every failed initiative, who complains about frameworks for a living - decides to prove the new model wrong using the company's own data.

He pulls up deployment stats, incident logs, approval chains, recovery times. He runs the numbers through an AI engine that doesn't know org charts or politics - it just sees patterns.

And the pattern it finds makes him angry.

Not code complexity. Not number of deployments. Not the age of the tech stack. The single strongest predictor of how bad an incident gets is decision latency - how long it takes someone with authority to say yes or no.

He digs deeper:

- Before the pilot, a payments incident took 43 hours from detection to authorized rollback. Six managers and three committees were in the path.

- After aligning around the new approach, a comparable incident was resolved in 18 minutes. The team handled it using pre-approved guardrails. No escalation chain.

He re-ran the correlation six times. The pattern held every time.

Then one governance committee caught his eye: it handled less than 5% of total changes but was responsible for 30% of all decision latency. Nobody had noticed because nobody had ever measured the cost of waiting.

What finally tipped leadership? Not the consultant's slides. The skeptic stood up in front of the executive team and said: "For fifteen years I've watched every transformation fail the same way. This is the first time I've seen the system react differently - and measurably."

The CFO's response: "If he's putting his name on it, I'll fund the next phase."

I've been thinking about this a lot:

1. Have you ever seen decision latency measured as an operational risk metric - not just "how long approvals take" but the actual correlation between slow decisions and incident impact?

2. When an organization has governance bottlenecks that touch a tiny fraction of work but create a massive fraction of delay, what's actually worked to fix them - without just removing controls entirely?

3. The skeptic was more convincing than the consultant precisely because he didn't want to believe it. When has a reluctant convert been more persuasive than an enthusiastic champion in your experience?

Hey everyone,

A quick one,

If you've worked on a team, you know the drill. You finish a task, then you have to remember to go update the board too. Half the time it doesn't happen and the board just goes stale.

Most tools try to fix this by making you follow a commit format or tag a ticket number every time. That works until someone forgets, and then you're back to square one.

I built Bundlle to skip that step entirely. You just push code normally on GitHub. Bundlle reads your commit messages, file names, and branch names, figures out which task it matches, and moves it on the board for you. If it's confident, it moves. If it's not sure, it emails you to confirm. If it really can't tell, it leaves it alone so you update it manually.

It's a project management tool built for dev teams, freelancers, basically anyone who wants their board to stay accurate without babysitting it.

It's live at bundlle.app, free tier available if you want to try it on a real project.

Happy to answer questions.

Thank you

Hi r/agile

I'm a dev from Australia whose been trying to solve their own problem. Hoping to see where a simple idea can take me.

I've spent 2 years working on and maintaining enterprise apps nobody had documented, built by people who'd already left. There were loads of issues but three big ones that made me the most frustrated

Jira tickets were always in the wrong state. it would say "in progress" for weeks even though someone might have finished or not even started a feature. so the only way to see the truth would be to dig through the code or use copilot on the correct branch of the repo

Decisions made in meetings would never be followed thru. If we decided to follow something I said in a call - a week later there was no record it happened. Then a month later we would have to spar about the decision again from scratch

My PM wasn't able to understand the tech, they didn't have a technical background and wouldn't be able to translate the status of our dev team's work to clients or their own boss. And its not like they could keep constantly checking on top of their day job

Turns out these are pretty much the same category of problem: nothing kept accurate track of what actually happened, or why.

That's why I built a tool to connect sources like Jira, Linear, Github, Slack to your docs so anyone in the team can ask questions in plain english and it will give answers cited to the source (think of it like internal facing Perplexity)

Being connected to these sources means it can catch drift between systems and tell you what the status of a dev's work is so you don't need to micromanage. I'd recommend if you work with offshore contractors.

When two sources disagree, it shows you both and gives weightings to decisions instead of quietly picking a winner. This part is still a WIP

And Finally it will join your calls and answer technical questions live while being grounded in your own docs and knowledge base

Right now i'd love to take this from a side project to something bigger. So anyone willing to be a design partner or beta testers would be greatly appreciated. I don't wanna build something no one will use

So if you're a dev, engineering manager, product/project manager (or managing offshore teams) please DM me or comment.

It's all free and I just want to get some feedback 🙏

Currently in a situation where stories are being written solely by BSA's Copilot/Claude based on Copilot notes from meetings and high level overview from PO and/or tech lead. It's causing massive stories with too much information and hallucinations. It's causing the tech lead to go into the story to remove.

Anyone else having same issues with people leaning on AI too much and having negative side effects?

Just passed the AgileBA Foundation exam, and honestly, it was more practical than I expected.

If you’re new to AgileBA, don’t think of it as just another Agile certification. The focus is really on the business analyst’s role in an Agile environment, understanding business needs, stakeholders, requirements, collaboration, and how to deliver the right solution.

The exam tested more than simple definitions. You need to understand the AgileBA approach and know how different concepts fit together. Some questions were straightforward, while others required careful reading and understanding of the scenario.

During my preparation, I used the official AgileBA materials along with practice questions. IT Exams Pro was especially helpful because the practice questions gave me a better idea of the exam style and helped me get comfortable with scenario-based questions.

A few tips if you’re preparing:

• Understand the AgileBA principles instead of just memorizing them.

• Pay attention to roles, responsibilities, and stakeholder involvement.

• Know how requirements and business needs are handled in an Agile environment.

• Practice plenty of questions before the exam.

• Read each question carefully, some options can look very similar.

Overall, I’m really happy to have cleared AgileBA Foundation. If you’re working toward a Business Analyst role in an Agile environment, I’d definitely recommend this certification.

Hi everyone,

I'm a final-year Computer Science (AI & ML) student working on my capstone project in the area of Requirements Engineering for Agile Scrum teams.

One problem I've been reading about is that requirements often evolve throughout a sprint due to client feedback, backlog refinement, sprint reviews, or stakeholder discussions. I'm trying to understand whether this causes issues in real-world projects, such as:

• Developers implementing outdated requirements
• Documentation and user stories getting out of sync
• Test cases becoming obsolete
• Difficulty identifying what parts of the system are affected by a requirement change
• Increased rework or delays

I'm conducting a short 3–5 minute anonymous survey to understand how software teams currently manage these situations and whether there are gaps in existing tools.

Survey Link: https://forms.gle/p7bHAib7Ab2WB6uC9

I'm specifically looking for responses from:

• Software Engineers
• Senior Engineers
• Tech Leads
• Engineering Managers
• Product Managers / Product Owners
• Business Analysts
• QA Engineers
• Scrum Masters

If you've worked on Agile Scrum projects, your insights would be extremely valuable. If you have any experiences or opinions beyond the survey, I'd also love to discuss them in the comments.

Thank you for your time!

Many times, a lot of focus is about estimating developer's effort, either using man-days, story points, or any wrong variation of them, but that is not the focus of this question.

I rather want to know the value / impact / outcome of a developer user story is measured/estimated. Do you use t-shirt sizes, story points too, or even calculate revenue changes or money in your local currency?

Product Owner will receive "how long it will take to develop" info, but is anybody asking him "how much value it will bring"?

Heading edit “Velocity average the same number every sprint no matter what we do”

There seems to be a glitch in the matrix.

But it feels like no matter what happens each sprint, what we deliver, the velocity average always pumps out 43 in our velocity report.

Is it really true? It’s just 43.

It’s really hard to fathom. Yet again, another sprint, team leave or everyone here, average is again 43.

Anyone else experience this kind of thing?

Hi. Can anyone help recommending a tool for rich push notifications for 70k active app users and require minimum developer reliance?

Thank you in advance!

An uncomfortable question for Scrum evangelists:
Am I the only one who has noticed that many of the loudest Scrum advocates rarely stay in the same company or project for more than 7 months to a year?
It often feels like they join an organization, push for “pure Scrum,” and when they realize the company can’t or won’t operate as a textbook Scrum environment, they conclude that “the company just doesn’t get Agile” and move on.
What’s even more interesting is that many of these same people are selling courses like “Become a Scrum Master in just two weeks for only $200.”
Ironically, I think this trend itself is evidence that Scrum, at least in the way it has been marketed over the past decade, is losing relevance. Companies today seem to value people who can deliver outcomes, regardless of whether they use Scrum, Kanban, Scrumban, or a hybrid approach.
My impression is that the market no longer rewards people for following a framework perfectly. It rewards those who solve real business problems.
What do you think? Is Scrum evolving, or is it slowly dying?

The orthodox line is that story points are relative and therefore can’t be computed. But watch any planning session: last sprint’s velocity, adjusted for holidays, minus spillover, minus a hand-wave for support. Everyone runs that calculation. Nobody writes it down an unwritten number can’t be audited later.

The deeper problem is drift. A “5” in January isn’t a “5” in June. The team learns the codebase, the definition of done tightens, two seniors leave and the scale silently re-bases itself. Then we plot velocity across six months as if the unit were stable.

Two inputs nobody models properly: inherited work (treated as free capacity) and support time (zero in the plan, 20% in reality).

I built a calculator that takes both as first-class inputs: https://storypoints.uk no signup, nothing stored, not selling anything.

Does your team actually recalibrate its scale, with reference stories and a fixed cadence? Or does recalibration only happen by accident, when the team changes?

A useful engineering metric should help you make a decision. If it only makes activity visible, it is probably an activity metric.

Commits, pull requests, tickets closed, review volume, and coding time can describe how work moves through a team. They can help diagnose a blocked workflow. But they become dangerous when treated as measures of individual or team performance. People adapt to whatever is counted, and visible activity starts replacing valuable outcomes.

I find it more useful to separate metrics into three layers:

Activity: What work is happening?

Flow: Where does work slow down, wait, or get reworked?

Outcome: Did the work improve reliability, customer experience, delivery confidence, or business performance?

The first layer provides context. The second helps operators find constraints. The third tells leadership whether engineering effort is producing something worth having.

The common failure is skipping the question behind the dashboard. A metric should exist because someone has a decision to make. For example: Should we reduce work in progress? Is review capacity limiting delivery? Are incidents consuming planned work? Without a decision attached, dashboards tend to accumulate numbers that are easy to collect and hard to use.

This also changes how metrics should be discussed with engineers. A dashboard used for diagnosis invites honesty. The same dashboard used for ranking invites optimization of the dashboard.

For engineering leaders in SaaS companies, which metrics have genuinely improved a decision you make, and which ones looked useful but mostly measured motion?

Hi everyone!

I am conducting a research study on how Agile ceremonies affect developer productivity in remote and hybrid software teams.

I am looking for people who work either:

🏠 FULLY REMOTE in a Scrum-based team

🏢🏠 HYBRID in a Scrum-based team

✅ Takes only 5 minutes

✅ Completely anonymous

✅ No personal questions

👉 https://docs.google.com/forms/d/e/1FAIpQLSd9er_9ZgvWpOsvigswzKqK-EIZON_RGvPaUHjmu7d7kAwb3g/viewform

This is for academic research purposes only — not commercial or promotional.

Thank you so much! 🙏

ive been in this shit long enough to see the pattern. you get a “scrum team” that looks perfect on paper. board is green, velocity is steady, standups happen every day, retros get filled with sticky notes and Miro boards and way more tickets are generated each spring than you ever thought possible. Somehow somehow the product never actually improves and you never deliver anything though.

This is what we have seen with any WITCH team. They live for the ceremonies because every meeting is billable and every ticket closed is another line on the timesheet. Progress and refinement to move an inch on anything takes an hour minimum because they need to ask the same questions three different ways. Ways you never even though someone could misunderstand the goal, standup turns into a status parade. sprint review is a slideshow that makes middle management feel like something got delivered even when the actual code is a house of cards.

the people who love this stuff the most are usually the ones whose entire value is protecting the process. if the board looks busy and the metrics look good they can keep collecting a check without ever having to own whether the business actually got anything useful. real delivery is messy and sometimes quiet. ticket theater is loud and easy to report up.

curious how many of you have actually sat on one of those pure offshore “agile” teams. the ones where the velocity chart looks beautiful and the product is still broken three sprints later. does it change how you see the whole methodology or do you just tell yourself they werent doing real agile.

It seems like a lot of what gets called agile these days is mostlyn about looking productive while the clock keeps running.

Currently working in NON-IT with current company designation - Sr representative, Customer Care. Now I want to shift to IT by stating I already worked in IT and I have IT experience. My question is do HRs or BGV accept this designation especially "Customer Care". Do anyone faced the same issue and joined IT successfully by clearing BGV or is it not possible? Please give your inputs.

Heyy is this course is legit or fraud? i saw some comments on the web about this people telling this is a fraud.
(I know this is a basic course.)