Story Acceptance criteria between Product Owner and Quality Engineer

Questions
, ,
#1

Hi brain trust,

I basically lead a team of Quality engineers who are embedded on Scrum teams. One team has been replaced by an agile / lean-thinking Product Owner but the QE is very detailed / waterfall approach. Right now, the habit is hard to break from the QE as she was used to having a very detail-oriented PO with multiple toolsets to track requirements, etc. I’m trying to get her buy-in to be more flexible (but that’s another story) and eventually we’ll get there but right now, I need a short-term solution.
So, the process is that the PO will put up a story with very high-level Acceptance criteria. QE will then provide some Testing notes with the details she wanted and then include those as part of the AC before being locked-in during the Backlog grooming sessions.
The PO thinks that the additional AC are looking like test steps and very detailed (and to be honest, looking a bit un-agile). The QE is used to raising bugs as the requirements are usually loosely followed by the Developers, hence, the user story goes back and forth and has a longer feedback loop at the end of the delivery (Making the devs and QA collaborate more and building the feature together is again, another story to discuss!). That is the reason she wants to put more details at the start of the design / requirement phase.

Question is, how do I find the right balance at its current state?

2 Likes
#2

IMHO this is a “people problem” not a process or testing problem.

My only advice is to get the PO, QE and one or more developer talking (Amigo’s). Encourage them to take a step back, and agree on some fundamentals and high level shared objectives.

Ask them to discuss some questions like:

  1. What is the mission of the team?
  2. How can they best serve the customers?
  3. How can they keep the constructive detailed oriented output from the QE and adapt it for the current process?
  4. How do they actually want to work together anyway?

Communication is key when opinions and practices differ.

Make sure the PO and Devs understand the value the QE is bringing, and make sure the QE understands expectations and importantly the WHY around how they might be trying a different way.

Hope this help!

5 Likes
#3

@ebanster - I think that the QE, PO and Devs should come to an agreement on the minimum requirements to be specified in the stories. The minimum will depend on the thing you are testing. You could pick a story as an example and ask the QE why they need (in your opinion) test case like requirements for it. Involve other intelligent and experienced QEs/Devs in the discussion too. That way, they can explain why some of your QEs expectations are/are not justified.

From a QE perspective, I posted a related question in which I ask how much info should be put in a (API) story by the PO - Testing - What information should a story for an API contain?. Does this sound like the QE you are working with? I have stated the reasons why I want a little more details than most POs might provide. Do some or all of my expectations about the requirements seem reasonable to you?

1 Like
#4

Here is a short term solution to think about.

let the tester add whatever testing notes she wants under a section called QA notes rather than acceptance criteria.

she has the details that make her happy and it’s not in the AC and that should make the PO happy.

Another idea is to include the tester in the story writing session with the PO and devs. Hash out what the story is and is not at the beginning of the process rather than the end. I don’t think you can “make” dev and test work together, but you can provide an environment that encourages more collaboration.

encourage dev/QE handoffs. Devs will have the opportunity to describe any requirements not met, scope change, and any helpful hints for testing.

Finally, the QE may not be a good fit for where you want to go and the best decision may be to part ways.