What is the best practice in terms of moving stories/tasks through the workflow. Should stories be allowed to move back in the workflow e.g. In Deployment to In Development; In Development to To Do.
My current employer does not support this however at my previous employer it was acceptable.
Absolutely. Kanban is not a straight jacket limiting you to only one way of doing things.
Kanban is a visual representation of the actual workflow. In hardware it can be pretty obvious as you're moving around a physical object. If a car fails quality inspection, it doesn't sit in the quality bay waiting for an engineer to come to it. It gets sent back to where the work needs to happen.
If QA finds a bunch of issues with a completed piece of software, they send it back to development. If it stays in QA, it limits QA's work in progress limits. Only QA isn't working on it anymore.
And moving something even as far back as To Do is a recognition that you can't work on it right now. Maybe a dependency popped up and you have to wait a month for that to be complete.
Now I do recommend a "Waiting" column on your task flow. If you are waiting for an outside dependency, which is within a reasonable time, then toss it in waiting. It shows it is being worked on, but not actively. Things in waiting would not count again the WIP limit for "Doing". I still put a WIP on "Waiting" if you exceed that WIP, then you start raising risks.
Moving stories/tasks back is an important part of the process.
We want our workflows to reflect reality as much as possible. This is useful as it highlights any issues that the team needs to address.
As an example, if the team is seeing deployments failing and stories moving regularly back to development then they should discuss this at their retrospectives and try and better understand what is going on.
I’d say no. The car in the production line gets inspected in the bay it is being built. When it doesn’t pass quality control, it stays there, and continues to get worked on. It doesn’t leave the paint booth, until it’s passed paint quality control. Why, because you cannot physically move the car backward, there’s another car already in there.
You need to think of your definition of done for the phase you are in. Unit testing and smoke testing should be done by a developer, as well as peer review. This happens in development. Where the tester finds quality issues, defects are raised, and the ticket is out in a waiting state until those defects are resolved, or if those defects are trivial and can be accepted for a production release, the product is released, with the defects to be attended to when needed.
If you don’t do this, you hide rework, and make it difficult to track team effectiveness. It also allows for jobs to suffer from scope creep as they stay in the workflow longer than needed.
I’d suggest avoiding moving jobs backward, and instead instilling explicit policies around the definition of done for each phase of your workflow, and use defects to make it transparent when issues are detected.
I believe that moving items backwards simply masks the true issue. If a bug is found in QA, why not simply allow the work item to remain in QA until the bug is resolved? Whether you add a separate bug card or include the details of the issue in the original story, I find it best to allow the card to remain in the QA/Test column. The longer the card languishes there, the more visibility you have that there is a problem. The very purpose of the board is to shine a light on your bottlenecks, issues, etc.
