Have you noticed that your Scrum teams are running Sprints and doing reviews, but are still not seeing the kinds of improvement in product quality, value, and team productivity that you were hoping for? One of the reasons for this could be that the members of the team do not completely understand their roles. In particular, it has been my experience that Product Owners are frequently not indoctrinated into the Agile way of developing products and are not taught how to actually be a Product Owner. In fact, my experience with teaching the Certified Scrum Product Owner (CSPO) training over several years tends to indicate that, while there has been an increase in CSPO classes, most real-life Product Owners have no idea how to do their jobs in an Agile environment.

If you don’t have the time to invest in formal training, let me suggest one thing your Product Owners (or you) could do to improve the productivity of your Scrum teams, and improve the quality and value of your products: communicate!

Product managers are used to getting the product requirements documented and, while still answering questions every now and then, letting the development teams do the job of building what was documented. Product Owners must change the paradigm from answering questions when asked to being a team member with the rest of the developers and taking an active interest in what is being built, how it operates, and whether or not you like what you’re seeing come to life. As a Product Owner, you must come to see your job as creating a product, not simply managing its development.

For Scrum teams, collaboration and communication are paramount. As communication decreases, risk and cost and waste increase. You should plan to be with your team for a little while (1-2 hours) every day. As they build, you should try to see what’s coming to life. If you like it, great! If not, it’ll be easier and less expensive to fix now than to wait for the Sprint Review or, worse, live use of the product.

Requirements change — more than that, even when understood, reality is often different than what was desired. In other words, even if the developers on the Scrum team understand the requirements, what gets built may still not be what you, the product owner, want. Talk with your team, help them build the right product the first time. You’ll definitely see a big difference!



Product Ownership Overview

Download Now!

Swipe this FREE DOWNLOAD and maximize your product’s value.

Normally available ONLY to Artisan students, we’re offering this handy guide to you for a limited time!

More About #TransitioningToScrum

Agile Transformations – Is It All-Or-Nothing?

If you're thinking about transforming your organization to more of an agile mindset, your first question is going to invariably be "where do I start?" Should I pick a single team? A single project? Maybe we should just training everybody and go? These aren't easy questions to answer. Depending on the situation, the right

Leading the Way to Organizational Change

Helping an organization learn how to change means getting an organization to learn that “the way we’ve always done it” works but doesn’t necessarily mean you’ve found the BEST way to do something, or even a reasonably good way to do something. As a ScrumMaster and change advocate, you’ll need to teach your organization

What Causes Conflict on a Team?

Creating change in an organization is also going to create conflict. A good change agent in an organization, and that should be the ScrumMaster, knows what kind of conflict will be encountered and how to handle it. In this section, we’ll discuss how people respond to change and what causes conflict in an organization.

It’s All About Value

One small change can make a BIG difference to your Product Owner success. Before worrying about putting value on backlog items, here's some simple tips.

What Does it Mean to BE Agile?

With the Agility mindset, it's critical to understand the concept of "being" Agile. Some people want "to do Agile", but you don't DO Agile, you must BE Agile.