Does Kanban require that there is a Definition of Done for each state the work/item flows through?
When a card moves through the different columns or states on a Kanban board, does each column have to have a specific Definition of Done. Is there anything out there that states that such a requirement is needed? or could we just have one Definition of Done that can be used to inspect the work that reaches the final column?
If this wasn't defined and universally understood, how might it impact the flow of work when another team member is ready to pull it into their queue?
The Definition of Done should guide both per my understanding. Do we need a DoD for each column? wouldn't that be unnecessary overhead?
I agree an overarching Definition of Done that may hit multiple states of the flow would be needed to describe whether a work item is releasable and able to be moved to the 'Done' column.
There may also be cases where the team would want to describe in more granular detail what 'Done' is for each state (or queue) in the process.
I'd think the overhead incurred in doing this would ultimately be less than any rework, meetings, or missed communication that could result from not having a clear understand of what's required for work to flow through each state.
Do we need a DoD for each column?
It can be wise to have explicit policies for pulling work from one station to another. Inspection and adaptation may then occur in as timely a manner as possible. Each of those policies could perhaps be thought of as asserting a certain level of Done.
Normally, DoD contains test descriptions or acceptance criteria, so it should be in one column (Testing column or Verify column ....)
I think all the policies for pulling work from one station to another combined can be looked as as the Definition of Done.
So Yes, I think you can look it at as 1 Definition of Done but different parts of it are spread out to different transitions on the KanBan board.
You might even want to add a Definition of Ready to the thought above, depending on the configuration of you KanBan board.
To answer your initial question, the Scrum with KanBan guide says:
Visualization should include the following:
....
Explicit policies about how work flows through each state (which may include items from a Scrum Team’s definition of “Done” and pull policies between stages).
....
I think all the policies for pulling work from one station to another combined can be looked as as the Definition of Done.
@Eric Hoogers, This was pretty much my thought process when I posted the question
@Ian Mitchell, If implementing Scrum with Kanban, why would we want to make separate policies for each station? In Scrum, we only use one DoD that guides the entire Dev Team, so why not in the case of Scrum with Kanban or just Kanban too?
If implementing Scrum with Kanban, why would we want to make separate policies for each station? In Scrum, we only use one DoD that guides the entire Dev Team, so why not in the case of Scrum with Kanban or just Kanban too?
Might the early application of Done help to promote timely intervention and the minimization of waste?
The Kanban Guide for Scrum Teams says:
"The board's configuration should prompt the right conversations at the right time and proactively suggest opportunities for improvement.
"Visualization should include the following:
...
"Explicit policies about how work flows through each state (which may include items from a Scrum Team’s definition of 'Done' and pull policies between stages)."
+ It makes your flow more transparant
Might the early application of Done help to promote timely intervention and the minimization of waste?
The Kanban Guide for Scrum Teams says:
"The board's configuration should prompt the right conversations at the right time and proactively suggest opportunities for improvement.
"Visualization should include the following:
...
"Explicit policies about how work flows through each state (which may include items from a Scrum Team’s definition of 'Done' and pull policies between stages)."
@Ian Mitchell, Considering if we're not changing Scrum, then how I am understanding this is that the policies at each stage should suffice the requirement for a DoD. If not, should the understanding be that in addition to the policies at each stage, there should also be an overarching DoD?
In the context we're discuss now..I look at the overarching DoD as the quality standards that the final increment must meet to be release worthy by the time it flows through the entire process. This could be pulled from multiple states but would sit at more of a macro level.
I view the agreements between states at more of a micro level. Perhaps the team members put in place certain policies that they use to consider done for transition between states that aren't required for the overarching DoD.
Here's a basic example of how I think about it... I'm working with some team's now that have a hand off from a vendor QA to business functional testing. The DoD states these PBI's must pass per the acceptance criteria. The pull policies between the two groups state the vendor QA must assign the work to the business and provide their test cases upon completion. The pull policies are not necessary for the overarching DoD to be met but they allow for a smoother flow of work because the business can pick it up and run with it quickly.
I am also looking at this from the perspective that if a team was using Scrum without Kanban, they may have a DoD that addresses both the quality aspects as well as the development, testing and all other aspects that would help assess the "Done"-ness of the Increment.
If such a team decided to now start using Kanban with their existing practice of Scrum, does it mean this team would now have to breakdown their DoD to match each state/column? Would that not be unnecessary overhead? If the team could deliver Done Increments prior to the use of Kanban by referring to the original DoD, can't the same apply even if Kanban is introduced?
Ah I see.
If their current DoD is working for them I'd agree it doesn't make sense to necessarily break it down at this point.
Personally, I'd say leave it 'as is' and decide later through inspection if the team finds they need any more specific pull policies from state to state as they move forward.
Considering if we're not changing Scrum, then how I am understanding this is that the policies at each stage should suffice the requirement for a DoD. If not, should the understanding be that in addition to the policies at each stage, there should also be an overarching DoD?
Scrum makes no prescription either way. Kanban policies may suffice or there may be an overarching DoD. What matters is that everybody is clear about what Done means.
From a Kanban perspective, what matters is that the policies expressed by a DoD are explicit in the workflow. If an "overarching" DoD reduced transparency over these policies, and where in the workflow they apply, then there would be an issue.
What matters is that everybody is clear about what Done means.
Completely agree on this one.