Is moving Jira epics/stories/sub-tasks/bugs into "Done" the only way to track a developers efforts?

[Jasmine Schwartz]

I have a scrum master where I work who refuses to change the Jira workflow to incorporate QA. This team has never had QA before, so they feel that it isn't necessary to incorporate us into their workflow. The scrum's argument is that the only way to track the developer's idea of what is their development for a feature being complete, is to move tasks into "Done". He says there is no other way to track this otherwise. Please advise if there is another way as opposed to moving things into Done. This makes a QA's life very inefficient because we become responsible for moving the the task through 3 other statuses currently in order to place it in testing. It's just absurd :(

[Jack Brickey]

there are other threads in the Community discussing how best to incorporate QA into an agile workflow. Which I think is at the heart of the debate here so you may wish to search a bit to get more insight. With that said here is my opinion on this...

I concur that you should not use a workflow that only completes a task when QA has touched it. Rather I prefer a solution where development and QA have there own tasks. Example...

• Story 1 - "We need to develop a new solution for selecting the customer in the UI"
• Story 2 - "We need to verify the new solution for selecting the customer in the UI"

Story 2 is linked as blocked by Story

This allows the team to measure development and QA velocity independently. Also there is no good way to estimate tasks using a single task. Example - lets say the developer says it will take me 16h to complete the development and QA says it will take me 4h to test. So you set the OE to 20h. Then the developer takes 18h but it still takes QA 4h so now you are 2h over budget w/o the insight of which one actually ran over.

Now, if you are certain that your QA can complete within the same sprint as the development the you could consider a single story/task w/ sub-tasks. But only take that path if you are confident and don't really care about tracking time, etc.

[Jasmine Schwartz]

Thanks for you response, but it didn't answer this:

"Please advise if there is another way as opposed to moving things into Done."

I've worked in many agile teams and none of them have ever had their devs move tasks to Done in order to track.

The flow has always worked like this (with other companies I've worked with) to incorporate QA in a TDD environment:

To Do > In Progress> Ready For Testing > Testing in Progress > To Be Fixed > Done

With the exception of Blocked for items that are out of our control and generally information required from the clients. This team treats Blocked items as items that require bug fixing. The scrum refuses to do it any other way even though our team requires it. That is why I need to know if there's anything other than moving tasks into Done that can help the situation.

[Jack Brickey]

Sorry Jasmine I thought I had answered with my last sentence but did not elaborate so let me do so here.

If you wish to have a single task to track the development and QA then you can modify your workflow accordingly. In fact, the example you presented does just that.

To Do > In Progress> Ready For Testing > Testing in Progress > To Be Fixed > Done

The developers own the first two, the third is 'shared' (developer transitions issues into the status while test engr transitions it out) and QA owns the fourth, the fifth would be shared (QA finds bug and set to To Be Fixed and developer moves back to In Progress). Finally QA owns moving to Done.

Again, I'm not a fan of this but if it works for your business then that is good. In fact I did something just like this many years ago but changed for reasons I mentioned. When I was doing this I actually created two boards one for DEV and one for QA and I broke the workflow across the two boards as follows:

• DEV: To Do, In Progress, Done (where Done column had "Ready for Testing" status mapped)
• QA: Ready for Testing, Testing in Progress, Done (note: i did not employ a "To be Fixed", rather I had QA open separate bugs)

By separating into two boards my Dev team was working agile and QA using a Kanban. Two boards has the benefit of allowing the Dev to mark their effort as Done.

The key is to find a process that works for your teams collectively.