No matter how the work is scheduled, your best-case one-piece-flow cycle
time is a lower bound.

If a deadline falls within the normal variation of lead time, then you
can mark the date on the kanban and schedule it in the usual way.

Otherwise, there are a couple of expediting strategies you might apply
to time critical tasks. The lesser is to jump to the head of the input
queue and then be treated like a normal ticket. The greater is the
"silver bullet" expedited kanban:

http://finance.groups.yahoo.com/group/kanbandev/message/68

Beyond that, any single work request is subject to the same kind of
"cone of uncertainty" as any other software estimation. Kanban smooths
out the aggregate, but the individual work request may still vary
widely. Parallel/redundant (i.e. set-based) work requests can further
smooth out scheduling uncertainty, at the cost of some...redundancy.

Corey


Martin Schapendonk wrote:
>
> Hi all,
>
> I like the idea of a kanban system, especially in the 'sustained
> engineering' context, as discussed on this list. I haven't tried it in
> practice, and I still have some questions.
>
> Suppose a change request has serious legal consequences if it hasn't
> been implemented by date X. How does a kanban software development
> team handle such a request? As I understand it, a request enters the
> first queue and every 'station' along the way tries to deliver as soon
> as possible.
>
> But how do I know (or how can the team commit) that 'as soon as
> possible' is soon enough to meet date X?
>
> Regards,
> Martin
>
> --
> Martin Schapendonk, http://www.schapendonk.org/blog/
> <http://www.schapendonk.org/blog/>
>
>