About me

Sono Andrea Regoli ho 31 anni e lavoro in ambito IT da oltre 10 anni.

Ho iniziato come programmatore e successivamente mi sono poi specializzato come Business Analyst: ottimizzazione/automazione dei flussi aziendali.

Ho sempre lavorato a contatto con i clienti in quanto consulente, di conseguenza ho maturato una buona capacità di relazione e comprensione delle loro richieste.

Attualmente svolgo il ruolo di Project Manager IT coordinando un team interno e alcuni fornitori esterni.

Mi occupo del monitoraggio dell’intero lifecycle dei progetti, delle possibili problematiche e delle evoluzioni future.

Inoltre seguo la gestione dei clienti/stakeholders dalla definizione di offerta alla raccolta feedback post deploy al fine di raccogliere possibili nuove features da realizzare per il miglioramento del servizio offerto (Continual Service Improvement).

Sono appassionato di tecnologia, quindi cerco sempre di rimanere aggiornato e nel tempo libero mi diletto a sviluppare app per mobile

Contact Me

User's feedback

Here some user's feedback about my Windows Phone apps


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

In my previous article I wrote about the problems I came across using Jira standard project workflow.
In this post I’ll show you in detail how I solved these problems.
Solution Mixing SCRUM and Kanban (it’s not ScrumBan)
In my opinion Kanban is the right choice to show and manage a flow, SCRUM instead, could be good to deal with some status of our workflow.

Dispite of adding the state To Review / To Test / Ready for QA in the dev board, I obtained a good result using a Kanban board for QA users.

First of all I’ve realized two different workflows:

  1. Story (User story, New Feature, Improvement) Task, Bug
  2. SubTask

Here my project SubTask workflow (easy):

Here is my project Story(User story, New Feature, Improvement) Bug and Task workflow:

As you can see, they are very different and the story workflow has lots of status that I’ll explain when I use it below.

I don’t know if you can understand my idea now, but I hope the next part will clear all your doubts.

SCRUM Dev board:


Before going on with this topic, I suggest looking at Story Point vs Estimated Time and config in Jira

Here the explanation of the only subtask statuses:

  1. To Do:
    Something to do
  2. In Progress
    subtask that are worked by someone
  3. Resolved
    subtask resolved

And that is easy.

Some of them are mapped also for story, bug and task.
Here the explanation of the only Story(User story, New Feature, Improvement) Bug and Task statuses manageable in this board:

  1. To Do:
    Something to do
  2. In Progress
    Something that are worked by someone. In case of story when at least a subtask is in progress.
  3. To Deploy
    The story is completed and committed to GIT (svn, tfs)

In this SCRUM board you can only deal with these statuses.
Noticed that when something is completed by devs doesn’t mean that is ready to be tested because many times they have completed it in their environment but it’s not deployed.
Keep this in mind.

As you can see in the Dev board all status are mapped in the last column. This solve the the "Burn down chart impact (previous post)" because every time an issue is completed, It will "burn" its sorypoint (or time estimate do not use it).
Sprint planning
Before starting the sprint, dev team analyzes the story point of each story and split it in the necessary subtasks. I prefer to estimate each subtask in remaining time, but it’s not necessary. The team can avoid to estimate subtasks if they prefer, the important thing are story points.

Sprint starts
The team starts working the stories moving subtasks from TO DO to In Progress. When they move the first subtask the have to remember to move “in progress” the story as well (I automated it, using Script Runner and I’ll tell you how in next posts).
When all subtasks are completed jira asks to complete the story as well.
The story will be moved to the next available status that is “To Deploy”

This is everything I’ve to do in the scrum board
Easy? yes it is.

Kanban DevOps and QA Board:
This board is thinked for “Operations” that deploy the changes or for only QA team that deploys the changes by theirselves using some deployment tools like jenkins.


  1. To Deploy:
    The story is completed and committed to GIT (svn, tfs)
  2. To Test
    All changes are deployed to an integration/staging environment
  3. In Review
    A QA user is reviewing the story, bug task. Here subtasks are not visible.
  4. Closed
    The story, bug, task respctes UAC
  5. Reopened
    The story, bug, task doesn’t respcte UAC so it’s parked in this status

As soon as a user story, task, bug is done they appear in this Kanban board.
I named this board DevOps and QA because the issues that you can see here are completed by dev but this doesn't mean that a QA team can already chek them.

When all issies are deployed in staging/integration server they are ready to be checked and in order to tell this to you QA team it's necessary that Operation team moves the story from the state To Deploy to To Test. The operation team could automate this writing a script that uses jira web services to move automatically issues. This solve the problem "The QA must work in the same dev environment (previous post) "

Now all user stories are ready to be checked not directly in checking as the default jira baord. A QA member can move the story/task/bug from To Test to In Review and this means that he/her is checking it and this solves “Concurrency QA people (previous post)“.

If the story passes all UACs the QA member move it from In Review to Closed and this means that the story could be deployed in production.

If the story failed the test, QA user have to move the story from In Review to Reopened. But this will not appear to Dev board. In oreder to notify dev team why the story is failed QA user have to create new issues (usually bug or task), link them to the story failed and plan it for the current sprint (this could be the next sprint of the completion of the user story)

Here the detail of a failed story after the creation of some tasks and bugs

Here the detail of the related bug

Now dev team can see tasks or bugs in the dev SCRUM board and using the link dev can understand wich story is referred to.

When dev team completes tasks and bugs, QA can see them appear in the kanban board ready to be deployed.

Using the link inside the user story, It’s easy to understand if all related bugs are complted or not. In case all bugs and tasks are completed QA team can move the story to Close

I wrote a lot, I know!
I hope this solution may help you to manage your software project even if your company is not a pure SCRUM arganization.

Have you found a better solution?
What’s your experience about it?

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