I have been working in Scrum teams for quite some time now, and I am a big fan of the method. One thing I always wondered about however is why product owners seem to change their minds so often after a sprint delivery.

The last few months I got the chance to experience Scrum from the product owner’s side and it really confirmed the value of the method to me and also taught me a valuable lesson…

From November to February, I acted as the product owner of an Android game, developed for us by a group of valiant students from the HAN University of Applied Sciences. Using the Scrum method means going through several cycles of planning sessions, followed by two weeks of waiting for the sprint to be completed and culminating in delivery of the product. In each planning session, I got to explain exactly what I wanted and after each and every one I really thought both sides knew exactly what it is I wanted.

But each delivery of the product gave me a product that differed slightly from expectations.

And the weird thing is, when I went back to the notes from the planning session, it always appeared as though the product was actually conform to what I had specified. This made me realize that it’s not so much that product owners change their minds, it’s that however detailed the specifications are and however certain you are that both sides understand each other, there will always be variations between what a product owner expects and what is delivered to him…

In my opinion, this is because specifications will always be interpreted to some degree. And they will be interpreted differently by different people, who have different technical backgrounds or habits and who have different views on aesthetics, usability and other such things.

So how did I handle this? Well… some things weren’t very important so I just let them go, but others were important and I wanted them altered. But because this was a Scrum project, the team delivered the desired changes within the next two week sprint.

And I suppose this is one of the very big reason to love Scrum. Indeed, in a traditional Waterfall project, I would have experienced the same issues, but would have had no opportunity to rectify them along the way. So the end product could only be far removed from my expectations since all those variations in interpretation would have accumulated for the whole duration of the build…

This is why we use Scrum and embrace change!