Skip to main content
Project Management

Return to Answer

I wanted to elaborate that with keeping the the task in QA lane will reduce handoffs and that one of the issues could be that implementor didn't made enough effort into testing the task in the first place
Source Link
RenatoIvancic
RenatoIvancic
  • 101
  • 3

I strongly agree with the approach to keep task in QA/Review column. From multiple viewpoints:

  • Priority - Tasks on the right side should be more important. More attention from the team to finish it. If in QA (maybe marked as blocked) this should be resolved before any new ticket is being worked on. Knowledge will still be fresh. If necessary swarm, pair program.
  • Simplicity - Process is easier to follow. You can measure the time of the tasks that are in the QA lane instead of measuring how many times task moved back from QA -> DEV. From the First Way of DevOps, reduce handoffs.
  • Collaboration - When the task is in QA lane I expect higher collaboration between QA and Development members if this is the case in the team.

Learning and improving - IMHO its crucial to strive for 0 rework needed. Reflect on why it happened in the first place:

  • Missing requirements?
  • Not enough analysis upfront
  • Missing experience
  • Lack of collaboration with PO/QA
  • Lacking the tooling to properly test functionality locally.
  • Not enough testing efforts from implementors

Can you improve the process with:

  • Pair programming during the development process?
  • Spending more time on defining requirements with happy path and multiple edge cases
  • Do you need to improve test data
  • You need explicit DoD in place?

I strongly agree with the approach to keep task in QA/Review column. From multiple viewpoints:

  • Priority - Tasks on the right side should be more important. More attention from the team to finish it. If in QA (maybe marked as blocked) this should be resolved before any new ticket is being worked on. Knowledge will still be fresh. If necessary swarm, pair program.
  • Simplicity - Process is easier to follow. You can measure the time of the tasks that are in the QA lane instead of measuring how many times task moved back from QA -> DEV.
  • Collaboration - When the task is in QA lane I expect higher collaboration between QA and Development members if this is the case in the team.

Learning and improving - IMHO its crucial to strive for 0 rework needed. Reflect on why it happened in the first place:

  • Missing requirements?
  • Not enough analysis upfront
  • Missing experience
  • Lack of collaboration with PO/QA
  • Lacking the tooling to properly test functionality locally.

Can you improve the process with:

  • Pair programming during the development process?
  • Spending more time on defining requirements with happy path and multiple edge cases
  • Do you need to improve test data
  • You need explicit DoD in place?

I strongly agree with the approach to keep task in QA/Review column. From multiple viewpoints:

  • Priority - Tasks on the right side should be more important. More attention from the team to finish it. If in QA (maybe marked as blocked) this should be resolved before any new ticket is being worked on. Knowledge will still be fresh. If necessary swarm, pair program.
  • Simplicity - Process is easier to follow. You can measure the time of the tasks that are in the QA lane instead of measuring how many times task moved back from QA -> DEV. From the First Way of DevOps, reduce handoffs.
  • Collaboration - When the task is in QA lane I expect higher collaboration between QA and Development members if this is the case in the team.

Learning and improving - IMHO its crucial to strive for 0 rework needed. Reflect on why it happened in the first place:

  • Missing requirements?
  • Not enough analysis upfront
  • Missing experience
  • Lack of collaboration with PO/QA
  • Lacking the tooling to properly test functionality locally.
  • Not enough testing efforts from implementors

Can you improve the process with:

  • Pair programming during the development process?
  • Spending more time on defining requirements with happy path and multiple edge cases
  • Do you need to improve test data
  • You need explicit DoD in place?
Source Link
RenatoIvancic
RenatoIvancic
  • 101
  • 3

I strongly agree with the approach to keep task in QA/Review column. From multiple viewpoints:

  • Priority - Tasks on the right side should be more important. More attention from the team to finish it. If in QA (maybe marked as blocked) this should be resolved before any new ticket is being worked on. Knowledge will still be fresh. If necessary swarm, pair program.
  • Simplicity - Process is easier to follow. You can measure the time of the tasks that are in the QA lane instead of measuring how many times task moved back from QA -> DEV.
  • Collaboration - When the task is in QA lane I expect higher collaboration between QA and Development members if this is the case in the team.

Learning and improving - IMHO its crucial to strive for 0 rework needed. Reflect on why it happened in the first place:

  • Missing requirements?
  • Not enough analysis upfront
  • Missing experience
  • Lack of collaboration with PO/QA
  • Lacking the tooling to properly test functionality locally.

Can you improve the process with:

  • Pair programming during the development process?
  • Spending more time on defining requirements with happy path and multiple edge cases
  • Do you need to improve test data
  • You need explicit DoD in place?