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):
subtaskwf
In this workflow I configured:

  • TO DO –> In Progress: added a post function using script runner in order to change the status of the parent issue
  • In progress –> TO DO: added a post function using script runner in order to change back the status of the parent issue

Here you can find the script I created for this:

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

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.
To be honest I use 2 different workflows for Story(User story, New Feature, Improvement) and Bug & Task.
The workflow used with Bug & Task is the same as the story but there are 2 more things:

  • TO DO –> In Progress: I added the validator: Required fields: Remaining Estimate
  • In progress –> To Deploy: I added the resolve input screen in this transition
  • In progress –> To Deploy: I added a post function Remaining Estimate = 0

So I create 3 different workflows where 2 have the same logic a part from the things listed above.
For Epic I used “JIRA Workflow (jira)”

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:
boarddev

devboard

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.

boardqa
devopsqa-board

  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
storyparenttaksof

Here the detail of the related bug
bugissubtasksof

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?

Annunci

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 e contrassegnata con , , , . Contrassegna il permalink.

Rispondi

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

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. 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 )

Google+ photo

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

Connessione a %s...