Four Techniques Most Scrum Teams Get Wrong
The art of sucking with Scrum by messing up with unnecessary add-ons
The art of sucking with Scrum by messing up with unnecessary add-ons
I lost count of how often I heard someone saying, “Scrum doesn’t work!” I‘ve said that several times too. Many professionals I know think Scrum failed them. The promise of doing double the work in half the time never happened. Teams wanted freedom and got 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, 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 Scrum, leading to a watered-down Scrum version.
#1 — User Story — The Official Backlog Item Format
Scrum 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 that 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 that, have a look at the Scrum Guide. You won’t find a single mention of User Stories there.
You may think User Story is 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.
Three parts 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 Stories’ purpose. Note the emphasis on problem understanding over solution.
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 to a solid Scrum team.
#2 — Story Points — The Ultimate Estimation Format
How do Scrum teams estimate? I’d 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 short: 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.
You may opt for whatever technique you find fit. I’ve written a summary that can help you decide.
Agile Estimations in a Nutshell
Originally published in GoRetrodavidavpereira.medium.com
#3 — Velocity — Speed Speed Speed
A Scrum team gets better Sprint after Sprint. I heard this statement 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, I understood, “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 metric to me. I thought the more output we created, the more successful we were.
I remember a case 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 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 confuse that as part of Scrum. Burndowns are not part of Scrum, and you are not forced to use them.
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.
Did you like this post? What about becoming a Medium member to benefit from unlimited reading? By doing that, you also support writers like me and thousands of others 😊
Originally published in GoRetro