Should the Product Owner test everything?

A scrum master I’ve coached recently sent me this question and I wanted to share my answer. Would you have answered the same way? What did I miss? What do you ask (demand?) from your product owner?


Question: Hi, Jeffrey,

Quick question for you: Does Product Owner (PO) approval need to be on a per story basis, per feature basis, or both?

We are facing a situation where some of the system environments were not in place and completed work has remained in Dev until today. We received today that the Test environment is ready. The stage environment is due to be completed at some point in the near future. Meanwhile, our team has modified the team’s “Definition of Done” so that completion criteria are more aligned with our capabilities within the framework of system environments being incomplete. Hence, the above question.

The Client


Answer: Hello, Client.

First, it makes sense the PO is included in the conversation around “Definition of Done.” I’m not sure based on the question if they are in the loop, or not. I say this because the team is building and meeting expectations for the PO. It’s the polite thing to do to notify them and explain the new definition. In some cases, it may be more appropriate to ask their permission to change rather than simply notify them of the change.

Second, this change makes sense to me; you didn’t have the right environments previously and now you do. It makes sense the definition should change to accompany the environment and how the team is working.

Third, what’s happened to date and how much trust is there between the PO and team? If the PO has already tested all the existing stories, then they may not want to do more than audit the existing stories in the new environment(s). If the PO has trust in the team and testers, they many never do more than audit the stories. If the PO doesn’t have time, they may never get to more than auditing stories. In the end, it’s a great big “it depends” kind of answer.

What do I want from the PO? I want more involvement, as much as I can get. I want the PO to test every story as it’s finished and at least audit functionality and features as they are delivered. I don’t often get it, but it’s my request.


  1. @jdspyers   •  

    “Jeffrey Davidson: Should the Product Owner test everything?” good read #yammerstl

  2. Jenny Martin (@jennyjmar)   •  

    @jennyjmar PO to agree examples to support biz capabilities up front, verify continuously, then trust team to test thru release process. IMO.

    Editor’s note: This response from Jenny Martin came in via I wanted to post it here in part to recognize her contribution and in part because Jenny’s could be my lost twin. We haven’t met in person yet, but we both love to talk about BDD, Specification by Example, and Impact Mapping!

  3. Mike DeCleene   •  

    Clearly, I need to read your blog more often. 🙂

    I think the question as asked is an implementation question. The more interesting question (to me) is around the organizing principle, which I would state as “We, as a team, need to make sure all the work we’re doing is as aligned as possible with the end users’ needs.”

    Everyone on the team (including the Product Owner, who is the users’ REPRESENTATIVE to the team) needs to be part of a conversation on “What is the best way for THIS TEAM to make sure we’re delivering software that’s aligned to end user needs?” Specific “person does a thing” decisions are the output of that conversation.

    Having the product owner sign off on stories, or review acceptance criteria (or, better, WRITE acceptance criteria) are ways to do that, if your product owner has the availability and can understand the software on a low enough level that every story makes “sense” to them. If you don’t have the availability, consider whether leveraging regular demos is a better option for this team. A/B testing the heck out of everything in production (and substituting “what does the market respond to?” for “what does the product owner THINK the market will respond to”) is another approach. I’m sure there are plenty more.

    Every textbook has answers for “who’s responsible for what on an Agile team?”, which are a great starting point. But every team is different. Don’t get caught up in what the Product Owner “should” do – worry about what the best answer is for the team.

  4. Pingback: Top Blog Posts for Business Analysts: Week of July 7, 2014

Comments are closed.