How to manage a Scrum project and QA (Quality Assurance) / test phase with Jira part 1

When you start a software project in Jira, usually a basic workflow is generated for you.
I spent lots of time studying Agile philosophy, in particular Scrum and Kanban.
I tried to apply everything I learned to my team and I’ve always had problems applying QA (quality assurance/test) phase.
The “main” book of Scrum “The Art of Doing Twice The Work In Half the Time” written by Jeff Sutherland doesn’t talk about QA phase even thought I think it’s one of the best books I’ve ever read about Scrum.

I look around for some more information, but I didn’t find any good solutions so I did a lot of tests by my self and finally I found my own solution (It’s good for me and my team).
Before talking about my solution I’d explain some other solutions and their pros and cons.

In this post I’m talking about Jira because it’s the software I use to manage my projects.
Jira is a good software with lots of add-ons and a great community, but remember that Jira was born to manage dev issues.
You can understand it by thinking that jira called each item “issue” and looking at the resolution field.

In the version 6.7 Jira generated this workflow for software project

This is, instead, a generated Jira 7.0 Workflow (simplified workflow)

And this is an usual board that use these kinds of workflows:
Image fond online
I think this is the usual situation of most companies…

We can imagine that in a team there are some devs and a QA user and we can imagine:
3 columns for developers:

  1. To Do
  2. In Progress
  3. (Resolved) Code in Review / QA / To Test

3 columns for QA user

  1. (Resolved) Code in Review / QA / To Test
  2. (finish with success) Closed
  3. (finish with fail) Reopened (usually mapped in the same column of TO DO)


  1. Works only if there’s only one QA person
  2. The QA must work in the same dev environment
  3. Burn Down chart impact

1. Concurrency QA people:
In this situation if there are 2 or more QA users it’s impossibile to determine if another QA user is already checking this issue or not. Developers has 2 status to dermine it: TO DO and In Progress.
In this board, instead, QA users have only one status. In order to improve it, it is necessary to add a status To Review / To Test / Ready for QA.

2. The QA must work in the same dev environment:
In this period there are lots of books and resources that talk about DevOps, Continuous Integration (CI), Continuous Deploy (CD) ecc.
I don’t know your situation but not all companies have these systems. Even though there is an automatic CI flow usually the deploy in staging/integration is manual due to you can’t deploy everytime you want.
On account of this It’s necessary that QA checks only deployed iessues and as you can see there’s no way to determine if an issue is deployed in staging/integration or if it is solved only in git or on the dev’s pc.

3. Burn Down chart impact
In pure Scrum QA memembers are part of the team and at the end of the sprint all user stories must be checked by QA (and obviously unit test e integration test) and ready to be deployed as soon as the sprint is closed.
Are you in this situation? Unfortunately, I think it’s very difficult. Even though you’ve automated CI, there are some manual checks (UX) that happens after the end of the sprint. Another situation could be a QA team for multiple projects (1 team cross projects).
For these reasons, I prefer remove the QA from dev board and as soon as a dev complete an issue, they move the issue to the last column so the burn down chart can consider it, and they disappear. Otherwise if the QA team stops some stories by checking it for long time, the story point of these stories are not burned at the end of the sprint. This will cause that a team burns very different story points every sprint, and the storypoint burned in a sprint are not reliable.
The side effect of my solution is that the story points are burned even thought the work done by the team is bad… so it seams that they work a lot… you’re right but next sprint they have to fix all bugs (and I don’t use story point to evaluate QA bug) so the burn down chart will drop.
During the next sprints it will move constantly when the team starts working well; producing a few bugs.

In this article I showed every problem I found working with the default Jira workflow and board.
In the next post I’ll explain what I’ve done to deal with them.

Informazioni su Andrea Regoli

Project Manager .Net Developer WPF WP7 Asp.Net c# javascript ajax SQL sharepoint
Questa voce è stata pubblicata in Agile, Jira, Management, SCRUM e contrassegnata con , , , . Contrassegna il permalink.


Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo di

Stai commentando usando il tuo account Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...

Questo sito utilizza Akismet per ridurre lo spam. Scopri come vengono elaborati i dati derivati dai commenti.