Skip to main content

Does the Product Owner get involved in testing stories

Last post 05:34 am June 15, 2015 by Zoltan Dosa
4 replies
02:28 pm June 11, 2015

Hi all

I have started working as a new PO. Read a lot about scrum and trying to apply this to gain the experience. Eventually I want to do my certified scrum PO and perhaps a scrum master one day.

The company I work at does not have any testers or QAs within any other their scrum teams. From my understanding, this shouldn't be a problem as scrum does not require team members to wear definite hats i.e. have specific specialised roles. However I have been experiencing that a large percentage of the Product Owners responsibility at this company is to test individual stories as part of acceptance. The Head of the Department wants the POs to write test scripts, test the features the team completes, and if the POs testing is satisfied the the PO accepts the story - this must be done within sprint period. A number of the POs are feeling stretched when it comes to the last two days of the sprint because they are then flooded with more than 50% of the stories pending with them to test and accept.

I'm new to this. It doesn't 100% align with the articles I've read about scrum PO role. I had thought that testing is worked into the Definition of Done; and the PO would be regularly reviewing any outcomes of stories to check the features are being delivered. At Sprint Review the PO, with other stakeholders if needed, will get to see what the team completed in the sprint and as they see the work and ask questions they accept the stories or provide feedback if there's something that the stakeholders did not agree on fitted the acceptance criteria.

Could you educate me here please. Is this model of the POs doing the writing of test scripts and manually testing a norm in scrum methodology? Does 'acceptance' mean the PO must perform the testing to validate that the story acceptance criteria has been met?

Appreciate your insights and guidance here.


07:22 pm June 11, 2015

Hi Sophia,

Based on my experience it is most definitely not the "norm" for the PO to do all the testing. There is no reason why a PO cannot get involved in some testing tasks during a Sprint but it is not their responsibility. The PO may well carry out their own brand of testing to accept the story as complete but the duties of testing really should belong within the development team itself.

I am a bit concerned when you state the following too ...

"A number of the POs are feeling stretched when it comes to the last two days of the sprint because they are then flooded with more than 50% of the stories pending with them to test and accept."

....this does sound a bit like water falling over a cliff somewhere along the line ;0)


01:16 am June 12, 2015

Product Owners are not forbidden from also being Development Team members. It is permissible for a PO to be involved in the actual creation of the increment he or she values, including development activities such as testing.

In the situation you have described, there appear to be two problems. Firstly the composition and duties of the team should be a matter for them and not the head of department, who appears to be exerting undue influence in this case. Secondly there is an issue of inadequate Sprint Planning and/or self-organization. The team should be able to avoid testing bottlenecks in the last few days, such as by staggering the flow of work more effectively or by other members assisting in test. Both matters should be addressed no later than the next Sprint Retrospective.


06:40 pm June 12, 2015

Sophia,

The essence of your question is whether the PO is typically also a tester. The answer is No. However, it appears that your org has decided that all PO's will *also* play the role of "Dev Team Member", doing some of the testing. Playing more than one Scrum role is not forbidden by Scrum, but most of us who coach Scrum think that playing dual roles always has numerous challenges -- so we generally recommend against it in all but the most extreme of circumstances. (example - there is no possible way your team can do Scrum unless one or more people play dual roles).

It sounds like your management and team needs some Scrum Coaching, too. :-)

You also might benefit from this article, which explains more of what the PO role is about:
http://ScrumCrazy.com/newPO

(PO "acceptance" is not the same thing as testing. It usually involves a PO, mid Sprint, looking over the shoulder of a programmer or tester while that person does a mini demo of the completed PBI, hoping for acceptance and/or feedback on meeting the PO's expectations)


05:34 am June 15, 2015

This situation seems a bit counterproductive to me. Your goal as a "tester" is to find errors, but if the only testing is at the end of the sprint, it means you work for the failure of the sprint, because there will be no chance to fix errors.
There should definitely be some people in the groups who test continuously. Well, continuous testing and fast feedback are bases of agile.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.