Skip to main content

Scrum as a Catalyst for Product Evolution

May 19, 2025
Scrum as a Catalyst for Product Evolution

Moving Beyond Delivery to Innovation and Learning

By Dr. Charles Suscheck

You can get more out of Scrum.
 

Over the years, I’ve noticed a common pattern: many teams follow Scrum by the book, yet the products they deliver lack innovation. Scrum is often seen as a way to push out more work, faster, and on a predictable cadence—and it can do that. But if we only focus on delivery, we miss the larger opportunity to inspect and adapt based on customer feedback.

A typical workflow goes like this: the team reaches the end of a Sprint, releases a product increment to customers, and then moves on to the next set of Product Backlog Items (PBIs) during Sprint Planning. That’s fine, but it may be using Scrum as a product delivery mechanism, not a product evolution mechanism.

 

Four Strategies to Infuse Innovation into Scrum

 

If you want to create more innovative, customer-centered products, here are four strategies that can help:

1. Treat Each Release as an Experiment

Every product increment you release is based on an assumption about what value the it will deliver. But it’s an assumption that you won’t really know until customers interact with it.


So instead of viewing the release as the end of the cycle, treat it as the beginning of a learning loop—an experiment to test the value you believe you’ve delivered.

Make it a habit to explicitly gather feedback—perhaps not just right away, but over time—and use what you learn to refine the Product Backlog. This feedback-driven approach is what transforms delivery into evolution.

2. Release Based on Value, Not Necessarily Sprints

Scrum encourages releasing frequently, but that doesn’t mean it’s only at the end of a Sprint. Sometimes the best moment to release is mid-Sprint, or even after several Sprints.

 

The key is to focus on accumulated value and release when there’s enough value for your customer, not necessarily based on a schedule or Sprint boundaries. Decoupling release decisions from Sprint boundaries lets you deliver value sooner and gather feedback more quickly.

Your product will be more flexible, and your customers will get more timely enhancements.

3. Embrace Strategic Procrastination

It might sound counterintuitive, but detailing out PBIs early can slow you down.  It can lead to rework. Locking in details too soon often leads to rework once customer feedback shifts your direction.


Instead, leave some space—intentionally. I call this strategic procrastination: holding off on details until closer to when work begins, when you have more information. Less detail early on means more flexibility.

Of course, it’s a balance—some detail supports shared understanding—but leaning toward “just-in-time” refinement can make your product more responsive and resilient.

4. Refine Frequently, and with Small Efforts

If you really want to embrace strategic procrastination, you should refine your Product Backlog items several times (4 or more time) before they are considered for Sprint Planning.  Each time you refine, keep it brief. You don’t need to go deep on any one PBI if you know you’ll revisit it in a couple of weeks.  

This approach helps to sidestep prematurely detailing out a PBI and then reworking it.  It also helps to keep enough detail in the Product Backlog to plan where the product should go. 

Like the other strategies, it’s a trade-off between details and flexibility.  The right balance comes from continuous inspection and adaptation, especially during retrospectives.

Conclusion

Scrum isn’t just a process for shipping features - it’s a framework for learning, adapting, and discovering what truly matters to your users. When teams embrace uncertainty, collaborate closely, and deliver in small, meaningful increments, Scrum becomes more than a delivery mechanism—it becomes an engine for innovation.


What did you think about this post?