This article was tough to write, not because I don’t have enough mistakes to share, but because there are so many! Mistakes are where we learn, and that’s exactly what I’ve done. I hope sharing mine will help you avoid making the same ones.
1. Sharing Velocity Outside the Team
I once shared velocity with senior executives. I made sure to add all the caveats. “You can’t compare one team’s velocity to another,” I said. “It’s just a tool for planning.” I gave them value metrics too, so they had the full picture.
Why did I do it?
I thought I was being transparent.
Here’s why it was a mistake.
They didn’t hear the caveats. They just saw that Team A’s velocity was higher than Team B’s, and it triggered their command-and-control instincts. Even though they saw the team with the lower velocity was delivering great outcomes, they felt the need to push for more.
Here’s what happened.
The team changed their point system to thousands because, honestly, velocity is just a number. One team’s 5-point story is another team’s 8-point story. It’s subjective, and it’s only useful for the team’s own planning. (If you’re tired of velocity, check out Flow metrics!)
What to do instead.
Share metrics that actually matter—like customer outcomes. Focus on progress towards the Product Goal, not meaningless numbers.
2. Letting the Definition of Done Include Customer Approval
This one still stings. I was working on a big Agile transformation with a major customer. We wanted to get their buy-in, so we added “customer approval” to our Definition of Done.
Why did I do it?
I wanted to be transparent and keep the customer happy.
Here’s why it was a mistake.
Our Definition of Done became a moving target. What should have been a clear, achievable goal was now based on someone else’s opinion, which changed frequently.
Here’s what happened.
Our Sprint Reviews turned into approval meetings. Instead of reviewing completed work, we spent the time convincing the customer that what we had done was good enough. It delayed feedback, slowed down decision-making, and frustrated the team. The customer also used the Sprint Review as a way to increase the scope of individual Product Backlog items and bypass the Product Owner's authority.
What to do instead.
Keep the Definition of Done in the team’s control. It should be a checklist that the team can own and accomplish by the end of the Sprint. Customer feedback is important, but it belongs in the Sprint Review—not as a gate in your Definition of Done.
3. Letting the Daily Scrum Go Too Long
This one’s a bit embarrassing. I let the Daily Scrum drag on for an hour. Every. Single. Day. In my defense, it was my first time as a Scrum Master, and I hadn’t been trained yet. (Take Applying Professional Scrum course first, trust me!)
Why did I do it?
I thought I was helping collaboration by giving everyone time to talk.
Here’s why it was a mistake.
Nobody wants to sit through an hour-long meeting every day. In retrospect, it seems obvious.
Here’s what happened.
A few of the Developers kindly pulled me aside and told me the Daily Scrum should only be 15 minutes. I didn’t listen—I thought I was protecting “valuable” discussion time. Within a Sprint, someone else volunteered to take over the Scrum Master role, and before I knew it, I was off the team.
What to do instead.
Keep the Daily Scrum short—15 minutes or less. It’s a quick sync to help the team align and adjust their plan for the day. If problems come up, discuss them outside the Daily Scrum. This keeps the meeting focused and lets people get back to work.
4. Misunderstanding the Purpose of the Scrum Master
I started submitting any security requests or change control paperwork for the Scrum Team.
Why did I do it?
I thought I was being helpful and taking administrative work off their plates.
Here’s why it was a mistake.
Taking on the administrative burden of the team kept me from doing what I was supposed to be doing, which was helping the team become more self-organizing.
Here’s what happened.
Taking on the administrative burden of the team kept me from doing what I was supposed to be doing, which was helping the team become more self-organizing. Not only that, but pretty soon, I became a bottleneck. The Developers eventually came to me and asked if they could submit their own security requests because I was slowing them down.
What to do instead.
Trust the team to handle tasks like ticket submission. The Scrum Master’s role is to remove impediments, not become one.
5. Skipping the Sprint Review
We skipped the Sprint Review because we weren’t going to release to production yet. We figured, “Why waste everyone’s time?” Big mistake.
Why did I do it?
I thought the Sprint Review wasn’t necessary if there wasn’t a release in the immediate future.
Here’s why it was a mistake.
We missed out on talking to the business about what mattered most. Instead of adjusting based on feedback, we tried to deliver everything at once. We ended up going way over budget.
Here’s what happened.
By the time we did deliver, we realized we had worked on things the business didn’t care about. We could have caught that much earlier if we hadn’t skipped the Sprint Reviews.
What to do instead.
Never skip the Sprint Review. Even if there’s no release, use it to check in with stakeholders and course-correct if needed. It’s about getting feedback early and often.
Conclusion
We all make mistakes, and that’s okay. The important thing is to learn from them. I’ve learned that transparency is key, but only when it’s meaningful. Metrics should focus on value, not vanity. Meetings should be short and to the point. Trust your team—they’ll surprise you. And remember, Scrum is about delivering value, not just staying busy. Keep that in mind, and you’ll avoid these - and other - mistakes!
Interested in networking with and learning from your peers? Join us at Scrum Day Madison on Wednesday, October 23. Last chance to get tickets!