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, specifically Scrum, inherently have a Due Date. Most often, 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.
So, the Sprint end date serves as a reasonable reminder to the team that they need to complete their work by then. In spite of the issues mentioned earlier, Due dates can help team members working on different user stories belonging to the same MMF align their completion date. If something needs to be done by an intermediate milestone (like a customer demo date), Due Date can focus the participating team members to that milestone.
In contrast to Scrum, Kanban systems, being flow centric, take away the pressure of the Sprint date. The question is: should teams that are used to Due Dates, consider using them on the cards/work items on their Kanban board?
While project teams are expected to be self-organizing and self-driven, the reality might be quite different; and the absence of Due Dates can cause loss of momentum within the team. Parkinson Law takes over. 5 days of work can easily stretch to 7 days when no expectation is set with the developer of a 5-day deadline. For projects that work on fixed budgets, such slippage can soon pile up and cause management escalation.
So, in many situations, use of a Due Date at the card or task level becomes useful. One is not talking about going back to the old ways – wherein the Due Date becomes a deadline cast in stone and quality/ technical debt become a secondary consideration. It’s used as a simple guideline to the team member to complete a card/ task can be useful.
The next question comes is – how does one set the Due Date?
The typical approach to this has been estimation. Agile/ Kanban systems discourage detailed estimation in hours but story point estimates are used a lot and even hours estimates often do 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. Pre-sales estimates are expanded to more detailed estimates at execution time.
In Kanban systems, a simple T-shirt sizing approach is usually adopted to communicate whether a particular card should be completed in 1 week or 2 weeks. So, in general, teams have a sense of the co-relation between size (in story points or T-shirt sizing or hours) and the amount of elapsed time it would take them to do it. That determines the Due Date.
Kanban systems also have the added advantage of focusing on lead time and cycle time data, with statistical distribution charts that enable the team to make commitments at various levels (release, sprint or card level) with a certain level of confidence. So, after establishing some amount of historical data, teams using Kanban can effectively use Due Dates to provide guidance to team members or visibility to customers/ stakeholders.
In summary, we need balance! Agile teams advocated against Due Dates because they tend to drive wrong behavior and subvert quality. On the other hand, an absence of Due Dates can lead some teams’ throughput to drop. While estimates driven Due Dates can work well, Kanban systems provide additional help to teams to determine more realistic Due Dates. My recommendation to such 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.
Other Blog posts you might be interested in:
Turbocharge your Personal Kanban with GTD (Getting Things Done)