Scrum Teams Should Not Deliver Features Every Sprint

Whenever you observe one of the following situations, consider it a warning sign blaring in your face:

• Stakeholders expect Scrum teams to deliver features every single Sprint
• Everything is good when velocity is increasing; the moment it decreases, you are in trouble
• Handing over activities is the status quo. Somebody outside the team defines what to do and hands over a predefined solution to teams
• Product Owners must sign off on tasks done by developers
• Software engineers are expected to code and are measured by the output they create
• Bug-free is the ultimate definition of quality, even though some bugs may never occur and cause no hassle for real end-users
• Following the process is more important than figuring out alternatives for creating value faster

Do these ring a bell? For me, they trigger a fire alarm. I’m sensitive to it because I’ve been in all of these situations before, and it sucks to fall into these pitfalls.

Let me walk you through common misperceptions and offer some alternatives to escape them. I hope that I can generate insights that help you whenever you find yourself in such a scenario.

Scrum Isn’t a Delivery Framework

I’m a calm person, and only a few things can derail me. One of them is diminishing Scrum teams to delivery teams. That’s a massive misconception of Scrum, and it will set the team in a pointless direction.

Many companies perceive Scrum teams as responsible for the execution, and they have no say in the direction. They expect Scrum teams to ensure features are delivered on time and as specified. That isn’t Scrum at all—that’s waterfall, or Waterscrumfall. 

To understand Scrum better, let’s take a quick look at the Scrum Guide:

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1- A Product Owner orders the work for a complex problem into a Product Backlog

2- The Scrum Team turns a selection of the work into an Increment of value during a Sprint

3- The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint

4- Repeat

I think the biggest misconception comes from this sentence: “The Scrum Team turns a selection of the work into an Increment of value during a Sprint.” People may interpret that to mean all Sprints result in features. But wait a moment—does that mean features guarantee value? 

No feature will guarantee value without end-users benefiting from it.

The Sprint should be used to create value. Self-managing teams should organize themselves to uncover what yields value and what doesn’t.

When teams get too busy with the implementation, they miss the mark. The goal is not to create more output, but to generate more outcomes.

Scrum Can Be a Bad Choice

People often approach me to learn how to do Scrum better. I try to understand what they need and give them some tips. Common questions I get are:

• How could we improve our performance?
• How could we be more efficient?
• What are the tricks to increase velocity?
• How could we be more predictable?
• How could we reduce our risks?

Such questions disturb me. They don’t represent a value-driven mindset but a fixed one. When I’m asked these questions, I realize the company might be using Scrum without knowing why they are using it in the first place. 

Whenever someone asks me how to do Scrum better, my first question is, “Why do you do Scrum?” The answer is often surprising, and I quickly realize Scrum was a bad choice for them.

Don’t do Scrum when your goal is to solely:

• Increase output
• Increase predictability
• Improve performance

You will be disappointed and make people frustrated with Scrum.

“What you’re really seeing is Agile for delivery, but the rest of the organization and context is anything but Agile.” - Marty Cagan

Beyond Features

It might take companies a while to understand, but eventually, management realizes that a prescriptive roadmap doesn’t go beyond pleasing internal stakeholders. They notice that more features doesn’t mean more value, and something is wrong with how they work.

When companies get interested in a life beyond features, they will evolve their mindset and start thinking about creating value over developing features. That’s the moment Scrum can shine.

Scrum has better chances of yielding valuable results when:

• Top management is frustrated with the current results
• Executives are ready to empower teams to pursue goals over meeting deadlines
• Innovation becomes more important than avoiding failure
• Exploring opportunities is better seen than mitigating risks

With such motivation, Scrum teams will have the required support and room to do what’s needed to create value. 

Doing Scrum goes beyond developing features. It’s about being comfortable with the uncomfortable and being adventurous enough to uncover the unknown. Solid Scrum teams take responsibility from end to end and focus on doing whatever it takes to create value for end users and businesses.

“The objectives do not need to cover every little thing the team does, but they should cover what the team needs to accomplish.” - Marty Cagan

Despite the possibilities that Scrum brings, I must warn you: there’s no shortcut for agility. The journey will be challenging; you will hit a wall, fall, get mad and frustrated—but you’ve got to stand up and keep moving forward. You will continuously face resistance; some stakeholders will push for features, predictability, and deadlines. You cannot avoid that, but with support from leadership, you can help them understand how to work with Scrum.

Final Thoughts

The Scrum Guide insists there’s an increment at the end of every single Sprint and that should be your goal. But you shouldn’t limit the word “increment” to features. Here are some examples of potential increments:

• Validate or falsify a set of critical assumptions of your business model
• Uncover real end-users’ jobs and pains
• Collect evidence that justify investing energy into an initiative

The main point is that Scrum teams must be cross-functional and accountable for results. They work as a self-managing team, eager to solve end-user problems.

Real Scrum teams start with the end in mind and work backward to create value. They may not know the path, but they are ready to embrace the unknown and navigate uncharted waters.

Waterscrumfall teams don’t have any goal to achieve beyond matching precise requirements defined by someone outside the team. They are afraid or unempowered to go through unknown paths.

Your goal should be to become a real Scrum team, but the truth is that not all organizations are ready for that. Don’t let that stop you! Don’t be powerless, and do your best to influence the leadership to understand the importance of empowerment and going beyond features.