Dread Pirate Roberts, our QA role

The situation

In our team at Taiga, no member is assigned exclusively to testing and quality assurance (QA) tasks. That is QA understood as checking that the stories we complete meet the acceptance criteria, clean code, test coverage, etc.

Dread Pirate Roberts (frame of the movie "The Princess Bride")
Dread Pirate Roberts (frame of the movie The Princess Bride)

But we were always missing someone to play the part of Defense, someone there in case we were forgetting something. Apart from how boring it would be, it goes against the multidisciplinary team’s philosophy (in a way).

We attempted to address this issue by doing it in pairs, but that didn’t work very well. We did not know who to assign the review task to, and nobody wanted to take it voluntarily. Everyone felt they always had something (better) to do than test someone else’s work.

Because of this, we were often arriving to a Sprint Review with doubts and plenty of bugs.

The Pirate idea

And then, in 2011, came the Agile Spain Conference and one of the tips we adopted was the Dread Pirate Roberts. The details of the legend are in the link, but the fact that concerns us is that the Pirate Roberts, a near-mythical being, has always existed and will continue to exist:

“It is revealed during the course of the story that Roberts is not one man, but a series of individuals who pass the name and reputation to a chosen successor once they are wealthy enough to retire.”

Missions

So, the Pirate Roberts is a role that holds a team member during a sprint, and then rotates amongst all team members.

During sprint the Pirate must perform various tasks, but the most important is to be responsible for quality assurance, for what is being developed and for the delivery at the end of that sprint.

The workflow is as follows: when a team member completes the development of a user story and passes it to the Ready for Test status, the Pirate tests it and if it meets the expected behavior, then moves onto the story to be Closed. All the stories must be in a Closed status before a Sprint Review & Demo. Any error or doubt means the story moves back and requires further checking.

Yes, the Pirate is responsible for personally accepting all the user stories in the sprint before the Demo.

With this simple trick, we immediately increased our product quality.

But the Pirate Roberts has other responsibilities as well:

  • Performs the demo in the “Sprint Review”.
  • Manages communication with customers.
  • Reviews the Backlog and searches for serious deficiencies, and determines if a Grooming is necessary.
  • Checks code coverage in CI tool.

There are other possible tasks, and each team creates his own agreement.

The benefits

The main benefit is improved product quality. You can expect to reach the end of the sprint with more stability.

And it’s fun and useful for the team member as well. Being the Pirate holds great power and responsibility, and also allows each team member - on a rotating basis- to acquire great knowledge of the application as a whole… and the team’s “bus factor” decreased.

And now it’s your turn, how do you guarantee your QA?

Do you find this proposal interesting? Does rotating the role make sense?

How do you currently perform this role in your team?