Four Techniques Most Scrum Teams Get Wrong

The art of sucking with Scrum by messing up with unnecessary add-ons

I’ve lost count of how many times I heard someone saying, “Scrum doesn’t work!” I‘ve said that several times, myself. Many professionals I know think Scrum failed them. The promise of doing double the work in half the time never happened. Teams want freedom and get trapped in vicious circles. Let me ask you a simple question:

Is Scrum that bad, or are we bad at playing this game?

Years ago, I perceived Scrum as a set of roles, events, and artifacts. Nothing more, nothing less. I had intense attention to one question, “How do we get things done faster?” No surprise, then, that all of my energy would go to that question. I found answers to my questions with techniques to increase predictability and output. And I thought they were part of Scrum or mandatory. Well, I got it all wrong.

Unfortunately, I still notice teams falling into the same confusion I’ve fallen into. Scrum is a process framework, and it’s incomplete by design. You can play the game differently, and you’re free to decide what you add to it or not. You don’t have to do something because almost everyone else is doing it.

I hope you can help teams avoid the traps I’m about to describe. Let me share what I learned from typical techniques misused with Agile and Scrum, leading to a watered-down Scrum version.

#1. User Story : The Official Backlog Item Format

Though some talk about Scrum methodology, it is an Agile framework, which means traditional requirements are a misfit. That’s why User Stories became the official way of representing Product Backlog items. Well, not so fast. 

Scrum has no official way to represent Product Backlog items.

Most Scrum teams indeed opt for User Stories, but that doesn’t mean Scrum forces you to use them. Don’t take my word for it have a look at the Scrum Guide; you won’t find a single mention of User Stories there.

You may think User Stories are a way of representing requirements. I’d say you’re right, but User Stories go beyond that. When used correctly, they should foster collaboration and help teams build a shared understanding of problems before considering solutions. This is what teams get wrong.

There are three parts that define User Stories: card, conversation, and confirmation. Someone writes a problem from a user perspective, then the team has a conversation around it and writes down how they confirm the problem is solved, also known as acceptance criteria. The steps have to happen in this sequence to reach User Story’s purpose. Note the emphasis on understanding the problem over solving it.

Teams mistakenly write a User Story with highly defined acceptance criteria upfront. As a result, they talk about solutions, implementation details, and estimation while ignoring the problem. This will get them closer to a feature factory team and farther from a solid Scrum team.

#2. Story Points: The Ultimate Estimation Format

How do Scrum teams estimate? I believe Story Points come to your mind. Most Scrum teams opt for Story Points to estimate their Product Backlog Items. Some teams even believe this comes from Scrum, and you’ve got no other choice.

To put it shortly: You’re free to choose whatever you want. Scrum doesn’t limit you. On the contrary, Scrum doesn’t even use the word estimate in the Scrum Guide. The only recommendation you will find is to size your Product Backlog items. You can do that however you want.

Am I against Story Points? No. So what am I talking about here? I’m encouraging you to encounter a technique that helps your team in your scenario to create value sooner. You don’t need to take Story Points as the sacred unchallenged estimation technique.

Scrum doesn’t limit teams. Teams limit themselves.

#3. Velocity: Speed, Speed, Speed

A Scrum team gets better Sprint after Sprint. I heard this statement for the first time in 2012 from a Scrum Trainer. He meant that the more people work together, the stronger collaboration gets, making it simpler to create valuable results. Yet, what I understood was, “Scrum teams can increase their velocity Sprint after Sprint.” 

I used to give too much attention to the team’s velocity. This was the most important agile metric to me. I thought the more output we created, the more successful we were. 

I remember one time when stakeholders cheered us up as we moved from 20 Story Points per Sprint to 72. More than 300% output increase in six months; we thought we should all celebrate. Curiously, it turned out that none of our outcome metrics changed. Our revenue remained the same, and customer satisfaction didn’t go up, which confused us. We didn’t get it. For us, it made no sense. We were shipping features at the speed of light. How could that be?

Velocity cannot guarantee valuable outcomes. Don’t fall into this trap.

Once again, I got velocity wrong. Worse than that, I blamed Scrum without understanding that velocity isn’t part of the Scrum Guide.

Scrum teams should focus on creating value at a stable pace. Sprint after Sprint, they create value, users benefit from it, and business grows. Frequency is more important than velocity. It’s not about speed; it’s about value.

#4. Burndown:  Micromanaging the Team

Take a minute and reflect on what the following image tells you.

The above burndown chart shows me that in a weekly Sprint, the team seemed “fine” until day three and got stuck and worried about their velocity on day five. Probably the Scrum Master challenged developers, and developers disliked that. Yet, in the end, everything was delivered. 

You may think some interventions during the Sprint are necessary to ensure meeting the commitment. I’d challenge that. Developers are self-managing and shouldn’t need anyone to micromanage them. Also, the Scrum team commits to reaching the Sprint Goal by the end of the Sprint, which means they have the whole Sprint to make that happen.

A burndown obsession wears developers down and sets an output direction. I thought burndown was a great tool to help me see when the team was trapped and how we could adapt. As a result, our attention went straight to output and velocity while ignoring goals. 

I no longer use Sprint Burndowns and don’t even care how the team is performing during the Sprint. I care about reaching the Sprint Goal by the end of the Sprint and encourage the team to use the Sprint the best way they can to figure out how to reach the goal.

Although you will find burndowns as standard in tools like Jira, don’t mistake them for mandatory in Scrum. Burndowns are not part of Scrum, and you are not forced to use them. Yet, if you decide to use them, try applying them in a way that unstuck your team. It can be helpful to understand what holds the team back from progressing. 

A good usage of burndown creates valuable conversation, while a bad one feels like micromanagement.

Final Thoughts

None of the techniques above are mandatory with Scrum, yet they are commonly used and misused by many teams. I misused all of them for a long time, and my key learning is the following: 

Step back from your daily doing and reflect on how your current techniques help you achieve your goals. 

When I reflected on it, I came to the following:

• User Stories were misused and often confused the team instead of helping us. We changed our focus from writing to collaborating. Sometimes we used User Stories, sometimes Job Stories, but we always focused on the problem we wanted to solve.
• Story Points became mechanical in terms of estimates. We stopped caring too much about estimates, and we shifted our attention to gaining perspectives and learning what we knew and what we didn’t.
• Velocity used to be my key metric and the most inadequate one. I assumed impact and became proud of increasing velocity. We ditched this technique and consequently maximized our outcome.
• Burndown set our minds in delivery mode, pressured us for output, and ignored learning during the Sprint. We ditched it, and my teams never called me a micromanager anymore.

Don’t do something just because everyone else is doing it. Do what makes sense in your scenario.