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

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.

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?

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

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
jira_67workflow

This is, instead, a generated Jira 7.0 Workflow (simplified workflow)
software-dev-gt-wf-col

And this is an usual board that use these kinds of workflows:
b9a88e24-3ab6-4fe4-a34f-d8cb3eed964f
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)

CONs

  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
estimation-dev-board

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

SumUp
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.

ScriptRunner
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
http://www.emilianosoldipmp.info/tag/user-acceptance-criteria/
Here more detail
https://en.wikipedia.org/wiki/Behavior-driven_development

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

How do I automatically move parent story to done (new status) when all sub issues or tasks are completed in Jira?

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:
TO DO –> IN PROGRESS –> RESOLVED

MY Parent Issue (story) has this workflow:
TO DO –> IN PROGRESS –> TO DEPLOY –> ect

Here some pictures to understand it better.

My statuses
story-and-subtask-status

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.
jiraupdatepareissue

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

jiramovetodonebutton

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

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