How to separate task completion on dev side and QA verification processes?

[Noa Resheff]

Hello,

I am a project manager working for a mobile app startup company, organizing our dev tasks in JIRA sprints.

I am wondering how can I separate DEV side and QA verification processes for sprints measurement purposes.

Today we have a workflow that looks something like this: new bug / task -> DEV fix (ready for QA) -> QA approved (done). 

This causes a situation in which I compile a sprint with several issues, which are counted as completed only when QA approved (naturally). I would like to change that though, so it will be possible to count issues completed by dev in each sprint (currently they are being pushed to the next sprint until completed by QA).

However, I don't want to consider the DEV fix status as done since it isn't.

Can you recommend a solution?

Thanks very much,

Noa

[Norman Abramovitz]

Create an overall issue which has a separate sub-tasks for design, coding, QA, documentation, system test, deployment or whatever your breakdown needs to be.   Each sub task can have its own issue-type/workflow. 

 In this way each group can have their own workflow and these workflows are parallelized.    Each sub-issue can be resolved and the overall issue only when resolved when all the sub-issues are resolved.

You will need to move the parent issue into the sprint and the subtasks will show up in the sprint.

https://confluence.atlassian.com/display/JIRA/Creating+a+Sub-Task#CreatingaSub-Task-workingWorkingwithsub-tasks

https://answers.atlassian.com/questions/85897

Since you are using JIRA Cloud you will probably need to create your subtasks manually or you might be able to use the REST API to create your subtasks.  I am not up to date on the bundled plugins or the Atlassian connect plugins.

[Noa Resheff]

Thank you for the quick reply Norman. However, (and if I understand Andrew's problem in the link attached it is quite similar), I want to be able to do this (complete the flow of dev fixing and QA verification) over several sprints. Meaning, I want to be able to complete the dev part in one sprint, and the QA verification in the next. I want to be able to count the dev effort as part of one sprint, and the QA's effort separately. How can I do this without having to create separate tasks / subtasks for fixing and verification? Thanks again! Noa

[Norman Abramovitz]

Using Atlassian tools you cannot do it without creating issues/tasks. If you want to do things across sprints then you need to create issues (not subtasks) for each sprint. These issues would be linked to a parent issue. dev sprint 1 dev sprint 2 qa sprint 2 dev sprint 3 qa sprint 3 test sprint 3 parent issue with links to the above issues. The parent issue would be there to relate the individual issues together and for you to accumulate the work log. Most likely you will need to write a REST API script to update the parent script

[Norman Abramovitz]

One of the guiding principles of Agile to complete the work in a sprint. So the next task should be different from the previous task, so having separate issues/tasks seems to be reasonable fit verses trying to push the same issue along meeting multiple goals representing the sprints..

[Noa Resheff]

I do understand the Agile principal here, however it does not seem to make sense, creating multiple tasks for the same subject - dev part and qa part. This results in a load of issues in the system, also making it clumsy to complete an issue's life cycle of new -> in dev -> ready for QA -> completed.

[Norman Abramovitz]

I believe this is one of those cases where the tool dictates the solution (not a good thing at all) and shows one of the weaknesses of JIRA.

[nadavw]

how do I create a QA Issue - 'Sub-Task for issues discovered by QA' - in my board there is only a general sub-task

[Tamas Gulyas]

Unfortunately google brought here me as a result of my search because we suffer of the same issue.

I appreciate that the JIRA would like to enforce the agile principles however as a tool this should be a configuration option to enforce something that one think is good to follow and there are people, developers who do not need fancy manifestos we need solutions to our problems and sometimes.

I would say it is a pretty valid usecase that the development team works in sprints, the testing team works in sprints, the quality works in spints.

Once they all processed the series of issues necessary for a release the software can be released, until then the branches of code,tests,quality records can be updated one after each other and the teams have nothing to do with each other, they are distinct dimensions of the product development (e.g. a testing team can reject a bugfix and the issue can be replanned for development in another sprint).

I always wonder why people complicate tools with introducing hardcoded solutions instead of configurability and push this responsibility to the end user with a sample/default setting. It is actually less work to realize and yet all the tools are telling us how to work instead of supporting versatility :)

[JHolmes]

Am I really the only one who has solved this?

- Create tags on all your statuses, "Dev" with value "ToDo," "InProgress," and "Done", for every status. (If you have anyone else in the sprint, you can do the same for them.)

- Create a "Dev/Sprint Management" board, with three columns filtered on the aforementioned tag values and filter needs at least "sprint in (currentSprint())"

- Set the first column filter to show any issue with "Dev" flag and value "ToDo", the last to "Dev" flag with value "Done". Set the interstitial stuff to everything else

- Set a quick filter to only show the hot-dev items, that is the immediate to-do and the immediate done, so you can avoid clutter

- Create a Kanban board for QA to work out (or a sprint board, if you think that helps) and use the same tagging method to set the first Dev: Done flagged ticket to have a "QA" with the value "To Do"

- You got it from here, I believe in you!

[Anne-Laure Caluori]

Hello Jeremy, 

I am very interested in the way you are dealing with statuses, but would have a few questions for you, though:

- what do your burndown charts look like? Does it help having a better visibility on Developers' work actually been done per sprint?

This is what we would need to change in our team: our workflow includes a QA status (To Do > In Progress > Code Review > QA > Waiting for Release > Done), where we have a huge lack of workforce and accumulate tickets. Unfortunately, the burndown charts only considers the DONE status which comes afterwards, so the results don't reflect their actual work over a sprint.

- if tickets are sent to a separate list when they are on QA, how do you consider effort/time spent on back and forth with developers? Do you include it in a way or another in the current sprint efforts? 

Thanks for your replies,

Anne

[JHolmes]

Burndowns are board-specific: The first column is always "To Do"; the last is always "Done", the middle is where it's "In progress". This happens regardless of it your "Done" is called "Code Review" to your devs (while to QA, "Code Review" is "To Do"). Done as so, your Dev board would show the right burndown, assuming you wanted to getting to code-review finished to be your definition of done.

Your QA board would be strange, however, as the Code Review stage, their "To Do", would have no work at the beginning of a sprint (unless you carry over WIP from previous sprints).

I recommended a kanban for QA's working task board, as they are not quite as scrum-timetable. The backlog they added to the Kanban is great for showing upcoming work, and a filter for "is in current sprint" will make it nice and pretty. (Alternately, you could rank tasks by a custom color scheme or similar so that current sprint is top, then next sprint, then future, then backlog.) Anyway... my team uses scrum-fall (water-scrum?) because we are heavily regulated and also they keep changing the rules on us ("they" is our legal counsel, in this case).

Your question about burndowns... they look saw toothed. QA pushes tasks back from "QA In Progress" back past "Dev Done" (aka "Code Review" ) and into "Dev In Progress." If you use a burn up chart that tracks new work as a stacked chart on (well, under) your burndown, you'll be able to see every time the developers failed their unit tests and had to get smacked down by QA. 

I like to keep two additional boards: "Sprint Planning," which is only for sprint planning/backlog grooming, and can be tuned to hide/suppress things that the product owners aren't ready for in the backlog. If you run simultaneous sprints, you can put your team-wide initiatives here, with "version x.y" as the goal, with the feature list in the "To Do" and the "Ready to Deploy" in the done collumn. In theory you should be able to do this on the backlog page using the version number,  but I didn't see a nice way to nest version numbers (so that 1.2.3.x, the dev release version number, is under 1.2.y.x, the QA release version number, itself nestled under under the 1.z.y.x, the feature level version number, which is nested under the architecture/generation version number). If you have a delivery at a sprint's end, you can use this board, even if it's a multi-sprint delivery schdule.

The other good board is "Standup Status", which has a column for each "hat wearing" role on the board regardless of who currently has it... "BA" has requirements gatherinjg, as well as when the coder in india is confused and kicks it back for clarification, then there's DEV, QA, then PM/PO (Product Manager/Product Owner), and my favorite hat, Architect. He's the one who gets tthe entire board when [C_O of the day] walks into [sprint planning/grooming/standup] demanding we [do something absurd/stupid/company destroying] THAT UNDOES EVERYTHING WE'VE DONE ... hooray agile! Now excuse me, I'm rewriting literally everything... 

Oh, make sure to turn on "number of days in column" on the status board, then create a filter that shows any ticket that was at some point assigned to each team member. That way, if everyone dogpiles on the timezone shifter, your lead can see who's really been dropping the ball.

[Colleen Coleman]

I know this is an older post and I have question regarding the resolution for the dev done column in the sprint board.  Are you leaving resolution box checked so it marks a truly done or it is unchecked so it is officially done after it runs through the QA Kanban board?

Thank you in advance for you assistance.