Many teams adopting Kanban come from Agile background. Agile thinking has discouraged the use of Due Dates. Due Dates breed undesirable behavior. Focus on Due Dates results in teams working under significant pressure. Quite often, that translates into short cuts in Design/Testing activities. The net effect is that work quality is compromised and technical debt piles up.
That said, Agile methodologies inherently have a Due Date. This is the Sprint end date. The team has a clear expectation that the planned scope of the Sprint needs to be completed by the end date of the Sprint. Someone has gone through the process of mapping the Sprint capacity with the story points that is planned in that Sprint. Yes, some requirements may spill over to the next sprint but that is generally a small % of the overall Sprint scope.
In contrast, Kanban systems, being flow centric, take away the pressure of the Sprint date. The question is: should such teams, if they have not been using Due Dates, consider using Due Dates on their cards/work items?
While project teams are expected to be self-organizing and self-driven, absence of due dates tends to loss of momentum within the team. Parkinson Law takes over. A 5 days work can stretch to 7 days when no expectation is set to the respective developer of a 5 day development timeline. For projects that work on fixed budgets, such slippage can soon pile up and cause management escalation.
There are other benefits too. Due dates can help team members working on different user stories belonging to the same MMF align their completion date. If you want to get something done by an intermediate milestone (like a customer demo date), Due Date can focus the participating team members to that immediate milestone. I have also experienced that a mismatch in Due Date expectation between the developer and others in the team, corrects a requirement/implementation disconnect between team members. User Stories aren’t a detailed spec.
Once again, one is not talking about going back to the old ways – wherein Due Date becomes a deadline cast in stone and quality/technical debt becomes a secondary consideration.
The next question comes is – where does the Due Date come from? Agile/Kanban systems discourage detailed estimation. Nevertheless, estimates do often exist. In IT service companies, projects are estimated and bid for in the pre-sales lifecycle. Those estimates are inherited by the development team, though often not the same level of granularity. In cases where estimates don’t exist, a simple T-shirt size categorization is adequate to communicate whether a particular card should be completed in 1 week or 2 weeks.
In summary, we need balance! Agile teams advocated against Due Dates because it used to drive wrong behavior. On the other hand, complete absence of a Due Date can lead to team throughput coming down. My recommendation to teams is to use Due Dates with Kanban Cards but ONLY as a guideline – not as something that will make the team compromise product quality and add to technical debt.
I would like to hear about your experience with the use of Due Dates in Kanban systems.