backlog management Archives - Scrum Master Toolbox Podcast

Maria Skvortsova: The Yes-Man Product Owner and the Scrum Master Who Became a Proxy for the Proxy

In this episode, we refer to User Story Mapping and the MoSCoW prioritization method.

The Great Product Owner: Structure Over Gut Feeling — When a Well-Shaped Backlog Speaks for Itself

“The indicator of a good product owner is a well-shaped backlog — with priorities, with values, with efforts. You definitely know that you pull from the top, and it is the most valuable thing you should work on.” — Maria Skvortsova

For Maria, the best product owners she’s worked with share one trait: they bring structure. Not rigidity — structure. They use techniques like user story mapping to make priorities visual for everyone. They use value-effort matrices instead of gut feelings.

They apply methods like MoSCoW to give the backlog a clear, unambiguous order. The result? A developer never has to ask “what should I work on next?” — the answer is always at the top of the backlog. Maria, drawing on her decade as a C++ developer, knows firsthand how frustrating it is to chase down a BA or PO just to figure out what to build next.

A well-ordered backlog doesn’t just help the team move faster — it also makes it easier for the product owner to communicate with the business, because every decision has data behind it, not just intuition.

Self-reflection Question: Could a new team member look at your product backlog right now and immediately know what to work on next — and why that item is the most valuable?

The Bad Product Owner: The Yes-Man Who Sank the Ship — When Saying Yes to Everything Means Delivering Nothing

“He was always saying yes. And this led to the scope that grew and grew, until we realized we were not capable of delivering what we committed to.” — Maria Skvortsova

Maria returns to her SAP migration experience for this anti-pattern. The team had a team lead acting as product owner — someone technical who saw everything as important.

Every new requirement got a “yes.” The scope ballooned while the iron triangle held firm: fixed cost, fixed time, no room to breathe. The team reached a breaking point where they had to admit, to each other and to the client, that delivery was impossible. Maria stepped in as what Vasco called “a proxy for the proxy” — she helped the team lead build a user story map on Miro, then facilitated a workshop with the business.

Her question was disarmingly simple: “If we don’t deliver this by go-live, will your product still function? If yes, it goes to release two.” That reframing — not “no” but “yes, later” — gave the client clarity without triggering defensiveness. The team lead learned that business stakeholders aren’t the enemy; they just need someone to help them make honest trade-offs. And saying “not now” is infinitely more useful than saying “yes” to everything and delivering nothing on time.

Self-reflection Question: When was the last time you or your product owner said “not now” to a stakeholder — and did it feel like a failure or a strategic decision?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!

About Maria Skvortsova

Maria is a Delivery Manager and Agile Coach who thrives in complexity, bringing clarity to chaotic environments. With a decade in C++ development and a background in professional opera, she blends technical precision with human empathy, helping enterprise teams move beyond task execution to collaborate seamlessly and perform like a synchronized, high-impact orchestra.

You can link with Maria Skvortsova on LinkedIn.

Christian Thordal: The Jazz Duo Effect and The Absent PO — Two Sides of Agile Product Ownership

The Great Product Owner: Clarity, Accountability, and a Partnership That Fills in the Blanks

“We kind of filled in the blanks for each other, and it felt very natural — it’s grown organically into this partnership where we’re extremely aligned on how we see and do things.” – Christian Thordal

Christian describes his best Product Owner as someone he currently works with — a person who combines deep product clarity with genuine leadership. This PO is fully accountable for the backlog, sets clear expectations toward the teams, and isn’t afraid to push them.

What makes this PO stand out is how they use reporting as a communication tool: alongside the backlog, they proactively communicate to the product leader whether things are within or outside scope, always with a plan ready. Christian and this PO hold weekly follow-ups to discuss the team, the backlog, and the product direction.

Over time, their alignment has become so strong that during facilitation sessions they naturally fill in blanks for each other — one picks up where the other leaves off. Vasco compared it to a jazz duo, where each musician picks up on the other’s leads in real time. This kind of organic partnership in leadership direction reflects positively on the entire team, creating a sense of coherence and momentum that everyone can feel.

Self-reflection Question: How aligned are you with your Product Owner on leadership direction, and what would it take to build the kind of partnership where you naturally fill in the blanks for each other?

The Bad Product Owner: When the PO Disappears and the Scrum Master Becomes the Glue

“You can inspire, you can motivate, but you can’t really do the work for them.” – Christian Thordal

Christian shares an experience from a larger logistics company in Denmark where the Product Owner was a great, likable person — but didn’t understand the role. The backlog was high-level, consisting primarily of Epics with no acceptance criteria. Then the warning signs started: the PO became increasingly hard to get a hold of, started canceling refinement meetings (sometimes on the same day), began working more from home, and became physically more distant from the team.

Christian and the team were left to navigate on their own, breaking down epics into stories and tasks without knowing if they were building the right product. Christian tried setting up weekly one-hour sessions to help the PO work through the backlog, but the fundamental problem remained — you cannot do the PO’s work for them.

Eventually, Christian found himself filling in for the PO, which is itself an anti-pattern: the Scrum Master becoming the glue that holds the product together. The symptoms to watch for are clear: a PO who starts missing meetings, backlog items that remain unrefined, a PO who becomes physically or remotely distant, and — the biggest red flag — a Scrum Master who feels compelled to step in and do the PO’s job.

Self-reflection Question: Are there signs that your Product Owner is drifting away from the team, and have you caught yourself filling in gaps that aren’t yours to fill?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Christian Thordal

Christian Thordal is a former Danish Army officer turned Agile Coach. He works with leaders and teams to create clarity, accountability, and momentum in complex organizations. His approach blends military leadership principles with modern product development, helping organizations move from discussion and strategy to real execution and measurable results.

You can link with Christian Thordal on LinkedIn.

Christian Thordal: How “Fake Kanban” Fooled the Metrics, And What This Agile Coach Did to Fix It

“The team was like birds in a nest waiting to get fed — completely dependent on the PO for every piece of work.” – Christian Thordal

Christian tells us about a team that always appeared busy but was hiding serious dysfunction behind a single healthy metric. When he rated the system across his domain, he found the team scored low in process maturity, effectiveness, and learning — yet their cycle time looked good.

The team claimed to practice Kanban, but in reality it meant “we can do whatever we want.” Daily standups had become social check-ins. The backlog held over 100 items to do and 50+ in progress, most of them just headlines with no descriptions. Real work assignments happened through 30-minute Slack huddles between the PO and individual developers — pure push, no prioritization.

Despite having OKRs, the team could only plan a week ahead. Christian’s fix was radical: he restarted the backlog entirely, cutting 150 items down to roughly 30, established WIP limits to create a pull-based system, and brought the team into the process as active participants rather than passive recipients.

In this segment, we refer to Kanban and OKRs.

Self-reflection Question: When was the last time you looked beyond a single “green” metric to understand what was really happening in your team’s workflow?

Featured Book of the Week: Turn the Ship Around by David Marquet

Christian recommends Turn the Ship Around by David Marquet, a former U.S. Navy submarine commander who transformed his crew’s performance by replacing permission-seeking with intent-based leadership. Instead of waiting for orders, crew members were expected to say “I intend to…” — transferring ownership and making people accountable for their decisions.

Christian says this deeply resonated with his own military background in the Danish Army, where leadership operated on similar principles. The book’s core message — stop creating dependency and start building leaders at every level — connects directly to the team story in this episode, where passive dependency on the PO was the root of the dysfunction.

You can also listen to previous episodes with David Marquet and explore more on intent-based leadership.

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Christian Thordal

You can link with Christian Thordal on LinkedIn.

Christian Thordal: When Applying Scrum By The Book Fails, Understanding Context Before Changing The System

“I treated Scrum like a military SOP — follow the book, execute the steps. But I failed to see that the context was really the tipping point. What looked like a problem was actually their solution.” – Christian Thordal

Christian shares a hard-won lesson from his time coaching three RPA teams at one of Denmark’s largest banks during the pandemic. He inherited teams running six-week sprints with half-hour planning sessions that amounted to little more than putting items on a calendar. As a former Danish Army officer, Christian’s instinct was to fix the obvious deviation from the Scrum Guide — the sprint length.

He advocated for shorter feedback loops and eventually convinced the Product Owner, who also served as the director, to try two-week sprints. The first planning session was a disaster.

There was yelling and scolding, and it became clear that the real problem had nothing to do with sprint length. The teams had no proper backlog. The six-week sprints actually worked because they gave teams enough time to go out to the business, discover work, and deliver it within a single cycle.

Christian realized he had been applying Scrum mechanically without understanding how work entered the system. He started attending business analyst and PO meetings, uncovered the backlog gap, and helped the teams build a proper one. His key insight: what looks like a symptom can actually be a pragmatic solution to real constraints. Understand the system before you change it.

In this episode, we refer to the book Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland.

Self-reflection Question: When was the last time you assumed a team’s practice was wrong, only to discover it was a reasonable adaptation to their context? How might you investigate the “why” behind existing processes before proposing changes?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Christian Thordal

You can link with Christian Thordal on LinkedIn.

Nate Amidon: The Leadership Void — What Happens When Product Owners Forget They’re Part of the Scrum Team

In this episode, we refer to Nate’s previous BONUS episode on the brief-execute-debrief cycle and alignment.

The Great Product Owner: The Team Player Who Leads From the Trenches

“The best product owners are really part of the team. They attend all the ceremonies, they give their daily stand-up status, they’re shoulder-to-shoulder in the trenches.” – Nate Amidon

For Nate, the best product owners he’s worked with share one defining trait: they act like teammates, not managers. They show up to daily stand-ups and report on what they worked on, what they completed, and what they’re blocked on — just like everyone else. They listen to ideas from the team without being dismissive, recognizing that engineers often know the user just as well as they do. They don’t treat the product owner role as a position of authority over the team, but as a different function within the same unit.

Nate draws from his military background: leadership is “care and feeding of the people.” When product owners internalize that the team’s success is their success — when they feel genuine allegiance to the people they work with — backlogs get better organized, priorities become clearer, and collaboration happens naturally. As Vasco adds, alignment is the real purpose behind Scrum ceremonies, and when POs are there, alignment follows.

Self-reflection Question: As a product owner, do your team members see you as someone who is part of the team — or as someone the team works for?

The Bad Product Owner: The Leadership Void That Creates Corporate Game of Thrones

“It eventually becomes a leadership void on the team that someone will step up and fill — and usually it’s an engineer, or the Scrum Master becomes a quasi-product owner.” – Nate Amidon

Nate views the product owner role as fundamentally a leadership position — leadership of the backlog, prioritization, and the connection between business needs and team execution. When a PO doesn’t embrace that responsibility, the symptoms are predictable: throwing half-baked stories over the fence with a “just figure it out” attitude, constantly shifting priorities without considering the downstream impact on a team that just spent two weeks building something, and being absent from the daily conversations that keep everyone aligned. What follows is what Nate calls a “leadership void” — someone else on the team, often an engineer or the Scrum Master, steps in as a quasi-product owner because the work still needs direction.

Meanwhile, without a PO acting as a filter, stakeholders start shoulder-tapping the team directly, competing directors play corporate Game of Thrones over whose priorities win, and the team gets whiplashed between conflicting demands. The biggest red flag? When you hear the team say: “We just did what you told us.”

Self-reflection Question: If your product owner disappeared for two weeks, would anyone on the team notice a gap in leadership and direction — or has someone already quietly stepped in to fill that void?

Transform Your Agile Teams with Hard-Earned Lessons from Super-Experienced Scrum Masters

About Nate Amidon

Nate, founder of Form100 Consulting, and a former Air Force officer and combat pilot turned servant leader in software development. Nate has taken the high-stakes world of military aviation and brought its core leadership principles—clarity, accountability, and execution—into his work with Agile teams.

You can link with Nate Amidon on LinkedIn. Learn more at Form100 Consulting.