Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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.
