Don’t Use Fake Due Dates in Kanban


Real Due Date

At it-agile we use a Kanban board for acquisition. Once we turned all our tickets on our acquisition Kanban board into fixed delivery date tickets. We wanted to decrease our average lead time by reminding those who where working on the tickets to keep on working. Good intention, bad execution. Here’s why.

At my company we have customer requests like “We’d like you to do a Kanban class” or “Could you help us with developing an iPad app?”. We also have a lot of experts working outside the office most of the time, who answer to such requests. We use a Kanban board to coordinate answering of customer requests. We call it acquisition board. This does not work without problems.

We have a service level agreement for answering the first customer contact. When a customer writes us an email, our team assistants turn the email into a ticket and put it into the ready queue of our acquisiton board. The ticket also gets a due date, which turns it into a fixed delivery date ticket. Now we wait that someone of us pulls that ticket. If it’s not pulled before the due date, our team assistants call the customer and turn down his request by saying that we’re sorry but we actually do not have the capacity to help him.

Now that is what I find a good use of a service level agreement in combination with a due date. So did others in my company, and that’s why they started using due dates for other things than just answering to the first contact. The idea was to decrease our lead time of the whole ticket by having due dates all the time, in all columns. That due date would mean something like “I want to work on that ticket until [due date].” Imagine an acquisition board full of tickets with dates on it – most of them red, indicating that they’re overdue.

Overdue tickets could mean that most of my colleagues pulling those tickets are lazy, uncoordinated or just too busy to keep up working on acquisition, but from a systemic point of view that’s just ridiculous. Maybe it’s because of the due dates all over that it’s not working?

Fixed delivery date tickets are explained by David Anderson in his book Kanban
like this:

“Requests of this nature carried a significant cost of delay, whether direct or indirect … There would be a date when a penalty (or fine) would be incurred … [or] there would be a requirement to cease some activity … This second, indirect cost is a cost of lost opportunity – the potential lost revenue during the period of delay.”

Is there a penalty if we do not answer the first contact of a customer? Nope, it’s legal to do so. Is there lost revenue because of a delay? Sure there is, the customer could be upset if we don’t answer his request in time. Like Henrik Kniberg said, a request is like a bun and when it “comes in it is warm, juicy and soft“, but when you wait too long, you won’t enjoy your bun anymore.

But what happens after the first contact? There’s still no penalty. But there could be a cost of delay (e.g. not calling back for a long time), but there does not necessarily has to be one. Often, we talk to customers for months until everythings settled for a training. Sometimes it’s the customer who needs time (because she is on holiday), and sometimes we need time (because we are on holiday), and very rarely that results in four weeks of silence between me and the customer (my holiday was first, followed by her holiday). In that particular event where I didn’t have contact with the customer for four weeks it still resulted in a good business transaction. So there seems to be no necessity to set an arbitrary due date.

Having said so, arbitrary due dates are well known, not in Kanban, but in the Getting Things Done (GTD) community. GTD is a personal organization method, focused on tasks. The idea is, to organize the tasks externaly so you don’t have to remind yourself all the time on all the stuff you have to deal with. Kanban and GTD have lots of similar ideas; there’s even a Personal Kanban book out there which focusses on similar topics.

In GTD, arbitrary due dates are called false due dates or fake due dates. Chris smith wrote on Lifehack about fake due dates, that they are

“… dates that you set up for actions within a project that are due before the actual due date project. In my experience these types of due dates don’t work. What they tend to do is allow procrastinators procrastinate more, because when they see due dates they push everything back to the last minute.”

Procrastinators procrastinate more? Outch, sounds like increased lead time.

Some time ago I used to put fake due dates on all of my tasks in my personal task list. Shortly afterwards I was highly demotivated. It seemed that I wasn’t able to commit myself to the simplest stuff I planned on doing at a specific date, my fake due date. Turns out, it was not because I was undisciplined, but because I used fake due dates.

“[...] I’ve discovered over time that I have a strange habit of arbitrarily assigning due dates to some tasks, not because they must be completed by then, but because I think they might be or should be. This undermines the trust in my system and adds an unnecessary psychic burden, as tasks without a concrete due date begin to pile up in the “overdue” column. That aint good. The reason I haven’t completed those tasks is because I haven’t had the time or energy to do them. Making them artificially overdue is like being punished for something that’s not my fault. That was an important insight for me, enough to make me open my task list and remove due dates from every task that doesn’t explicitly require one. I feel a lot better already.” (by Todd Mundt)

I felt relieved after I threw all fake due dates away and kept only the real due dates (less than a hand full of them).

In another domain it’s the same: If you use your calendar to mark due dates, you are very likely to end up failing:

“Setting up false due dates will not only clutter your calendar, but will also make you frustrated and possibly even less productive. False due dates are those things that you add to your calendar when you say, ‘well, I think that I should have this part of my project done by this date here,’ and then mark it with your fake due date.
What this does is help you put off tasks that are related to that project until you are closer and closer to the date.
This isn’t to say that there is anything wrong with milestones, but to put a hard date a piece of a project when it isn’t actually do will most likely set you up for failure.” ( Chris Smith on Lifehack )

Well, we’re still struggeling in my company with the fake due dates – but I managed to get of the hook, i.e. the need for me to use due dates on the tickets I pull. I assure you, the flow is back now and I work much better on those tickets.

Don’t use fake due dates in Kanban. They put pressure on you, have you feel unproductive and guilty, and increase your average lead time. Only use real due dates.

This entry was posted in General and tagged , . Bookmark the permalink.

About Bernd Schiffer

Bernd Schiffer is consultant, trainer and coach for Agile Software Development in Melbourne, Australia. Learn more about him on his homepage or contact him on Twitter, Google+, Facebook, XING or LinkedIn.

18 Responses to Don’t Use Fake Due Dates in Kanban

  1. Stefan Roock says:

    For me the dates in the tickets of the acquisition board aren’t due dates but check dates. When the date has come I should check again status with the customer to stay in touch. Perhaps it is just a wording problem?

    • I experienced that differently. If it were a check date, it would mean something like “From the [check date] on I contact the customer again. It doesn’t matter if I do this exactly on the [check date], as long as I don’t do it before the [check date].” That not the case with our due dates. A week before the due date, the date turns into yellow, indicating approaching cost of delay. From the day of the due date, the date turns into red, indicating a serious problem. Pressure on all levels occure, ones a due date turns red. That’s not something I’d see with a check date.

  2. Hi,

    my second comment on this, WP killed the first one :-/

    Kanban did its duty, I guess. The solution is – as always – outside the Kanban and Kanban simply made it explicit. You guys modeled an approach into a Kanban board and either it does not work or is not explicit enough. Before Stefan posting, I was sure it wouldn’t work for a certain reason but now I’m not sure anymore.

    Let’s assume it could work and there is the wording issue that Stefan mentions. Then do a quick retrospective, get your senses together, make the approach more explicit by clarifying the wording and off you go.

    But still, I am afraid, the issue lies deeper. I guess you are not aligned on the underlying model of ‘How to treat customer requests’. The technical term that Bernd brings in is SLA. But I think it is still deeper. I think there are different expectations in the room as how to treat those requests and you need to discuss it and then commit to one way, which then can be modeled as work item types, classes of service, whatever fits the outcome of the discussion.

    If this will work with the capacity you have and if the process will work at all, will show the application of the next iteration of the Kanban board. If i were you I would come up with explicit expectations on the next level of achievement of the new approach as kind of a target condition, even if you don’t have a clue how to achieve it.

    But as I tweeted before, the whole issue is completely out of the scope of Kanban and Kanban is one many tools which would make this issue explicit. I guess this issue is so obvious that in fact any tool would make it explicit ;)

    Cheers

    Markus

    • Don’t agree with you that this is “completey out of the scope of Kanban”. Fixed delivery date tickets are part of Kanban, and they have due dates. Due dates can be faked, and it happens, not only on our board, but I’ve seen that on customer’s boards, too. For me, faked due dates are related to Kanban. And maybe it’s obvious for you, but there are lots of folks out there for whom it’s not obvious – including me short time ago :)

      I agree with you that we need to discuss it – in fact, we’re doing that a lot – and come up with new ideas on how to solve the issue.

      • Arne Roock says:

        I agree with Stefan: There´s confusion on the meaning of due dates here. As you mentioned in your post, we do not really have fixed date tickets on our board (as described as a class of service by David). But we´re using a feature of our tool that is designed for such fixed date tickets. From this “feature abuse” you seem to reason that we´re dealing with fake due dates. They´re no due dates. And they´re no fale due dates. They are check dates (as Stefan said). And I find them useful.

        • Hm, maybe I miss something. What’s the difference for you between a due date, a check date and a fake dute date?

          • Arne Roock says:

            You´re quoting Smith “dates that you set up for actions within a project that are due before the actual due date project”.
            That seem to be due dates for you, right? In our context, there are no “actual due dates”. So how can there be “fake due dates”?

            BTW: I just set my alarm clock for 7pm for tomorrow morning. Because I think it´s a reasonable time to get up. Would you consider this a fake due date and thereful harmful?

          • Markus Andrezak says:

            7am IS harmful but no (fake) due date.

  3. Your recommendation thingy is really annoying :-/

    On the iPad is hovers above all the important real estate, here on the Mac it is irritating while reading and writing. Zero added value, way too much distraction. And I can’t even get completely rid of it, I can only make it smaller :-(

    I even tried hitting the question mark. It informed me I can opt out of the recommendations. Guess what – after checking the opt-out, it just stalls and I can’t save my preference. Could be done by MS in it’s worst days …

    Cheers

    Markus

    • Thanks for the feedback. I’m still trying it out and I track the conversation rate. Will keep your in mind for a (later) decision on this. Will also report that the opt-out doesn’t work. Sorry for the annoyance.

  4. Bang, there it goes again :-/

  5. As I learned from Jerry Weinberg, fake due dates are not the problem, rather our reaction to fake dates (or the information that they reveal, as Markus put it). To explain that, I will explain how I use the dates, and why it’s working for me – to some degree.

    When I start working on a ticket, I set a target date, i.e. when I would like to work on the next step in process. I take a look in my calendar to check for a reasonable date, and maybe add a buffer if that date could turn out likely to be too optimistic. When I have a home office day, I take a look on the board, start my todo list for the day, and get going.

    Sure, I have forgotten one or teo tickets over the course. And I learned from it. When I am certain to have a tight schedule, I add a day or two when I feel comfortable to be working on that ticket.

    That said, I acknowledge that this system appears to work fine for me (until now), and I recognize others who feel unfomfortable wih it. So, rather than demanding a process for everyone (no fake due dates, no due dates at all, everything has a due date), I recognize the differences in our working, and appreciate the process of others. I think this is a good way to cope with the situation.

  6. After lots of hard thinking ;), I came to the conclusion that you simply designed a Wiedervorlage system, in which you still have to decide on what is happening with different types of outcome. No?

    • It would still be a Wiedervorlage system (I think the English term is follow-up system) without any (fake) due dates, wouldn’t it? I mean, every visualization with a Kanban board reflects the system’s state all the time – it’s not a follow up, it’s a persistent or permanent system. Why would I have to put due dates on those tickets, if they are visible all the time anyway?

      • Markus Andrezak says:

        I thought we are way beyond the due date discussion. They are none to anybody. And I’m only rephrasing the discussion. The dates are simply an indication for you guys to be able to coordinate the stuff in your schedules with some slack.

        And yes, it is a follow-up system invariant of if these are due dates, fake due dates or … muffins.

  7. @Arne: Due tue threading limitations, I’ll reply here.

    You wrote: “You´re quoting Smith ‘dates that you set up for actions within a project that are due before the actual due date project’. That seem to be due dates for you, right? In our context, there are no ‘actual due dates’. So how can there be ‘fake due dates’?”

    I think it’s bad to have fake due dates before an actual due date, and I think it’s even worse to have fake due dates without any actual due date.

    You wrote: “BTW: I just set my alarm clock for 7pm for tomorrow morning. Because I think it´s a reasonable time to get up. Would you consider this a fake due date and thereful harmful?”

    A fake due date is an appointment with a task without the need of that appointment. For me, getting up is not related to a specific task. If it were, I’d consider that a fake due date.

  8. Markus Andrezak says:

    I guess I simply don’t get the point you want to make :(

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *