Why bother with CSPO if You're Already a Certified ScrumMaster?

Posted by Erika Flora on Jul 12, 2016 8:04:00 AM

In Scrum, Certified Scrum Product Owner, Certified ScrumMaster


Of all the Agile classes you can take in the world, by far the most popular class is that of Certified ScrumMaster (CSM), a certification offered by the Scrum Alliance. That same organization offers another certification course call Certified Scrum Product Owner (CSPO), but in my experience, only about 1 in 20 students end up taking CSPO.  Why the popularity of ScrumMaster over Product Owner? And what exactly is the point of taking a Product Owner course if you are not a Product Owner or if you already have your ScrumMaster credential? 

Having taken both courses, I’ve found them to compliment one another perfectly. A Product Owner class is pretty great and worth the investment (even if you aren’t or ever plan to play the role of Product Owner). Here are two main reasons why.

1. You get a more complete picture of the Scrum roles.

It's no surprise that everyone wants to become a “Master” of Scrum, but the ScrumMaster is only one of the three roles on a Scrum team (like one leg of the stool). Thus, taking a ScrumMaster course only gives you a good understanding of one of the three roles – a partial picture of the whole system. The Product Owner class gives you an understanding of what this complimentary role does and helps you not only better understand the interface with and perspective of your customer (the folks paying your salary), but it also teaches you about the upfront activities involved in documenting and managing business requirements and how to create products and services that will excite and delight.

The course also helps you understand how a Product Owner would prioritize requirements and translate them into User Stories that gives your team something from which to build. Plus, the class is a fantastic refresher of overall Scrum concepts and allows you to get your questions answered from a bona fide Scrum expert – someone who has actually been there and done that.


Ready to take this a step further?
Learn the secrets to mastering Agile, Scrum, and ITSM!

Download the ebook



2. You gain tons of practical resources and tools. 

I have taken a few CSPO classes from different instructors, and each time I have received a few more tools that I use in a variety of applications. In fact, my first Product Owner course was nearly 10 years ago, and I still remember and use (imagine that!) what we discussed during class. Here are a few of the exercises I use regularly with teams:

  • Prioritizing requirements – When you ask a customer what they want from a product or service and how important each requirement is, they will tell you that everything is important. However, running a Product Tree exercise allows you to separate the “must have” requirements from those that are “nice to have” as well as the “won’t haves”.  Here’s what you do: Draw a tree on a large sheet of paper, have everyone list each requirement on a small post-it note, then have them organize the post-it notes according to their importance. It’s amazing how a simple exercise like this can help your customers and teams quickly delineate the importance of their requirements. Using the hierarchy of requirements created by the team, the Product Owner can then prioritize items in their Product Backlog accordingly. Have a virtual team? You can do this exercise online! Check out InnovationGames.com
  • Understanding your customers and the vision for your product – Taking a Product Owner class gives you a view of the “bigger picture” and the reasons behind requirements, which ultimately leads teams to build better products and services. We did another exercise in CSPO class where we came up with customer Personas (stories that define different users). This allowed us to think more concretely about who would be using our product. Once we had personas and initial requirements in place, we created User Stories. This is such a helpful exercise (and learning how to write good user stories is well worth the price of admission), as it allows you to turn requirements that often create confusion and can be interpreted in multiple ways into mini-stories that illuminate the underlying why. This promotes a common understanding and allows the development team to have more meaningful and productive conversations around the requirement. We also created Product Boxes, where we decorated small boxes with magazine clippings to help us think about how we would ultimately market this product. I often use the box exercise to help customers define IT services that will eventually end up in their Service Catalog. In thinking with the end in mind, they are better able to articulate the overall vision of what they are designing early on.
     

Want to learn more about Product Owners?
Here's a quick overview from the one and only Erika Flora.