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)
0 Comments
Hi Sudi- You have a very good thought here. Due dates are really helpful
in getting the team a feeler of how they have organized their work and a
blueprint of their execution. Due dates should not be imposed on the
team, but they will be very helpful to the team to track their progress
and make corrections as they go.
However, looks like Rally does not
have due dates are phase level. Possible phases could be design,
develop, test & accept. Due dates are there at tasks level though.
Regards,
Srini.
In Kanban a due date should really be for true deadlines meaning “this cannot be delivered past this date.” Give the people the power of due dates and watch the abuse happen and defeat the purpose of flow in the Kanban system. Often you find due dates calculated with leg room b/c you want to be really sure that you meet the deadline. Now the due date becomes a week earlier just to make sure it is met. Ever invited someone to an event and told them an earlier time because you know they are always late?
Enter class of service “fixed delivery date” which has a mandatory due date. Fixed delivery date is all you need and that becomes a class of service with a pull policy based on priorities. These item include regulatory, annual or semi-annual processes, perhaps quarterly cadences, hard deadline of a product beta launch, or promises to clients (even those are re-negotiable). The team can analyze fixed delivery items and determine when to pull them based on the due date, otherwise continue pulling other items in other classes of service.
In conclusion I would argue that due dates only exist due to the lack of continuous flow in a Kanban system. One doesn’t trust the flow of the system or there is no capacity so he or she will place a due date to trick the pull policies. Otherwise standard class of service with visibility on cycle time to understand generally when it will be done should suffice.