I decided to refresh my knowledge on product management in Scrum recently, so I reached out to “The Professional Product Owner” by Don McGreal and Ralph Jocham. I did not expect any surprises from such a canonical book, but early in my reading, I was suddenly struck by the compelling message: Scrum is science-backed. Like, actual scientific method science.
Here’s what hit me: Scrum isn’t valuable because of the fancy rituals or the specific cadence. It’s beneficial because it’s built on the scientific method. You make a hypothesis, and then you verify it through an experiment. In Scrum terms, you decide what might create value, and then you test it in a sprint.That’s it. Science is the core of SCRUM.
Every sprint is asking: “We believe this will work. Let’s find out.” Every sprint review examines the results. Every retrospective is refining your experimental approach. The whole framework is designed to help you learn through structured experimentation, not to follow a prescribed set of meetings.
I realised I’d been treating Scrum like a recipe to follow rather than a scientific approach to discover what works. The difference matters more than you might think.
When you see Scrum as science, everything shifts. A “failed” sprint isn’t actually a failure – it’s data. A pivot isn’t admitting defeat – it’s responding to what you learned. The pressure to “do Scrum right” eases up because you remember you’re not there to perform rituals perfectly. You’re there to understand what creates value, as quickly and systematically as possible.
This realisation reminded me why going back to basics is so powerful. We get sophisticated. We optimise our processes. We layer on tools and techniques. And sometimes in all that sophistication, we forget what we’re actually trying to do.
In my career, I’ve seen teams obsess over whether their standups should be 12 or 15 minutes, whether they should use Fibonacci numbers for estimation, and whether their sprint length should be two weeks or three. These discussions can go on forever because they miss the point entirely.The point is: form hypotheses about value, test them quickly, learn from the results, and repeat. If your Scrum rituals help you do that, great, keep them. Suppose they don’t, change them. The framework isn’t sacred. The scientific approach is.
So when you do your next sprint planning, ask yourself different questions. Not “What should we commit to?” but “What do we want to learn?” Not “Can we finish this?” but “What’s our hypothesis about value here?”It’s a slight shift in framing, but it changes everything.
Sometimes the most valuable insights aren’t the advanced techniques or the clever hacks. Sometimes they’re the fundamental principles you once knew but somehow forgot while you were busy being busy. The lesson from this aha moment for me is that you should purposely return to the fundamentals of what you are doing to ensure you understand the “why”.
What fundamental principle of your own work have you forgotten while focusing on the fancy stuff recently?