On monday and tuesday i attended the Professional Scrum Product Owner training by Ken Schwaber. He has rewritten the training to be more focussed on the role, goals and needs of product owners and product managers, and less on supporting the Scrum team. The previous training was more focussed on what a product owner should do to make a scrum team succesful, but it should be the other way around. The scrum team is there to help the product owner achieve his goals.
I think it was a good decision to change the focus of the training. The training itself does a good job of explaining what a product owner should do, and how he can achieve his goals. Ken discussed things like agility and empiricism, value, prioritizing requirments, release planning, scrum.
Having used Scrum for the last 4 years, there weren’t any big surprises in the training, but that’s maybe also because Scrum itself isn’t difficult to understand. Applying it in a succesful way is a lot harder.
The biggest eye opener for me was the fact that the product owner’s main task is creating and communicating a vision for the product. This can be done on a very high level. A product owner doesn’t have to write the user stories himself, nor does he have to have a ‘Business team’ to assist him in writing the user stories. If more detailed requirements are needed than what the product owner provides, you can add people to the Scrum team that can research and communicate the requirements. The team can write their own user stories. The best way to scale a product owner is by letting the Scrum team do more work.
There also isn’t a big difference between a product owner and a product manager. In fact, the best summary for a product owner is an empirical product manager.
The key here is empirical. I find this to be the most difficult part of Scrum to convince people of. “Is it really that hard to plan what you are going to do? You’re a professional, you should be able to plan your work and come up with a working design or architecture before you start implementing the solution. You’ve integrated many systems, why is it so hard for you to tell me when you’ll have this next one done?” Just the other day a coworker told me that business strategy is something that is hard to forecast and predict. Software architecture on the other hand is mostly predictable, so there’s no need for an empirical approach.
A while ago I received a link to a video showing how IDEO redesigned a shoppingcart. This video was supposed to be a good example of how a scrum team should collaborate with a product owner. I was a bit puzzled by the fact that the team didn’t really get good requirements. Just a vision that better shoppingcarts were needed. The team did their own research on what was wrong with these carts and how they could improve them. Then they built a prototype to test their ideas. Here’s the video, it’s an interesting watch: