Questions from a Certified Scrum Product Owner (CSPO) Class

I recently taught a Certified Scrum Product Owner® (CSPO) Class at Watermark Learning. As is often the case, our time-box did not allow for a discussion of all of the questions raised during the class. With only two-days to unpack the most difficult role in Scrum, there are always questions that can be explored more deeply using a blog as a medium.

With that goal in mind, let’s explore some of the questions raised in the recent CSPO course.

I hear “Product” often; what does that mean?

“Product” is defined by Merriam-Webster as, “Something that is made or grown to be sold or used.” Great, so what does that mean in a “Scrum” context? “Product” can mean anything that a customer or client finds to be of value. This means that any number of items can be “Products” – software that is used internally can be a product, a training class can be a product, even a “service” such as cleaning can be a product under Scrum.

The key to identifying your products is to think of your organization as if it were a stand-alone company. What is it that you sell? What is it that a customer would be interested in buying from us? Take this one step further and engage your customers or clients and ask, “What do we provide that you value?” and “Why do you value it?” Be prepared to be surprised. For example, I value my smartphone, not because of its technology but because of what it allows me to do – keep in contact with friends and colleagues while on the go.

How to transition from Business Analyst to Product Owner?

While many people that are new to Scrum view the Product Owner as a Business Analyst by another name, the Product Owner is actually a much larger role. It is a leadership role whose goal is to maximize the value of the product.

A great Product Owner has three core attributes: 1) They are knowledgeable; 2) They are available to the Development Team; and 3) They are authoritative.

Most Business Analysts possess the first two attributes – they are knowledgeable about the domain the product will address and the users it will serve. It is the third attribute, authority, which most analysts need to develop if they are going to be a successful Product Owner.

Look for more on this topic in an upcoming blog.

Learn More about our Agile Training, Coaching, and Certification Preparation

How do we think in “capabilities” and map to a Product Backlog?

User Story Mapping, a technique developed by Jeff Patton, is a great way to discuss high-level capabilities and break these capabilities down into user stories. A benefit of using this technique is that it allows everyone associated with the product development effort to not only understand the relationship between the features and user stories associated with the product, but to also allow for discussions about how users will actually use the product.

How to transition from traditional requirements to User Stories?

Traditional requirements, those documented in “System Requirements Specifications” or “Business Requirements Documents”, are substitutes for conversation. They are a relic of a single set of conversations held long before any working product is produced.

User Stories are meant to be a “reminder of a conversation had” or a “reminder to have a conversation”. These conversations are meant to occur continuously throughout the development of the product. Having these conversations continuously allows the Scrum Team to inspect and adapt based on feedback and changing business needs.

The best way to get started with user stories is to identify the target users for the product and engage them in these conversations. For example, as a Product Owner, spend time observing users in their native environment and asking them, “What are your pain points?”, “How will using this product make your life better?”, “What does a successful product look like to you?”, and “What changes to this product would make the most dramatic difference in your ability to serve your customer?” Once these conversations are started, inspect and adapt as you evolve and improve your user stories.

What are consequences of the ScrumMaster and Product Owner doing the Work?

There are a number of consequences of having the ScrumMaster and Product Owner actually do the work of the Development Team. Before discussing these consequences, it is important to note that the Scrum Guide indicates that it is optimal for the ScrumMaster to not be a member of the Development Team.

In my experience, most ScrumMasters who attempt to develop end up not fully filling their role as ScrumMaster while at the same time losing the benefit of being a neutral servant leader to the Scrum Team. A ScrumMaster is meant to be a change agent for the entire organization – how can they serve in this role when they are worrying about how to deliver the sprint goal?

Product Owners are subject to the same time constraint and, when they attempt to actually develop, lose the ability to fulfill all of their responsibilities under Scrum. From managing stakeholders to accepting or rejecting the work of the Development Team, it is difficult, if not impossible, for a Product Owner to be a “Product Owner” while also being a member of the Team.

Finally, having these roles involved in actually doing the work of the Development Team creates a false sense of what the Development Team can accomplish within a Sprint. It also decreases the Development Team’s ability to self-organize and be accountable for the results of the Sprint.

Future Attractions

In subsequent posts, I will address additional questions raised in my CSPO courses. In the meantime, please leave a comment below, and check out one of our upcoming Certified Scrum Product Owner courses at Watermark Learning. It would be great to discuss these topics and others with you in our next session.