Bad Scrum Teams Are Proud of What They Create

After 99 Sprints together, team Jorvik felt they nailed Scrum. They’ve never been so fast and in perfect sync with each other. Ivar, the Product Owner, wanted to celebrate their accomplishments. Therefore, he prepared a list of achievements to present to the team before the end of the 100th Sprint. He felt that would inspire the team.

At the beginning of the Sprint Retrospective, Ivar started saying how proud he was to be part of team Jorvik. Then, he said he had something special to share with the team, and brought up the following list of achievements:

• 453% performance increase: 17 story points delivered in the first Sprint compared to 77 this Sprint.
• 693 features created: Our average is 7 features per Sprint.
• 351 bugs fixed: We fix 3.5 bugs per Sprint, on average.
• 222 technical improvements: Every Sprint, we make at least two essential system enhancements.

Harold and Ragnar seemed proud of the numbers. Their faces couldn’t hide their excitement. But Björn seemed uncomfortable. He didn’t say a word until Floki noticed that and asked him, “Björn. How proud are you of our achievements?” Reluctant to respond, Björn started:

Björn: “Guys. I don’t want to be the party pooper, but I see no other way. These numbers are meaningless. How can I be proud of something when I have no idea of its result?”

Ivar: “Björn, come on. Give yourself a chance to celebrate. Be proud of yourself and our achievements as a team. We did a massive amount of things our stakeholders are happy with.”

Björn: “Things? Ivar, sorry. I simply don’t understand what the result of my work was. I don’t come to work to please stakeholders. We delivered thousands of story points, and then what? For a hundred Sprints, we created features, fixed bugs, and improved our infrastructure. But how did that make the world better?”

At this moment, the excitement from Harold and Ragnar was gone, and Ivar looked puzzled and didn’t know how to react. He remained silent, and Floki, the Scrum Master, decided to intervene.

Floki: “It seems like you cannot relate the output generated to the outcome created, Björn. Is that right?”

Björn: “That’s right. In this team, we only talk about tasks. I feel mistrusted. Nobody tells me which problem we are supposed to solve or what our features are supposed to create. Our  work is similar to an assembly line, but we create a different feature instead of creating the same component every time. I feel like part of our work is missing.”

Floki: “Thanks for sharing it, Björn. I think we have a lesson to learn here. Our features are a means to an end, and if we don’t know the end, we are trapped. Ivar, how do you see it?”

Ivar: “Well, I don’t even know what to say. I came here to celebrate our achievements, and now I don’t even know what we achieved. I think I missed the mark. It’s time for me to ensure before starting any feature, we know what the outcome of it should be.”

Does this scenario ring a bell to you?

Many teams are trapped on a feature factory anti-pattern. Sprint after Sprint, all they do is to create more and more output. Nobody talks about the outcome; even worse, nobody even knows the expected outcome.

Let me share some of the common pitfalls Scrum teams constantly experience. By the end of this piece, you should know how to avoid them and create value beyond delivering features.

Backlog Refinement

As often as needed, the Scrum team refines the Product Backlog, and the goal is to gain clarity into how to solve problems and create value – yet only a few Scrum Teams stick with this goal. Let me ask you some questions regarding your refinement sessions:

• Do you bring detailed requirements or broken stories?
• Do you evaluate how to implement solutions or how to solve problems?
• What’s more important to you, getting precise estimates or building a shared understanding?
• Do you talk more about meeting deadlines or creating value?

If your answers relate more to the left column, you have an output-focused refinement, while the right column means that you focus on the outcome.

An excellent backlog refinement will have the following characteristics:

• The Product Owner ensures the Scrum team has clarity on the expected outcome behind each backlog item.
• The Scrum team doesn’t discuss solutions before clearly understanding the problem they are supposed to solve.
• Estimates are a tool to ensure understanding instead of planning capacity.

Sprint Planning

From my experience, excellent Sprint Planning is often one of the main differences between good and bad Scrum teams. When teams are trapped in the feature factory anti-pattern. Sprints descend into shorter waterfall cycles, and team members are pressured to maximize their ability to create output. Again, let me ask you some questions regarding your Sprint Planning:

• Do you craft your Sprint Goal during the end or beginning of Sprint Planning?
• Do you plan the Sprint Backlog based on the Story Points or strive for a team committed to the Sprint Goal?
• Do you make agreements on what to deliver or what to achieve?

Like the previous session, if your answers relate to the left, it means output orientation, while the right side means outcome. Most teams I know misuse Sprint Planning; it ends with a boring list of features to deliver instead of an inspiring Sprint Goal and an engaged team.

Although Scrum Teams may feel powerless to defeat the anti-patterns they face, they can change things for the better. It’s always a choice between bowing to the status quo or challenging it.

Great Scrum teams would never let anti-patterns drive their actions.

Measuring the Outcome

Defining the expected outcome is only the first step. Changing how you refine your backlog and plan your Sprint isn’t enough to create value. You need to find ways of measuring the result of the output the team develops. If you don’t do that, you will be frustrated like Björn from team Jorvik.

Scrum is about transparency, inspection, and adaptation. Measuring the results is connected to “inspection,” that’s why you need to figure out how to evaluate the impact of your work.

For example, suppose you have an investment app, and you have to increase or sign-up rate. Then you talk to your team and start a new Sprint with the goal, “Potential users are motivated to sign-up to our investment app.”

During the Sprint, the team noticed a massive drop after users opened the sign-up page: 50% of them bounced. A developer had an idea of asking abandoning users, “Sorry to see you go. Could you share what we could do differently to gain your trust? Please.” After two days, there were 73 answers, and a pattern stood out: users didn’t want to sign up. They longed for a Google or Apple login. The team decided to implement that.

As the Sprint ended, the team adapted the login interface and wanted to run A/B testing to gain confidence. They decided to put it live for 20% of their audience and learn from real users. Every day, the team would look at the numbers. The drop rate went down to 43%, but it was still not satisfactory. The team sat down to understand in-depth the impact of their changes, and two things stood out:

• Desktop users’ bounce rate decreased from 50% to 25%
• Mobile users’ bounce rate increased from 55% to 60%

The team was surprised by the changes, but also curious. They realized that the new page was  poorly designed for mobile users; Google and Apple logins weren’t visible on the first screen, and users didn’t have anything to hint that they should scroll down. The team made some changes and ran a second experimentation. This time, the results were more promising – the overall bounce rate decreased from 43% to 28%. The team knew the impact of their work.

Inspecting and adapting means looking at what is not working and trying something different. Although that seems obvious, many Scrum teams are fooled by plans and forget about their essence.

Final Words

If you asked me about my major learning over the last decade, I would tell you that simplicity is the best weapon against complexity. There’s not only a single way of doing Scrum. However, you will stumble upon several ways of diminishing your chance of success.

The best way of doing Scrum is not by making it more rigid but by making it looser. Delivering features may be nice initially but frustrating in the long run once you realize it didn’t create the value you expected.

You don’t need a lot of knowledge to succeed with Scrum. But you do need a lot of courage to remain simple while everyone around you tries to make everything more complex than needed.