A Testers Guide to Collaborating with Product Owners

[Bob]

I’ve found that “testing” in agile team is often not good enough. Sure, testing has great value. BUT collaborating with stakeholders and customers can have an even larger impact from a business value perspective.

And your role as a tester is uniquely positioned to drive this impact. In a word, learning how to be more effective in collaborating with your Product Owner can be an even more valuable way to impact your projects and customers.

This is the topic for my March 23 webinar and here we’ll discuss any questions or deeper dives into the areas I’ve touched on. Please join me in the post-webinar discussion!

Bob Galen

Download Bob’s eBook – The Three Pillars of Agile Quality & Testing

View Webinar Recording and Slides Here

[Geoff]

Excellent presentation Bob! Worth every second of my time. Thank You!

[Soile Sainio]

Hi. I missed something due to disturbance in line. You talked about large test and quality focus areas. Do you think these are something to have in backlog as user stories.

[Alan]

Hi Bob,

Many thanks for the webinar, really highlighted the need to close any gaps between the team and a product owner.

I wanted to ask you about the notion of ‘Minimal Viable Product’, do you think it can breed ‘meh’ features within a team? A concept of “ah sure that’ll do, let’s move on to the next one” type of mentality? I have seen it used before to get around fixing some usability bugs, certain team members can tend to fall back on it as an excuse. Is a customer losing out if a team adheres to this concept?

Thanks,

Alan

[marzio]

Hi Bob,
thank you for this presentation, I recognise a lot of my everyday work.
If I’m not wrong, here we’re always talking about a Tester in an Agile Team. What about if there is not a ratio like that and as a tester I’ve to manage more than one team per time?
I’ve read around in the net, there are two schools of thought on this, one for having at least one tester in every team and one for having a Team of testers supporting all the Teams in QA activities.
I could not yet figure out what would be better and I like to know expert opinions.
Thank You.

[Bob]

@Soile, I personally like the view that any major activities that need to occur to meet a project/release goal, should “show up” in the Product Backlog. I’m not talking about tasks. Even larger tasks. I’m talking about larger focus areas – alluded to by the Tapestry notion I mentioned.

For example, if a team needed to setup a large performance testing environment, acquire tools, receive training, and do some sample scripts to verify they could write performance scripts during sprints – then I might call that a User Story and put it in the Backlog. Heck, I might even call it an Epic 😉

Point being, I want that sort of thing visible on the backlog and the efforts contrasted against all of the other work.

Hope that helped.
Bob.

[Bob]

@Marzio, I like to come back to “agile basics” for questions such as this. An agile team is:
– self-directed
– staffed with the cross-functional skills to deliver their backlog
– balanced across those skills – so that they can have balanced velocity
– in Scrum, it includes the Scrum Master and Product Owner roles

I.e. the team is setup to effectively deliver software as a team. To your point, I try to shy away from “part-time” team memberships because it often undermines the effectiveness of the team. And having “another independent testing group” do all of the testing, undermines the intent as well.

Can you do these things? Sure. But I certainly wouldn’t recommend it. But to be clear, I don’t think there are any “magical” ratios for good agile teams. Each has to find its own balance.

Hope that helped!
Bob.

[Bob]

@Alan, Good question!

I think it could, but it shouldn’t. The entire point of Minimal Viable… is to create something that, might be small or incremental, but in it’s own way hits the essence, sweet spot, or value proposition of your clients. It should not be an excuse for mediocrity or ‘meh’.

To be clear, the customer might not get ALL they want/need at once, BUT, it should be something that is usable and meets their most urgent needs. It should delight them and keep them wanting more…

I hope that helped!
Bob.

[Jaya]

Hi Bob,
Very Nice Presentation.

Could you please elaborate the role of Automation Testing in the Agile Team.
Is the Automation Team is inside Agile Team or Outside Agile Team, considering the fact that, Automation Team is newly built in to the organization
and much efforts are needed to automate the existing Product Features plus the newly bult in features.

Thanks
Jaya

[Daragh]

Hi guys.

Glad you all could make it today. Here is the Webinar Recording & Slides,

You can register for the two other webinars in the Agile series Here

Daragh 😉

[Bob]

@Jaya,

This is a relatively deep & broad question. What I’d ask that you do, and I’m not marketing here, is download a copy of my 3-Pillars book and read the automation chapter / references. It will share some insights on your question of internal vs. external team. And the implications of “starting up”. After you’ve read it, please post follow-up questions here and I’ll try to answer them. I think the book will give you a (at least my) perspective.

Here’s a link to the mailing list – in case you don’t have it:
http://goo.gl/3SFQci

Hope that helps,
Bob.

[Camal]

Hi Bob,
first thanks for your amazing talk.

I already read your book and so I am familiar with your view of points. I am also a strong believer that the team is the expert and should choose the right answer for a question within their sprint.

I got two questions :

You talked about that the Backlog should be opened for the “whole village”. I think this is a good point to start, right now the Backlog is just maintend by the PO in my team. I also started an intitiave to get the rights to check the user stories before, because I already got the idea to help my PO for the preparation of user stories.

So far I meet with my PO on every week once for 30 minutes or 1 hour to talk about new user stories than come into our backlog. I then try to make them more clear and add some Acceptance Criteria. I make this approach because I recognized that my team where sometimes pausing in meetings and so I give them something to discuss on already.

My question is, how you handle when everybody is changing stuff in the Backlog. I know there is a history. But should every change be communicate to the team ? I think this approach will lead to a lot of chaos.

My second question is how to get a business domain expert. I know it is a big question. But which pattern do you know. I do a lot of user acceptance testing, sitting right next to a user without speaking and checking his interaction with the product. Are there more ways ? How do you create personas or better question how to you know which persona is the most important.

While typing this I got a third questions. Nowadays everyone is working in their team, focusing on their teams. So when I want to archieve a quality focus area, like automation testing coverage and I want a user story for it should I just talk to the PO get that user story into the Backlog and try to make a high prio of it ? Our should not something like that be an overall company strategy ? In Agile Enviroments I am not aware how the quality is in the other teams. Are we something missing out ?

Thanks,
Camal

[Bob]

@Camal,

On the backlog point, I like the backlog to be open to everyone adding, changing, extending, etc. I’m looking for the team to ENGAGE on the backlog and to make their own. Now at the end of the day, the Product Owner is the final arbiter, so they need to be reading/monitoring the backlog and guiding the changes.

The sync-point, at least to me, to avoid the potential chaos you imply are the ongoing Backlog Refinement meetings. This where team members are discussing their offline changes with the team as a whole and the team is realigning with the backlog.

Your second question, as you said, is a broad one. One way it to get customers involved in the demo. And then earlier than that, in the iterative development of the stories – during each sprint. And remember, part of the Product Owner role is to serve in this capacity within and for the team.

I really like developing personas. How to do that is outside the scope of this thread. However, I always prefer inserting personas in the “As a User” clause of each user story. This blog post might help provide more information for you:

As for your third question, I think that is one way to do it. Ultimately, I believe ALL work should eventually be placed on the backlog. Another way to influence work is to make it a part of the organizations / teams Definition of Done. That will make the team implement things at a more holistic level.

I hope this has helped, Take care!
Bob.

[Bob]

now the link…

[Author]

Posts