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.

Pubblicato in Agile, Jira, Management, SCRUM | Contrassegnato , , , | Lascia un commento

Story Point vs Estimated Time and how to config Jira to help us

What are story point? what is this shit?! Fibonacci series? naaaaa IO estimate my work in days or hours… I don’t want to bother with this useless stupid system.
How many of you have you thought at least one time this sentence?
I’ve thoughted it for some months when finally I found a great article that allow me to understand why I was wrong!

There are lots of topic that talk about it and I don’t want to write about it in this topic.

Story point is the right metric for our user story estimation.
Could it be the only metric in our scrum project?
No, you can estimate both with story point and time but each of them has a target.

Use storypoint to estimate User story. User story are what our team have to work.

This could be enought to work on a IT project.
If you or your team prefer you could use subtask.

Starting from a user story split it in subtasks that are necessary to realize the user story.

Now your team have two options

  1. Estimate subtasks
  2. Do not estimate subtasks

There is no role, I prefer that subtasks are estimated but it’s not required.
If your team like to estimate it, now the right estimation metric is the time.

To sum up:

  • User Story are estimated in story point (and business point to understand the business priority)
  • subtasks are estimated with time

Starting from this concept, here how to achieve it in jira:

I use story point to evaluate user story, new feature and improvement. I don’t use storypoint to evaluate task, bug and obviously subtask.
In my mind a task is something that I use to ask developers to change but it’s not a bug. Therefore I use task to say something like “the button is not aligned to the table”. Any Change Request is a story not a task, even though the PO change the request IMHO.

Considering that, It means that the effort of doing bugs and tasks are not considered and It’s true. This means also, that probably the story point burned in this sprint will be less and I like this effect bacause this consider if the work done was good or not.

In order to track storypoint and time in the same SCRUM board you have to set this configuration:
Your board –> Config –> Estimation

Pubblicato in Agile, Jira, SCRUM | Contrassegnato , , , , | Lascia un commento

Jira useful add-ons

Jira suite utilities (FREE)
This free add-on add a lot of validators, conditions and post functions
PostFunction aggiunge il setta il field da un altro field (stesso issue o parent issue)
I used it to copy value from other field (within issue or to sub-tasks)

JIRA Misc Workflow Extensions
This one an add-on that adds lots of features about workflow, in detail post functions.
This plugin is more complete than Jira suite utilities but this one is not free as the previous one

The most important feature offered by this add-on is SumUp Tow dimensional Filter Gadget.
Jire offers a two dimensional gadget but it counts only the number of issue.
This gadget can sum the field you want, so you can for example sum the estimate time of each person on your team.

If you’re using heavily Jira’s workflows or some jira’s integration features you can’t live without it! It’s a must have!
I used it to perform lots of actions during a post function event.
You can do what ever you want because you can write your own logic in a language java alike

Pubblicato in Jira | Contrassegnato , , | Lascia un commento

Agile UAC User Acceptance Criteria in User Story

Everyone knows User Acceptance Test (UAT) but do you know UAC? If the answer is no and you usually write user stories I suggest reading this post the links above.

When I started adopting User Story and writing them in the right way after a little period of time I noticed that sometimes the stories weren’t properly realized by the team.
The problem wasn’t the skills of my team but what they understood reading the story. I needed a way to improve the comunication and to create stories unequivocally in order to everyone can’t understand something different.

I found this artcile that came out with the solution I was looking for
Here more detail

Pubblicato in Agile, Management | Contrassegnato , , , | 1 commento

How does Jira automatically move parent story to done (next status) when all sub issues or tasks are completed?

I’ve struggled with this problem a lot of times and I wasted lots of time understanding how Jira deal with it.
Finally I understood how Jira works and I’m very happy about that!

There are lots of topics where people ask about how to move a parent task to done when all sub issues are completed.
The basic Jira workflow (v 7.0) support this by default, but how does it work?
It depends on the statuses of your board.
First of all, the parent issue must be IN PROGRESS (in reality must be to the status before the DONE status) not in TODO, and considering that Jira doesn’t move it automatically you’ve got to do it manually or creating a post function with Script runner for Jira (I’ll create a dedicated post with some post functions I’ve written)

Another required condition is that the next status of the parent issue must be mapped to the last column (done?) of your board.
It doesn’t matter what status is the next status of the story but it must be mapped in the last column. For example if the parent status is currently in progress and the next status is “ready to deploy”.

My Subtasks has this workflow:

MY Parent Issue (story) has this workflow:

Here some pictures to understand it better.

My statuses

If all above conditions are verified when you move all sub issues, Jira will ask you if you desire to move the parent to “done“. Even though Jira write “done” it means the next parent status.

If you answer Cancel Jira will show the button “Move to done


Pubblicato in Jira, Management | Contrassegnato , , , | 2 commenti

Jira Workflow postfunction copy value from other field

Today I struggled with this problem:
How to set a field copying it from another one?

I looked for a solution on the Internet and I found 3 different ways:

I installed jira suite utilities that is free and works good for my purpose.
After that, in post function you can find the option: “Copy Value from other field”

I used it to set the field Sum Time Spent from Original Estimated. Doing this you can see the progress in parent Issue (If you use subtasks)

I haven’t found any free solutions to set status “in progress” of the parent issue when a subtask move from todo to in progress yet.
If you are not looking for a free solution you can achieve it using “JIRA Misc Workflow Extensions”

Pubblicato in Jira, Management | Contrassegnato , | Lascia un commento

Calendar appointment .ics location clickable

Today I’ve analyed a customer’s request about generating a calendar appointment (.ics file)

I discovered that mobile devices try to recgnise the event address and if they recognise it, they create a link to the related map.
Here are my tests:

Via Guglielmo Marconi, 123, 48018 Faenza RA
via Guglielmo Marconi, 48016 Faenza RA
via Guglielmo Marconi, 48016 Faenza
via Guglielmo Marconi, Faenza RA
via Guglielmo Marconi, 123 – Faenza RA
via Guglielmo Marconi – Faenza RA

via Guglielmo Marconi, Faenza
via Guglielmo Marconi Faenza
via Guglielmo Marconi – Faenza
Faenza RA, via Guglielmo Marconi
Faenza RA – via Guglielmo Marconi

Here a link about ics format:

Pubblicato in Uncategorized | Contrassegnato , , , , | Lascia un commento