Bxdty

We have a product owner who starts testing while a item is in code Review and give feedback to developers. I see the point of view from a product owner to give feedback quicker, however I don't think she needs to start testing in code review stage but rather wait when the item is ready for testing, Because we have testers.

I've got feedback from the team that "Tasks turn around time is slower (Testing seems to be slow at times)"

Any ideas on this topic?

My suggestions/Solution is:

• Ask PO to wait until the item is in the testing phase and keep to sprint timebox and don't become a bottle neck.

I know this is an obvious question but I would like to hear if someone encountered something similar and what did they do to fix it.

In favor of eliminating waste I'd suggest waiting, too.

Assuming a PO's time is more expensive/valuable than a tester's or dev's, simply because of supply and demand as there is only one PO, but multiple devs/testers, the following would be a waste of good PO time:

• Reporting errors that would have been found by a developer anyway


• Reporting errors that would have been found by testers anyway


• Testing the same things again after scheduled changes (Code Review) have been made

In addition, developers might be a little miffed if their work is criticized before they declared it "done". You don't tell a cook their dish is not tasty dragging it out of the oven when the cook insists it's only half-cooked and needs anther 20 minutes. You don't tell people they park like idiot's when they are still in the street moving. In other words, don't tell people they made mistakes when they are not finished yet. It can only be a "bug" if it should work in the first place.

So filing bug tickets will generate wrong metrics afterwards. Many bug tickets means the developers need to work better. But in this case, they weren't even done yet. So your metrics are skewed.

But as always in Scrum: discuss it with the team, see what everybody has to say and find a solution that works for everybody.

The answer depends on whether this slows down or speeds up the process.

How many of the bugs she found were discovered during the Code Review phase?

If they were all discovered during the Code Review then maybe she's wasting her (and everybody's time). Though we can still ask:

How many of the bugs she found were fixed before the Code Review stage?

If they all were, then she is saving you time by having you review corrected code with fewer bugs.

And then there's the Type Of Bugs she finds that makes a difference.

A Product Owner would typically check the product for UI issues, wording, typos and aesthetics.

These "bugs" will not be picked up by Code Reviews or the QA department, as they are mainly subjective. (With the exception of typos.) So the sooner she fixes these issues the less work (of retesting) for all involved.

If, on the other hand, she's only finding hard to find bugs that a good Code Review would have picked up in much less time, then maybe it's worth pointing out to her that she's wasting her time.

One last thought: If she's simply taking the product for a quick test-drive and (since she found them) reporting all the trouble she finds, then maybe your coders need better work ethics; if they tested it for a minute before releasing it they would also find and fix these obvious bugs.

I don't see how this is a problem in the first place.

If the problem is that the PO is not available to give feedback or answer questions then this is an entirely different problem. If the PO is testing things and finding bugs then they're saving your team time and effort.

So if they're still available to do all the things you need them to do let them do whatever testing they want and be grateful for their input.

As a general rule I would say that the earlier the Product Owner starts testing the better.

The reason for this is that a lot of bugs happen as a result of misunderstanding of requirements. The Product Owner is uniquely well placed to review and give feedback to a team.

Ask PO to wait until the item is in the testing phase and keep to sprint timebox and don't become a bottle neck

If the Product Owner discovers an issue in the testing phase, re-work may be required and a repeat of the code review. This could be considered waste if it was possible for the Product Owner to discover the issue earlier in the development cycle.

Some Scrum teams I have worked with got to the point of demonstrating features to the Product Owner during development, let alone waiting for the testing cycle to begin.

If the team currently finds it disruptive to receive early feedback from the Product Owner then I would suggest looking at ways to improve the development process to make this less of a problem.

My recommendation would be to build your development process around a flexible and early feedback cycle. One approach I have seen taken is to have an environment specifically for the Product Owner. When the development team feels they have a stable build they release it to the Product Owner's environment and let her know that there are new features to review. If there are known issues then they should be clearly communicated and it is the responsibility of the Product Owner to not report duplicates.

Communication and teamwork are critical to making this work.