The Team That Decided Sprint Goals Were Optional | Alf Dobbert-Baums

Summary

Podcast Summary

Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Episode Title: The Team That Decided Sprint Goals Were Optional | Alf Dobbert-Baums
Host: Vasco Duarte
Guest: Alf Dobbert-Baums
Air Date: July 21, 2026

---

Episode Overview

In this episode, Vasco Duarte and guest Alf Dobbert-Baums explore the dangers of teams treating sprint goals as optional or unimportant. Alf shares a real-world story from his coaching experience about a team—and, by extension, several teams in a company—who consistently failed to value, align on, or focus around sprint goals. The discussion covers the organizational and psychological roots of this problem, the impact it had on team performance and collaboration, and actionable lessons for Scrum Masters.

---

Key Discussion Points & Insights

1. Books That Inspired Alf as a Scrum Master

• [01:42] Alf cites "Humble Consulting" by Edgar Schein and "Don't Just Do Something, Stand There" by Marvin Weisbord as pivotal.
  • These books taught him the power of asking questions and the value of adaptability as a facilitator.
  • Quote [03:32]:
    "Within five minutes, the whole thing changed. The topic changed, everything changed. And I was like, what? I was screaming in my head, 'No, my agenda, my workshop. It's gone.' ...But yeah, basically it wasn't important topic and it was very relevant and urgent for the team. And so I said, okay, let's go with the flow." — Alf

2. Story: A Team That Ignored Sprint Goals

• [04:58] Alf describes a team (within a structure of multiple teams he coached) that consistently disregarded sprint goals.

  • None of the teams truly valued or used sprint goals, often ending up with five or six mini-goals per sprint or none at all.
  • Efforts to use more concrete or abstract goals failed to generate engagement.

• Effects:

  • Teams were “floating around”—lacking clarity and focus.
  • They worked more like a Kanban team, reacting to what's available rather than rallying around shared commitments.

• Contextual Issues:

  • Heavy workload, multiple applications to support, and weak PO authority.
  • PO was described as a “proxy” without the power to say no to new requests.

3. Root Causes of Disregarding Sprint Goals

• [07:40] Organizational Setup:
  • PO lacked authority; unable to enforce focus (“proxy PO”).
  • Teams responsible for several products/applications at once.
• Cultural/Team Habits:
  • No meaningful consequences for missing sprint goals.
  • Team members developed their own “personal short-term goals” and acted on individual urgency rather than team priorities.
  • Quote [10:31]:
    "They developed their own personal short term goals that were for them more important than the sprint goal." — Vasco

4. Practices and Patterns

• [11:01] During sprint planning, backlog items were “clustered” but didn’t coalesce into a unified purpose.
  • This “feature factory” mindset led to overstuffed sprints and lack of clear priorities.
• [11:52] When asked to select the most important sprint goal, teams always answered “all of them,” negating prioritization.

5. Consequences of Missing/Optional Sprint Goals

• [12:28] Alf explains that not having a meaningful sprint goal:

  • Erodes team focus.

  • Reduces collaboration, as everyone pursues disparate individual goals.

  • Eliminates the sense of accomplishment (“success after the sprint”).

  • Makes predictability (a key agile value) impossible.

  • Dampens team motivation and shared purpose.

  • Quote [13:14]:
    "You can collaborate better when you have a sprint goal, definitely. And you also have a kind of success after the sprint. So you can say, yes, we made the sprint goal. Another thing is that you become predictable.” — Alf

  • Quote [14:05]:
    "Like being predictable and being able to work together because we share a goal...that's one of the core aspects of Agile in the first place, because we are all working together on the same problem, which makes us all more productive rather than working separately." — Vasco

• [14:33] True collaboration means more than just cooperating on different things; it requires working together towards a single outcome.

  • Quote [14:33]:
    "It changes not the type of work, but how you work together. So that is also the sprint goal...you need to collaborate and not like, not only cooperate so you are working on different things...but you collaborate and work together on a single thing." — Alf

---

Memorable Moments & Quotes

• Adapting to Change in Facilitation:

  • "Go with the flow. I just told the team, okay, I've prepared this one, but I have a feeling it's not currently relevant..." — Alf [03:45]

• On the Absence of a Strong Sprint Goal:

  • "It was kind of like we had maybe three or four or five topics. And then I was asking for the sprint goal...and they said, well, all of them." — Alf [11:52]
  • "Everything was a goal. Right, right. It was kind of like a little feature factory." — Alf [12:15]

• Why It’s Not Healthy to Work Without Sprint Goals:

  • "When you have a sprint goal, you can collaborate much better...and you also have a kind of success after the sprint." — Alf [13:14]
  • “It changes...how you work together. The sprint goal means you need to collaborate, not just cooperate.” — Alf [14:33]

---

Key Takeaways

• Sprint goals are critical for focus, collaboration, predictability, and job satisfaction.
• Teams without a strong PO or discipline around goals risk becoming unfocused “feature factories.”
• Alignment on a single sprint goal is not just about process—it’s a cultural discipline requiring both leadership and team buy-in.
• True agile teams rally around shared objectives, which amplifies teamwork and output quality.

---

Important Segment Timestamps

• [01:42] Books that influenced Alf’s coaching
• [04:58] Story introduction: Teams not valuing sprint goals
• [07:40] Organizational and psychological roots of the problem
• [10:31] Team members’ preference for personal goals over team sprint goals
• [11:52] Evidence of the “feature factory” model
• [12:28] Impact on collaboration, predictability, and team morale
• [14:33] Difference between cooperation and collaboration

---

Episode Tone and Language

The tone remains practical, humble, and reflective throughout—true to Vasco's facilitative approach and Alf’s storytelling. Both encourage open discussion, acknowledging both difficulties and the necessity of stepping into uncertainty as a Scrum Master.

---

This episode offers powerful lessons for agile practitioners and Scrum Masters on the real-world challenges of anchoring teams to clear, meaningful sprint goals—critical for sustainable, effective agility.

Transcript

[A]

Hey there, agile adventurer, just a quick question. What if for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame warfree and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's the Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

[B]

Hello everybody. Welcome to our Team Tuesday where we explore themes and sometimes their lack of understanding of how they can succeed, self imposed difficulties. This week we have with us three explore that and much more, Alf Dobett Baums. Hey Alf, welcome back.

[C]

Hello.

[B]

So let's dive into the team Tuesday. We'll talk about teams in a minute.

[A]

But first share with us.

[B]

Alf, what was the book that most inspired you in your career as a Scrum Master?

[C]

Yes, actually I have two books. I'm sorry for that, but I can't. I really thought about it, but one is from Edgar Schein Humble Consulting. I don't know if you know it. It's very nice. It teaches you. Basically it teaches you that you don't know anything and even if you ask, you still will not fully understand what the other person is in what context it is. But the good thing is that when you ask questions, it might help the other person to get on a different track. Kind of like have an inspiration or get a different idea. And maybe you will change something just by questioning. And the other one is, which I really recommended is don't just do something, just stand there. From Marvin Weisport and yeah, he's really. It really helped me a lot. Just a little story. Just a little story. One day I was, I was going, I prepared a workshop and I was going, I was like, yeah, this is a nice workshop. 1 1/2 hours. And I went into the meeting and within five minutes the whole thing changed. The topic changed, everything changed. And I was like, what? I was screaming in my head, no, my agenda, my workshop. It's Gone. But yeah, basically it wasn't important topic and it was very relevant and urgent for the team. And so I said, okay, let's go with the. Go with the flow. I just told the team, okay, I've prepared this one, but I have a feeling it's not currently relevant and another topic is more relevant. What do you want to do? And they mostly. And they all basically agreed that we would ditch the agenda in the workshop that I made and just go with the discussion. And so I moderated the new discussion and was kind of like, oh, okay, let's see how it goes. But yeah, it was. I think it was very, very important in a very important session. And basically I did that because of that book that I read.

[B]

So this is actually a great story and one that many Scrum masters perhaps are too afraid to do, which is to jump into the unknown, even when the information and the situation are screaming at you like, this is the right time, this is the right space. Open the door. So actually, that's a great reminder. Thank you for sharing that. Now, Alf, let's focus on the teams and how sometimes they become their own worst enemies. So tell us a story of a team. Give us a little bit the context so that, you know, is it a single team, multi team project, small, big project? And walk us then through their behaviors, patterns, or actions that maybe started small but eventually grew in proportion and led the team into a difficult situation.

[C]

Well, it was not so much as a development, but it was kind of like the. They didn't care about sprint goals. About the sprint goal, basically. So they were. And I was like, really pushing. Well, not really pushing for it, but always said, okay, this is important, this is important. It was one team, but within the company, all three teams that I. That I coached, basically. And they all didn't care about sprint goals. It was like, yeah, one team. It had like three sub teams and they were sometimes five or six sprint goals. And it was really difficult because I could not make them to focus on just one goal. It was very hard. I tried a lot. I said, okay, let's go to. Let's do a very concrete sprint goal or maybe do it more abstract. But yeah, they just didn't see the point in it. And they were more of a Kanban team, so to say. So it was hard. Basically what I noticed is that because of the missing sprint goal, they were always kind of like floating around and doing this and doing that and.

[B]

But not focused in the priorities. Or do you mean something else?

[C]

No, not focusing on the priorities and yeah, it was. It was hard. It was also the setup because the team is always set up in a context and they had a lot of stuff coming into them and the PO was. Was not strong enough to say. To say, no, no, let's not do this. At one point I was asking, yes, but is it important that we do it now or do it next week when the next sprint starts? And then someone said, no, yeah, it can wait for one week. And I said, okay, great, then we don't need to change the sprint code. So, yeah, that's basically what I. What I really saw that sprint goal, and I tried everything, but it just didn't work.

[B]

So when you think about that or those teams actually, since there were several. What might be the reasons why teams develop this understanding that sprint goals are maybe optional or perhaps not even important to begin with?

[C]

Well, one thing was the setup. So they had one po, but the PO was not very strong. Usually you say kind of like the proxy po, so he doesn't have the authority to say no, which was one thing. Another thing was that the team had a couple of applications that they are working on at any given time, so to say. So they were also supposed to support the team, the application which is running but is not the main focus on it. And yeah, and sometimes I just said, we don't care if the sprint goal is there because there was usually not a hard word, punishment, so there were no consequences if you missed the sprint goal. So that was also not very. I mean, I was in the rage, always asking, okay, did you reach your sprint goal? And I said, no, yeah, okay, we cannot do anything about it, basically. So

[B]

the weak po, definitely something to look out for because if the PO isn't speaking the language of the sprint goal, then no one else will for sure, because there's always all kinds of things coming in. Then why do you think the teams themselves didn't find the product goal, sorry, the sprint goal, useful or relevant for their own work? Because that could also happen, right? Like the P.O. wouldn't push it, but then the team would say, hey, but we committed to this. We should stick to this. Why were the teams not respecting the sprint goal that they had been, we hope, part of defining in the sprint planning?

[C]

Well, one thing is probably that a thing that they didn't want to change because if they would have respected the sprint goal, then they would have had to say no to some things. They would have excluded some things, and I'm not sure they probably didn't want to do that because then some Stuff would just be laying around basically for one week. So they might have had a, a feeling of urgency, kind of like if, if I just leave it here for one week or how long, however, then it will never get done and I want to get it done. And so.

[B]

So what you're saying is they developed their own personal short term goals that were for them more important than the sprint goal.

[C]

Yeah, yeah. That's a good reframing. Yes, basically. Yeah. Yeah.

[B]

But what you're suggesting also, what you're describing also suggests to me that they didn't really care about the sprint backlog. Right. Because the sprint backlog is usually developed in the sprint planning according to the goal. But if the goal is not that relevant, then the sprint backlog itself is not that relevant because it should lead to the goal. Is that how you see it?

[C]

No, no. I mean, we had sometimes stories in there and we clustered them, so to say, and then put it in the sprint. But they were, then if we had some, one cluster of that, of that stories, they were not enough, basically. So instead of saying, okay, maybe we can do some other things that are maybe relevant during the sprint, they said, okay, let's put three more stories into that.

[B]

So they tried to fill up the sprint with words.

[C]

Yes, a little bit, yes. And so in the end, it was kind of like we had maybe three or four or five topics. And then I was asking for the, for the sprint goal and asking, okay, what you have now? Three or four things, what is the most important thing? And they said, well, all of them. This was.

[B]

Yeah, it's almost like the mixture of the product owner and the team's own behavior led to the fact that they describe themselves or saw themselves as just doing work with no goal in practice. Because everything was the goal.

[C]

Everything was a goal. Right, right. It was kind of like a little feature factory.

[B]

So if you look at this story that you just described in a few words, why do you think it's not healthy for teams to fall into this pattern?

[C]

I think it gives a focus. If you say a sprint goal, then it gives a focus and you can say, okay, we want to achieve this one and not the other one. And you can also collaborate much better if you all work on the same thing, basically. But that also means that you come together more often and really work together. And what else? Your question was, how would it help?

[B]

Why is it a bad idea to not follow the sprint goal and just have many things that are all equally important in your sprint backlog?

[C]

Yes, collaborate. You can collaborate better when you have a sprint goal. When you have a sprint goal, definitely. And you also have a kind of success after the sprint. So you can say, yes, we made the sprint goal. Another thing is that you become predictable. So whenever the team says, yes, this is our sprint goal and we will reach it, and they have reached it already a couple of times, then management can say, okay, they have reached their sprint goal. Whenever they set, they reach it. So they. I expect that they will reach their sprint goal this time also. So. And I think it makes this much more fun to work together on. On a single. On a single focus.

[B]

Yeah, like being predictable and being able to work together because we share a goal. I think those are great advantages. And also one of the core aspects of Agile in the first place, because we are all working together on the same problem, which makes us all more productive rather than working separately on whatever problems we find important at that point in time, which may or may not be complementary to the others that others are working on.

[C]

Right, right. But it changes not the type of work, but how you work together. So that is also the sprint goal. Kind of like when you so that you need to collaborate and not like I just recently read it. Not that you not only cooperate so you are working on different things, but you need to cooperate, but you collaborate and work together on a single thing.

[B]

Absolutely. Well put. Thank you very much for sharing that story with us.

[A]

Alf.

[C]

Yeah, sure.

[A]

Alright, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile business intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile we have so much for you, so check out all the [e-mail] membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community.

[B]

Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.