How to improve the workflow on our team

[Jessie Li]

Hi there,

We are using Jira to manage our APP development. Our Jira scrum board now is set by the flow below;

The issue types are: Epic,Story, Task, Bugs, Improvement.

When start the sprint:

We create development tasks to developers(for example A), and test tasks to the QC team(for example B). when pull the task ticket to Need Review, and they will reassign the ticket to QC responsible person. When QC start to test, they will drag A and B to "Testing" status. If there are bugs, QC will create the bug ticket(for example C) and let it block the A & B. 

However, I have some confusions now:

1. Sometimes we need to submit a test version first and let QC team to start test earlier; in this case, when FE submit a new build with "Need Review" tickets, they are not stoping the development of other undo tasks, so it's really possible they pull more tickets from "IN PROGRESS" to "NEED REVIEW", when QC go to test, they cannot have a clear scope of test version.

2. How can we better manage the test process? making it more automatic, and very clear about who do what.

[Danny · Accepted solution]

Hi @Jessie Li

Have you thought about using role based conditions in your workflow to allow only certain project roles to transition in such statuses as TESTING? This way you have effectively set up a quality gates that only your testers can progress issues through. 

From the information you have submitted it concerns me that you are using one workflow for all the issue types you have listed above. I'm not sure why an Epic would need a formal TESTING status. Conversely, what does the status, IN PROGRESS, mean when the issue type is a bug. 

I think you may need to think about what you are trying to achieve with each issue type and what their workflows, or life cycles should be, as well as what information you need to capture. 

Hope this helps,

Danny

[Jessie Li]

Hey Danny,

Thank you, very useful for me. 

When the issue type is a bug, IN PROGRESS means the developer is debugging. 

I wanted to seperate the workflow by issue type, such as tasks and bugs...However, they all follow the same lifecycles.

Tasks:

TODO->INPROGRASS(in developing)->Need Review(finished the coding)->Testing(during QC test)->Done(pass the test and finished)

Bugs:

TODO->INPROGRASS(in debugging)->Need Review(fixed the bug)->Testing(verify the bug)->Done(pass the bug test and finished)

In case of Epic, I agree with you that it shouldnot have any status.. 

I feel that something is wrong but I cannot locate it, can you see the problems with my explain above?

Thank you so much.

Jessie

[Jessie Li]

May be I should make the task lifecycle only TO DO->INPROGRESS->DONE? But in this way how to interact with QC?

[Danny]

Hey @Jessie Li

Thanks for this detail, it really does help. Couple of suggestions below:

I wanted to separate the workflow by issue type, such as tasks and bugs...However, they all follow the same lifecycles.

You could create or copy and edit an existing workflow. It would need pairing with an issue type and a workflow in a workflow scheme. 

Tasks:

TODO->INPROGRASS(in developing)->Need Review(finished the coding)->Testing(during QC test)->Done(pass the test and finished)

Bugs:

TODO->INPROGRASS(in debugging)->Need Review(fixed the bug)->Testing(verify the bug)->Done(pass the bug test and finished)

Needs Review seems like a state where nothing happens; it is not being worked on nor is it being tested. Do you really need it? What information does it give you?

Done (pass the test and finished) 

What happens when you mark a Task or Bug as Done but it is obsolete, deferred, not longer applicable? Have you thought about utilising Resolutions to understand why an issue type was set to the Done status?

case of Epic, I agree with you that it should not have any status.

I think an Epic should have statuses; it has a lifecycle, it is created, it is progressed upon (indirectly), and there would be a point when it has been achieved/delivered. So for simplicity, you could have an Epic lifecycle similar to the below:

TO DO - IN PROGRESS - DONE

How would you track your Epics? 

Does the above help? Without knowing your processes I am limited in helping you. I think from the information you have posted you would need a status to identify when the work form the developer is done and the tester's review begins. 

Let me know if you would like further help on this. 

Thanks,

Danny

[Jessie Li]

Thank you very much Danny. Please see my reply

Tasks:

TODO->INPROGRASS(in developing)->Need Review(finished the coding)->Testing(during QC test)->Done(pass the test and finished)

Bugs:

TODO->INPROGRASS(in debugging)->Need Review(fixed the bug)->Testing(verify the bug)->Done(pass the bug test and finished)

Needs Review seems like a state where nothing happens; it is not being worked on nor is it being tested. Do you really need it? What information does it give you?

• Needs Review is to inform QC team and Product team that engineers have finished, waiting for review/test. Because some of the tasks require Product team to verify instead of QC(engineers will assign to them directly). PO can change status to DONE or to NEED TO TEST status, they can also reassign to engineers if the result doesn't match their requirement.  So for QC team, they will pull the tickets from NEED REVIEW to TESTING basing on the test progress, they pull them when. 

Done (pass the test and finished) 

What happens when you mark a Task or Bug as Done but it is obsolete, deferred, not longer applicable? Have you thought about utilising Resolutions to understand why an issue type was set to the Done status?

• Good question. I haven't thought about it, we haven't face the situation that Task or Bug is done but obsolete/deferred or no longer applicable. 
• Definition of done: Task/subtask - Done when the development done and related bugs all fixed ( that is also my confusion, can the task automatically change status of done when all related issues are done? Bugs - pass the test Epic- I just realize some epic is consistant cross sprints, but we have mark it done to end the sprint.. it makes our epic abnormal

case of Epic, I agree with you that it should not have any status.

I think an Epic should have statuses; it has a lifecycle, it is created, it is progressed upon (indirectly), and there would be a point when it has been achieved/delivered. So for simplicity, you could have an Epic lifecycle similar to the below:

TO DO - IN PROGRESS - DONE

• Thank you, Epic includes many storys, I figure that product manager should in charge of this type but the development and testing work are done from tech team, so how to deal with this relationship?

How would you track your Epics? 

• we simply track here. didn't pay much attention on that so far.
• 

Your suggestion are so helpful Danny, thanks again for your kindness help and patient.

[Danny]

Hi @Jessie Li

Needs Review is to inform QC team and Product team that engineers have finished, waiting for review/test. Because some of the tasks require Product team to verify instead of QC(engineers will assign to them directly). PO can change status to DONE or to NEED TO TEST status, they can also reassign to engineers if the result doesn't match their requirement.  So for QC team, they will pull the tickets from NEED REVIEW to TESTING basing on the test progress, they pull them when. 

You are essentially putting a lot of "in between" work on your PO. I would recommend trusting your engineers and QC team to make a decision on when work is ready for them to pick up, e.g: you have 20 issues in NEED TO TEST status but your PO has to confirm where it needs to go therefore you have created a bottleneck for yourself. 

Consider removing the NEED TO TEST status and chanigng to process so that engineers can choose whether to set the status to DONE (negative resolutions only - as it has not gone through a quality pass by the QC team or the engineer can change the status to TESTING and assign it to a QC team member. 

By using the above process you create autonomy without a lack of process. Think about using conditions in transitions so that only certain project roles can transition to certain statues such as a QC member can only transition to DONE form TESTING (with a positive resolution).

Now your PO has a status after TESTING that ensures they sign off, perhaps a status change from TESTING > PO REVIEW > CLOSED. QC member transitions a successful test to PO REVIEW and assigns to PO for sign off. 

Definition of done: Task/subtask - Done when the development done and related bugs all fixed ( that is also my confusion, can the task automatically change status of done when all related issues are done? Bugs - pass the test Epic- I just realize some epic is consistant cross sprints, but we have mark it done to end the sprint.. it makes our epic abnormal

"related bugs all fixed..." so any issue cannot be closed if a related issue is not closed? If that is so then what happens when there is more than one related issue? You are creating another bottleneck for yourself and a cumulative report would identify this as such that your issues take a long time to resolve. For example, a Story could be delivered and DONE though there are Bugs that relate to it. The acceptance criteria of the Story has been delivered though there are outstanding Bugs. 

"can a task automatically change status of done when all related issues are fixed.." Yes is it possible using Jira automation rules OR marketplace apps though I would not recommend this unless the rules are really simple and do not circumvent your delivery process. 

"test Epic" Do you test at the epic level? Why?

Thank you, Epic includes many storys, I figure that product manager should in charge of this type but the development and testing work are done from tech team, so how to deal with this relationship?

The product manager can be in charge of it, yes, but explain it to me. Explain what they need to do during the life cycle of an Epic and when should they do it? What information do they need to provide on an Epic? Or is it someone else that needs to provide information? 

Why does the tech team test at the Epic level or do they test against stories? Could you explain their process to me? 

Hope this helps,

Danny

[Jessie Li]

Now your PO has a status after TESTING that ensures they sign off, perhaps a status change from TESTING > PO REVIEW > CLOSED. QC member transitions a successful test to PO REVIEW and assigns to PO for sign off.  

that is because some tasks doesn't request the QC test

"test Epic" Do you test at the epic level? Why?

Ah, the Epic usually cross sprints.. 

The product manager can be in charge of it, yes, but explain it to me. Explain what they need to do during the life cycle of an Epic and when should they do it? What information do they need to provide on an Epic? Or is it someone else that needs to provide information? 

actually doing nothing.. just for collecting the stories and tasks togather to convenient for the future use of any analysis or others.. Do you have other suggestions?

Thanks, for other points I am not writing here are usefull and we will discuss internally.

Jessie

[Gracjan Wesołowski _HeroCoders_]

Hello @Jessie Li ,

have you thought about using checklist apps that are available in the marketplace?

Checklists allows you to better control some elements of the workflow. 

I suggest you to check it out and see if it could help with your configuration.

Regards,

Gracjan

[Jessie Li]

Thank you Gracjan, I am preparing to use it.