If I asked you, “Will the new mobile app features be ready for the trade fair in March?”, what would you say?
In many organizations I help, the answer is a hesitant “We hope so.” When I dig deeper into their data, I find that their teams meet their Sprint Goals about 50% of the time.
They are operating on a coin-flip. And to be honest, I have been there as well with my own organization at Webfleet – it is an easy trap to fall into.
Scrum talks a lot about “Psychological Safety” and this is a good thing. But somewhere along the way, “Safe Space” got confused with “Comfort Zone” for a lot of organizations. The rituals of Scrum became social gatherings rather than business tools.
If you want predictability, you need to stop treating these meetings as safe spaces for status updates, and start treating them as steering committees for delivery.
The High Cost of Ignoring Velocity
Let’s be clear: Scrum is NOT a low-overhead development model.
It requires a Scrum Master, Product Owner, planning sessions, dailies, reviews, and retrospectives. That is a significant investment of time and salary. You pay this “tax” to buy one thing: Predictability. Or actually two, if you add transparency to the mix as I have explained in a previous article.
Yet, I am constantly amazed by how many teams don’t track their velocity or, worse, don’t use it to plan ahead.
If you are paying the high overhead of Scrum but not using the data it generates to forecast deliverables, you are burning money. You have all the bureaucracy of Scrum with none of the strategic clarity.
The Daily Scrum: Social Club or Steering Meeting?
Walk into your team’s Daily Scrum tomorrow morning and listen for one specific phrase: “Sprint Goal.”
If you don’t hear it, you have a problem.
Far too many teams use the Daily as a morning coffee chat: “Yesterday I fixed a bug, today I am working on the API.” Honestly? Your developers don’t need a meeting to know that. And neither do you.
The Daily is not a status report; it is a steering meeting. The only questions that matter are:
- Are we on track to reach the Sprint Goal?
- Is there a bottleneck blocking the path to the Goal?
- Do we need to swarm (work together) on a specific task to save the Goal?
If the team is just sharing an activity log, they are wasting 15 minutes every day.
The 80% Rule: Managing Ambition
So, how often should a team hit that Sprint Goal?
- 100% Success Rate: If your team hits the goal every single time, they are sandbagging. They are committing to “safe” goals they know they can hit with their eyes closed. You want a team to say from time to time, “This is a tough nut to crack, but we’re going for it because it is important for the business.” That is how teams grow.
- 50% Success Rate: This is the danger zone. If hitting the goal is a coin-flip, you have zero predictability. You cannot plan marketing launches or client migrations. Note: If you are at 50%, refer back to my previous article about Scrum Masters and their role. A Leader (not a Team Assistant) would not allow this pattern to persist.
The Target: According to my experience over the years as CTO, you want to be around 80%. This shows the team is stretching themselves, but retains enough control to be reliable.
The Retrospective: No More Excuses
According to the Scrum Guide, the purpose of the Retrospective is “to plan ways to increase quality and effectiveness.”
It is simple logic: If you missed your Sprint Goal, that is the topic of the Retrospective.
- What happened?
- How did we miss the warning signs?
- How do we steer differently next time?
Way too often, I see teams NOT achieving their goals – and then spending their time in retrospectives discussing something completely different. Or you could say: irrelevant. A good Scrum Master will not let this happen, of course, and I hope you have those in your teams.
Another major red flag that your Retrospectives are a waste of money? External Blame. If the conclusion is always “It’s management’s fault,” “the requirements changed,” or “this or that other team did not provide us what we needed”, and no internal action is taken, you are not learning. You are just venting. I suggest to not pay people to do that.
The Review: The Sound of Scrum Theater
Finally, look at your Sprint Review. The team presents the work of the last sprint.
Is there silence?
If stakeholders sit there, nod politely, ask no questions, and offer no critique (“Where is the filter function? I need that!”), you are witnessing Scrum Theater.
Silence means one of two things:
- You have the wrong stakeholders in the room.
- The team is building things nobody cares about.
The Review is not a “Show and Tell.” It is a strategic pivot point. If there is no friction, no feedback, and no debate, you aren’t validating value. You are just watching an expensive theater performance. Which, once again, you are paying people to perform.
The C-Level Takeaway
Scrum is a powerful framework, but only if you respect the Business side of it as much as the Technical side.
- Use Velocity: You paid for the data; use it to plan.
- Focus the Daily and the Retro: It’s about the Goal, not the tasks.
- Demand Predictability: Aim for 80% reliability, not 50%.
- Provoke Reaction: If your Reviews are silent, wake up your stakeholders.
The organizations I work with that embrace this shift move from ‘hoping’ they’ll hit deadlines to ‘knowing’ they will. That’s the difference between Scrum as theater and Scrum as a competitive advantage.
