When "Agile" Becomes a License to Change Everything, The Cost of No Rules in Backlog Management | Iryna Stelmakh

Summary

---

Scrum Master Toolbox Podcast: “When 'Agile' Becomes a License to Change Everything, The Cost of No Rules in Backlog Management”

Guest: Iryna Stelmakh
Host: Vasco Duarte
Release Date: March 23, 2026

---

Episode Overview

This episode dives into the pitfalls teams face when “Agile” is misconstrued as an excuse for constant change and chaos, particularly in backlog management.
Iryna Stelmakh, an experienced Agile coach and project delivery leader, joins Vasco Duarte to share her real-world story of “failure,” highlighting what happens when the foundational rules of Scrum are ignored—especially by clients who see flexibility as carte blanche for unstructured and uncontrolled change.
The discussion focuses on how this mentality leads to disorder, higher costs, broken predictability, and the vital importance of clear agreements with stakeholders.

---

Key Discussion Points & Insights

1. Iryna’s Journey to Scrum Mastery

• Background:
  • Iryna has 15+ years experience in both Eastern Europe and the US, working at the intersections of business transformation and human systems.
  • She started before the Scrum Master role was common and noticed early that most project issues stemmed from communication/procedural issues, not technical ones.
• Quote:

  “Most project problems were not technical actually problems, but that was about communication, decision problems, collaboration, etc.”
  — Iryna, [02:46]

2. The Challenge: When “Agile” Becomes a License for Chaos

• Client Situation:
  • Managed a project where the client (from Israel) believed “Agile” meant unlimited change—adding to both the product and sprint backlog at any time.
  • There were effectively “no rules,” leading to a constantly shifting backlog and relentless change mid-sprint, much to the team's (and Iryna’s) frustration.
• Quote:

  “For him ... he could bring everything that he could and [have an] extended backlog, not just product backlog but Sprint backlog as well, just many times per Sprint.”
  — Iryna [06:19]

  • Client’s pushback came from their perceived urgency:

  “[He said] he is right and the business needs are high and we have to add that task as well. That’s why I have to agree.”
  — Iryna [07:13]

3. The Cost of Uncontrolled Change

• Host’s Reflection:
  • Vasco underscores the burnout and chaos constant mid-sprint changes cause, recalling early Scrum training’s emphasis on sprint cancellation being an “extreme” (and rarely-used) measure.
  • Quote:

    “If you stop the sprint, we break the whole idea of the Agile ... you need to stop everything you’re doing and you need to throw it away.”
    — Vasco [08:19]

• Iryna’s Learning:
  • Unchecked changes increased costs and destroyed predictability.
  • She admits the mistake:

    “For me it was pretty hard to explain that Agile is about cost reduction and not about cost increasing.”
    — Iryna [07:37]

4. Rebuilding Trust and Structure

• The Turning Point:
  • After the chaotic project, Iryna recognized that project agreements and clear working methods must be set up before work begins—especially if clients are unfamiliar with Agile.
  • She now ensures these principles are part of both contracts and early discussions:

    “We have to explain, we have to declarate. We had put it into the contract before signing and then it would be easier ... not just in composition, but also the technical documentation and how we execute.”
    — Iryna [11:18]

  • Host’s Key Takeaway:

    “Collaboration starts with that agreement first.”
    — Vasco [12:25]

5. Practical Advice for Scrum Masters and Teams

• Educate clients early in the sales phase about how Scrum works and its boundaries.
• Set clear rules for handling backlog changes—move new items to the product backlog, do not disrupt active sprints unless absolutely necessary.
• Document working agreements and expectations contractually and operationally.
• Recognize that changing a sprint is “expensive”—do not treat it as trivial.

---

Notable Quotes & Memorable Moments

• On Scrum Adoption Reality:

  “Scrum was only actually used as a label, but in real life we were working with the chaotic backlog with all time long change requirements.”
  — Iryna [04:50]

• On the Backlog as a 'Convenient Change Request List':

  “[The] client literally joked that Scrum was just a convenient way to send change requests all the time.”
  — Iryna [05:08]

• On Learning and Repair:

  “We made few sessions, I talked with him, I explained how it works ... we set up the process and then it was easier and all the new tasks were moved to the product backlog and prioritized accordingly.”
  — Iryna [11:53]

---

Important Timestamps

• 01:16 – Iryna’s introduction and background
• 06:06 – Introduction of the “failure” story and the rule-less backlog
• 08:02 – Discussing operational cost and when to stop (cancel) a sprint
• 09:58 – Correct way to handle change requests and learning from the experience
• 12:22 – Importance of agreements with clients and concluding thoughts

---

Episode Tone

The conversation is candid, honest, and practical, couched in real-world anecdotes and friendly banter. Both speakers encourage learning from mistakes and approach their stories with humility and a desire to help others avoid similar pitfalls. There’s an undercurrent of persistent optimism and emphasis on growth, both for teams and individuals.

---

Summary Takeaways

• “Agile” is not a license for chaos. Clear structure, contracts, and alignment are essential—especially with external clients.
• Team predictability and cost control depend upon maintaining the rules of Scrum, particularly around the backlog and sprint integrity.
• Education and early mutual agreement with clients pay dividends and prevent later pain.
• Repair is always possible—by resetting expectations, clarifying roles, and reinforcing good practices, teams and clients can return to effective Agile collaboration.

---

Transcript

[A]

Hello everyone. Quick heads up before we start today's episode. The Global Agile Summit is happening on May 4th. Yes, May 4th. And even with a big blowout Star wars party you have to join. It will be online and it's like always free to attend. We have four tracks this year that I'm really excited about and I think you will too. Stick around to the end of the episode to know what they are. If you want to check it out already now you can check it out at bit ly globalagile 26. That's the numerals 2 and 6 at the end. So one more time, that's bit ly globalagile 2, 6, all one word, all lowercase. And 2 and 6 are the numerals 2 and 6. So stick around till the end of the episode and I'll tell you what's in store. But for now, on to today's episode. Hello everybody. Welcome to one more week of the Scrum Master Toolbox podcast. And this week, joining us from Ukraine is Irina Stellmak. Hey Irina, welcome to the show.

[B]

Hi Vaska. Hi everyone. Thanks a lot. Absolutely happy to be here.

[A]

And before we go any further, let me just say on behalf of our whole community, we hope that you are keeping safe and we wish you all the best.

[B]

Thank you a lot.

[A]

Let me tell you a little bit about Irina. She's a project and delivery leader and agile coach who helps leaders turn complexity into clarity. I like how you phrase that. With more than 10 years across the US, Nordic and Eastern European environments, she works at the intersection of business transformation and human systems, building resilient organizations and high performing teams in complex contexts. And of course we're going to hear a lot of those stories that brought you to that, I would say bio, that experience that you've collected over the years. So tell us a little bit more about yourself, Irina and how did you end up becoming a Scrum Master?

[B]

Yeah, that's a good question and a bit funny. By the by, about myself. Thank you for the introduction. First of all, Vasco, my name is Irina Stenmach and I am project and delivery lead and agile coach. With more than 10 is almost more than 15 years of experience working with teams across Eastern Europe and America, US based companies. My work sits in the intersection of business transformation and human systems, helping teams and early organizations move from complexity and chaos into clarity. As you said, ownership and sustainable delivery. Because this is the most painful point for everyone in it. So about my path to the Scrum Master. Actually my path started even before the Role itself existed in the companies where I worked. When I first started in IT industry, I didn't yet know exactly which role I wanted. I started by looking how different teams worked and what roles existed inside tech organizations. And on my opinion, I realized that project managers like the people who solved everything, everything. And that was the beginning actually. And they connected business, developers, stakeholders, like we say now. Yeah. And the whole delivery. So very quickly I realized something interesting. Most project problems were not technical actually problems, but that was about communication, decision problems, collaboration, etc. And that's why I stepped into Agile and Scrum. That was my first introduction to that site and at the moment I really stayed with a great stakeholder that was integrated biometrics. You can Google it. So this is the public information. Nothing about NDA breaking or so we are safe. Yeah, that project was one of the first where I experienced Scrum done properly because I had experience even before, but that was really mature people, mature clients with a technical background and that was possible to talk with them about the methodology, the most appropriate way of the implementation of that methodology. And yeah, that's why we started with Scrum. And yeah, it was very different from some earlier projects where Scrum was only actually used as a label, but in real life we were working with the chaotic backlog with all time long change requirements, etc. You know? Yeah. And one more project, for example, the client literally joked that the Scrum was just a convenient way to send change requests all the time.

[A]

Oh wow. Yeah, I've seen that happening because there's also a lot of people or a lot of teams that kind of burn out because of the constant change that happens when you have, quote unquote, an open backlog that everybody can look into and make changes.

[B]

Right.

[A]

Today's Monday, so we explore one of those stories where we, the Scrum master, didn't do so well. It's a story of failure. But of course we talk about that because we want to learn from the story. So Irina, share that that story with us. We'll dive into the details and the takeaways later. But tell us that story first

[B]

about the failure. Right, that was actually I have many stories regarding the failure, but let me step into the main one. It was pre team actually it was pretty hard to work with one of the client. The client was from Israel and actually from his meaning this cram was about the agility and the agility was about the. About actually everything for him. So he could bring everything that he could and be extended backlog, not just product backlog but Sprint backlog as well, just many times per Sprint.

[A]

So it meant no rules, basically.

[B]

Actually, yeah. Yeah. And that's why it was. For me, it was pretty hard. It was one of the first projects that I managed that I worked as Chrome Master 4 project, let's let's say correctly. And it was pretty hard for me then to work with that client because when I started explaining him, he did a step back and he explained me that he is the right. He is right in the date and the business needs are high and we have to add that the tasks. The task as well. That's why I have to agree. And for me it was pretty hard to explain that Agile is about cost reduction and not about cost increasing. And by this backlog stacking with tasks that are added one by one, we are increasing the cost of the budget. Yeah. And it was the first time where I didn't manage properly. One of the first projects that I had.

[A]

That story kind of reminds me of this idea and I don't know if you ever were exposed to that, but very early on in the Scrum training cycle, so like early 2000s, one of the exercises that we would go through in the CSM class, the certified Scrum Master class, was kind of a joke, but it was like, what would you do when the backlog changes? And it changes so much that it's got nothing to do with what was there at the beginning of the Sprint. And one of the things we talked about is we need to cancel the Sprint, right? Like, we need to stop it. Right. And this was kind of talked about as a little bit in a light mood, not very seriously, but over, over the years I kind of realized that we don't do that enough because canceling a Sprint is actually a very heavy operation. First of all, you need to stop everything that you're doing and you need to throw it away. So everything that you started is now not started. Right. And then you need to restart the Sprint. So you need to do another Sprint planning and you need to select what goes into the Sprint. But because there's no cost right now in kind of disrupting the Sprint, then it's so easy to just, hey, do one more. Hey, do one more. Hey, do one more. Hey, do one more. And you basically destroy the whole idea of why the Sprint was there. Right. In that case, I'm not sure if you could give that message to the client at that stage, but after that, have you been able to share that idea that disrupting the Sprint so much actually should cost? Because it's the only way we are going to give value to what the spring bring Sprint brings. Which is kind of this short term predictability, right?

[B]

Yeah, that's. That's right. You are fully right. Because actually if you stop the sprint, we break the whole idea of the Agile. That's why it is the easiest way there. Just to support the ceremonies, just to support the process of the Scrum methodology itself. That's why if you have some change requests, it is much easier to move it to the next sprint or to reprioritize within using the ceremony. Like we say, not the ceremony now in the new Scrum guide, but the meetings again. Right. So do the prioritizing via grooming but not canceling itself just because it would be more expensive. And in my case, yeah, I was able to explain but after that situation we realized that when we sell the project, when we talk with the client on the per sale phase, we have to explain the way how we work. We have to share with him what are the benefits. We suggest as the market experts in it and in this case we are storytelling, we are teaching clients as well. If this is not a technical client, so he is not, it is not necessary for him to know all of that things. Right? So we have to explain, we have to declarate. We had put it into the contract before signing and then it would be easier, you know, not just in composition, but also the technical documentation and how we execute. So yeah, from my side I did a mistake because I haven't checked the documents, I haven't checked it with presale team and engagement. And that's why I stuck with a situation where the client wasn't ready to work with me in the Scrum methodology. But then we made few sessions, I talked with him, I explained how it works and I explained what are the benefits, why we could aim and how we could reach those benefits. And yeah, we set up the process and then it was easier and all the new tasks were moved to the product backlog and prioritized accordingly.

[A]

Absolutely.

[B]

That was a good suggestion for me.

[A]

That's actually a great story and a great tip. Right, like we need to start by having that agreement with the client and teams that work with external clients or other external teams need to be aware that the collaboration starts with that agreement first. So great story. Thank you for sharing that with us.

[B]

Irina, welcome always.

[A]

Hi there friends. Thanks for sticking around till the end of the episode. So let me tell you what's coming on May 4th. We're running the Global Agile Summit. It will be online and I want you there. This year we have four tracks and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work just like you. The first track is AI in organizations where practitioners show what actually works. No hype, just AI that makes your Monday better. Happy Monday, everybody. And then we have the people track honest conversations about putting humans on at the center of how we work and keeping them there. And third is Agile in Construction. And yes, I really mean brick and mortar construction. Lean and agile. Actual job sites. Field leaders removing waste. Teams transforming how buildings get built. Stay tuned for what I think will be a super track on Agile in construction. And the fourth track is Agile in Gaming. How game studios ship without burning out Agile Inside the Creative Pressure Cooker over the years we've had more than 12,000 participants since 2017, the time of the first summit organized with the podcast, and this year we're making it easier than ever to join. You can register for free and get access to the summit sessions live during the event week. That's May 4th to May 6th. Or you can grab the Practitioner Pass and get immediate access to last year's keynotes from Jurgen Apollo, Gojko Adzic and Mirete Kangas right now, even before the summit starts. So grab your Practitioner Pass and start learning today. Head on over to bitly globalagile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit ly globalagile 26. All lowercase, all one word and 26. That's the numeral 2 and the numeral 6. I'll see you on the conference floor.