Problem solve Get help with specific problems with your technologies, process and projects.

Exploring the role of the product owner on a Scrum team

Expert Scott Sehlhorst discusses where the product owner’s responsibilities start and stop, particularly in relation to automation.

Do product owners have a say in development techniques such as decisions around automation?

In Scrum, a product owner's role is to act as the provider of vision (sometimes called the "voice of the customer"), and to be a member of the team. Most people describe Scrum as having a product owner, a Scrum master, and "the team." I think of "the team" as everyone, including the "delivery team" -- the people who create the product, the Scrum master -- the person who helps the delivery team be more effective, and the product owner -- the person who directs the team to work on the right stuff.

As the person who provides guidance to the team, the product owner should say "this is important" and "this is more important than that." The product owner does not get to also say "do it this way."

However, the product owner, as a member of the team, shares responsibility for what the team is able to accomplish. How much the team is able to accomplish, and the quality level at which the team is able to deliver are both factors that define what the team can accomplish. Automation (generating code and tests, running tests, building and deploying the product) increases what a team can accomplish. A team has to invest, to create the automation, before the team can realize the benefits of using it. That investment comes with a short-term cost and a long-term benefit -- delaying the delivery of product capabilities now, in exchange for the ability to deliver more and better product capabilities in the future.

The product owner can absolutely decide that investments (now) that improve the team's ability to deliver are more important than the delivery of product capabilities (now). The product owner can write a story that says, "As the delivery team, we need a repeatable build and deployment process so that we can create the product more frequently at lower cost" with acceptance criteria of, "The process will result in an identically built product given identical code" and, "The process will take no more than 5 minutes of a team member's time to complete." The product owner does not get to specify how the build will be automated (e.g. with ant scripts or make or ruby). 

Technically, the product owner cannot specify that the process be automated -- but the product owner can define acceptance criteria that obviate manual processes. The members of the delivery team get to tell the product owner what the cost of delivering this story would be (presumably by building automation). Together, the entire team has a conversation about this -- does it make sense, is there a better way, etc. The product owner then decides if the required benefits (the acceptance criteria) justify the opportunity cost (story points not spent improving the capabilities of the product).

Next Steps

Discover how critical the product owner role is to software development

Learn why companies need to fine tune Agile product owner responsibilities 

Dig Deeper on Topics Archive

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

This is basically the process that we follow. Our product owner is pretty technical (by necessity, because our team mostly works on back end processes with no actual users). So he will sometimes go into the implementation of the change. He does end up having a voice in that choice simply because some implementations are more expensive than others (spoiler: your product owner will always go for the cheaper choice!)