Loading ...
Sorry, an error occurred while loading the content.
 

Re: [kanbandev] How to handle strict deadlines in a kanban?

Expand Messages
  • Corey Ladas
    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,
    Message 1 of 11 , Jan 31, 2008
      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/>
      >
      >
    • Martin Schapendonk
      OK, sounds good. As you mentioned, work requests can vary greatly in size. When does a kanban team estimate the size of a work request? Is any effort spend on
      Message 2 of 11 , Feb 1, 2008
        OK, sounds good.

        As you mentioned, work requests can vary greatly in size. When does a
        kanban team estimate the size of a work request? Is any effort spend
        on estimating the expected lead time for a specific work request?

        Martin

        On 1/31/08, Corey Ladas <coreyl@...> wrote:
        > 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/>
        > >
        > >
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >


        --
        Martin Schapendonk, http://www.schapendonk.org/blog/
      • Landes Eric (CI/AMM1-NA)
        Not sure if this is helpful Martin, but we are trying to estimate each work item using a point system. This is more to help the team understand work in the
        Message 3 of 11 , Feb 1, 2008
          Not sure if this is helpful Martin, but we are trying to estimate each work item using a point system.  This is more to help the team understand work in the queue and over time, we can report back to upper management on what's actually in the queue.  For these items our team does planning poker.  But for us, since we do a FIFO process to select from our backlog, the estimation is more for management reporting than for the developers. 
           
          Eric Landes
           


          From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On Behalf Of Martin Schapendonk
          Sent: Friday, February 01, 2008 4:11 AM
          To: kanbandev@yahoogroups.com
          Subject: Re: [kanbandev] How to handle strict deadlines in a kanban?

          OK, sounds good.

          As you mentioned, work requests can vary greatly in size. When does a
          kanban team estimate the size of a work request? Is any effort spend
          on estimating the expected lead time for a specific work request?

          Martin

          On 1/31/08, Corey Ladas <coreyl@...> wrote:
          > 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.schapend onk.org/blog/
          > > <http://www.schapend onk.org/blog/>
          > >
          > >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >

          --
          Martin Schapendonk, http://www.schapend onk.org/blog/

        • Martin Schapendonk
          Eric, thanks for your comments. I m familiar with the point system and planning poker. But, I know it in relation to Scrum, with fixed sprint length. IMHO,
          Message 4 of 11 , Feb 1, 2008
            Eric, thanks for your comments.

            I'm familiar with the point system and planning poker. But, I know it
            in relation to Scrum, with fixed sprint length. IMHO, such a system
            has a bigger need for estimates, to determine if something fits within
            a sprint.

            A kanban system has no iterations and a work request can be any size.
            There is no real need to see if it fits, because if it can be worked
            on, it can be put in the queue (or did I misinterpret something?).

            Do you use point value to estimate lead time? E.g. a kanban estimated
            10 points will take us (estimate! average!) 20 days and 15 points will
            take us 30 days?

            What do you answer (based on what information) when the business asks
            "what's the planning, when do I get it"?

            Martin

            On 2/1/08, Landes Eric (CI/AMM1-NA) <eric.landes@...> wrote:
            >
            >
            > Not sure if this is helpful Martin, but we are trying to estimate each work item using a point system. This is more to help the team understand work in the queue and over time, we can report back to upper management on what's actually in the queue. For these items our team does planning poker. But for us, since we do a FIFO process to select from our backlog, the estimation is more for management reporting than for the developers.
            >
            > Eric Landes
            >
            >
            >
            >
            > ________________________________
            From: kanbandev@yahoogroups.com
            [mailto:kanbandev@yahoogroups.com] On Behalf Of Martin Schapendonk
            > Sent: Friday, February 01, 2008 4:11 AM
            > To: kanbandev@yahoogroups.com
            > Subject: Re: [kanbandev] How to handle strict deadlines in a kanban?
            >
            >
            >
            >
            >
            >
            > OK, sounds good.
            >
            > As you mentioned, work requests can vary greatly in size. When does a
            > kanban team estimate the size of a work request? Is any effort spend
            > on estimating the expected lead time for a specific work request?
            >
            > Martin
            >
            > On 1/31/08, Corey Ladas <coreyl@...> wrote:
            > > 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/>
            > > >
            > > >
            > >
            > >
            > >
            > >
            > > Yahoo! Groups Links
            > >
            > >
            > >
            > >
            >
            > --
            > Martin Schapendonk, http://www.schapendonk.org/blog/
            >
            >
            >



            --
            Martin Schapendonk, http://www.schapendonk.org/blog/
          • Corey Ladas
            Hello Martin, There are a couple of schools of thought about estimation. Each has its own +/-. 1. Threshold + kanban limit Work-in-process is limited
            Message 5 of 11 , Feb 1, 2008
              Hello Martin,

              There are a couple of schools of thought about estimation.  Each has its own +/-. 

              1. Threshold + kanban limit

              Work-in-process is limited according to the number of tickets on the board.  This means that the tickets should be of comparable size.  Estimation is considered a non-value-adding activity and should be minimized.  The outcome of estimation is a simple judgement of too-big/not-too-big to deliver within the current trailing lead time.

              2. Delphi + point limit

              Incoming work requests have too much variation in size to treat uniformly, so estimates are necessary to match work to capacity.  Work-in-process is limited to a number of [story|function] points per workflow state.  So, if you have a WIP limit of 9 for "UI Design", then you might have one 9-point kanban, or three 3-point kanban, or nine 1-point kanban, etc.

              3. Time-boxed analysis + kanban limit

              Estimation is a non-value-adding activity and should be eliminated.  Historical proxy-based estimates will appear as a side-effect of analysis.  The goal of analysis is to produce downstream work requests of a similar size.  Analysis is given a fixed time to decompose a work request.  Analysis products that are of the right size progress to the next state.  Analysis products that are too large are reinserted in the input queue.

              Corey


              --- In kanbandev@yahoogroups.com, "Martin Schapendonk" <martin@...> wrote:
              >
              > Eric, thanks for your comments.
              >
              > I'm familiar with the point system and planning poker. But, I know it
              > in relation to Scrum, with fixed sprint length. IMHO, such a system
              > has a bigger need for estimates, to determine if something fits within
              > a sprint.
              >
              > A kanban system has no iterations and a work request can be any size.
              > There is no real need to see if it fits, because if it can be worked
              > on, it can be put in the queue (or did I misinterpret something?).
              >
              > Do you use point value to estimate lead time? E.g. a kanban estimated
              > 10 points will take us (estimate! average!) 20 days and 15 points will
              > take us 30 days?
              >
              > What do you answer (based on what information) when the business asks
              > "what's the planning, when do I get it"?
              >
              > Martin
              >
              > On 2/1/08, Landes Eric (CI/AMM1-NA) eric.landes@... wrote:
              > >
              > >
              > > Not sure if this is helpful Martin, but we are trying to estimate each work item using a point system. This is more to help the team understand work in the queue and over time, we can report back to upper management on what's actually in the queue. For these items our team does planning poker. But for us, since we do a FIFO process to select from our backlog, the estimation is more for management reporting than for the developers.
              > >
              > > Eric Landes
              > >
              > >
              > >
              > >
              > > ________________________________
              > From: kanbandev@yahoogroups.com
              > [mailto:kanbandev@yahoogroups.com] On Behalf Of Martin Schapendonk
              > > Sent: Friday, February 01, 2008 4:11 AM
              > > To: kanbandev@yahoogroups.com
              > > Subject: Re: [kanbandev] How to handle strict deadlines in a kanban?
              > >
              > >
              > >
              > >
              > >
              > >
              > > OK, sounds good.
              > >
              > > As you mentioned, work requests can vary greatly in size. When does a
              > > kanban team estimate the size of a work request? Is any effort spend
              > > on estimating the expected lead time for a specific work request?
              > >
              > > Martin
              > >
              > > On 1/31/08, Corey Ladas coreyl@... wrote:
              > > > 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/>
              > > > >
              > > > >
              > > >
              > > >
              > > >
              > > >
              > > > Yahoo! Groups Links
              > > >
              > > >
              > > >
              > > >
              > >
              > > --
              > > Martin Schapendonk, http://www.schapendonk.org/blog/
              > >
              > >
              > >
              >
              >
              >
              > --
              > Martin Schapendonk, http://www.schapendonk.org/blog/
              >
            • Chris Matts
              Hi Martin The great thing about the situation you describe is that you know the date that the system needs to be delivered into production on. This falls into
              Message 6 of 11 , Feb 1, 2008
                Hi Martin
                 
                The great thing about the situation you describe is that you know the date that the system needs to be delivered into production on. This falls into the Real Option sweet spot. Work back from that date and put a reasonable estimate for the work involved,
                 
                If the delivery is critical, you want to make sure you understand all the things you need to build and the lead time. This is a where a light skim analysis is needed to give you a rough ideal of the scale and also when certain things need to be done by. Obviously some things may be needed a long time before the main delivery. An example from my past is Basle 2. Investment Banking regulators love their rules and reports. They introduced a new directive called Basle 2. Five years before it came into force my team did a few days work to re-architect the entire credit process of the bank. Our key discovery was that the best approach required a history of internal rating information. Several years before the main development started, we knocked together a database to store the rating information. It was obviously refactored when the app to use it came along but we made sure the info we needed was captured. The few days architecture work was shelved ready to be dusted off years later when we knew we had to start. Rumour has it a couple of banks missed this requirement and must build up the history before they can start using the best treatment...... The real option approach is that up-front analysis adds value by generating information before it would otherwise arrive. The requirements spec and all that guff add no value. We did the up front on Basle 2 because 5 years earlier the industry was wrong footed by Basle 1 ( The Capital Adequacy Directive ).
                 
                For estimation, the best work I've seen is Todd Little's IEEE paper ( http://www.toddlittleweb.com/Papers/Little%20Cone%20of%20Uncertainty.pdf ). In effect, if you want 90% certainty of delivery, then give your self 4 times the original estimate. i.e. do not leave it until the last moment. When estimating, people often focus on effort rather than elapsed time. Even if you are running a top Kanban system, there is allways the risk that your team win the lottery and fail to turn up on Monday....
                 
                The model I use all the while to help the business focus on the importance of features in a mission critical delivery is the Niel Nickeliesen model.
                 
                It just so happens that Niel and Todd will be presenting at the Dallas APLN summit later this month. http://apln.org/summits.html
                 
                So if you want to meet and discuss with Niel, Todd, myself... and the even more excellent David, get on down to Cowboy country in a few weeks time.
                 
                Chris
                On Jan 31, 2008 7:19 AM, Martin Schapendonk <martin@...> 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/




                --
                Regards

                Chris Matts
              • David J Anderson
                Adding to the general thread (having read all the posts)... It s worth mentioning that if the request is really urgent the expedite (or silver bullet)
                Message 7 of 11 , Feb 1, 2008
                  Adding to the general thread (having read all the posts)...

                  It's worth mentioning that if the request is really urgent the
                  "expedite" (or silver bullet) processing time can be much shorter than
                  the typical lead time numbers.

                  However, we don't want to be expediting too much or at all. But worth
                  keeping up your sleeve. If something has a hard delivery date and that
                  date is soon, then expedite it.

                  As Chris Matts suggests, if something has a hard date but it is
                  farther out and the cost of failure to hit the date is high then you
                  need to introduce it to the kanban system early enough to be confident
                  it will be complete before the required date.

                  The choice of when to put it in the system is heavily dependent on
                  cost of failure. I really need to write a lot more on this topic as
                  its been on my mind a lot recently and features heavily in my keynote
                  speech in Sweden next week. Look out for some blog posts on this topic
                  later this month.

                  David

                  --- In kanbandev@yahoogroups.com, "Martin Schapendonk" <martin@...> 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/
                  >
                • Martin Schapendonk
                  Everybody thanks for the valuable comments. Although it does sound interesting, I won t have the opportunity to visit Dallas in a few weeks time (The
                  Message 8 of 11 , Feb 5, 2008
                    Everybody thanks for the valuable comments. Although it does sound
                    interesting, I won't have the opportunity to visit Dallas in a few
                    weeks time (The Netherlands <--> Dallas is a bit far), so I'll pass on
                    that opportunity.

                    Corey, am I correct (based on your blog) that you are in favor of the
                    3rd scheme you describe? Use MMFs as 'high level' work requests, break
                    them down into rightsized chunks and do not consider anything done
                    until the MMF is done?

                    Martin

                    --
                    Martin Schapendonk, http://www.schapendonk.org/blog/
                  • Corey Ladas
                    Well, I try to be careful about what I m in favor of, as I am in favor of whatever makes the most sense for the capability of the team in question. I would
                    Message 9 of 11 , Feb 5, 2008
                      Well, I try to be careful about what I'm "in favor of," as I am in favor
                      of whatever makes the most sense for the capability of the team in
                      question. I would say that extracting MMFs from broader requirements is
                      almost always right.

                      The 3rd scheme goes along with a more advanced analysis and design
                      capability. If you're using Design Structure Matrices, operationally
                      defined requirements, and/or Nam Suh's design axioms, then the 3rd
                      scheme is natural and efficient. Any MMF will break down into a set of
                      rows in the DSM. When the rows are all resolved, the MMF is done. A
                      beneficial consequence is that kanban limiting is simpler than point
                      limiting. The ability to break work up into similarly-sized pieces is a
                      more advanced capability that some might aspire to. If your estimation
                      skills are actually accurate, you are already part of the way there.

                      Corey


                      Martin Schapendonk wrote:
                      >
                      > Everybody thanks for the valuable comments. Although it does sound
                      > interesting, I won't have the opportunity to visit Dallas in a few
                      > weeks time (The Netherlands <--> Dallas is a bit far), so I'll pass on
                      > that opportunity.
                      >
                      > Corey, am I correct (based on your blog) that you are in favor of the
                      > 3rd scheme you describe? Use MMFs as 'high level' work requests, break
                      > them down into rightsized chunks and do not consider anything done
                      > until the MMF is done?
                      >
                      > Martin
                      >
                      > --
                      > Martin Schapendonk, http://www.schapendonk.org/blog/
                      > <http://www.schapendonk.org/blog/>
                      >
                      >
                    • Landes Eric (CI/AMM1-NA)
                      Martin, Sorry for the delay in the reply. We use the points combined with our completion dates to right now for a good cycle time estimate (we re mainly using
                      Message 10 of 11 , Feb 6, 2008
                        Martin,
                        Sorry for the delay in the reply.  We use the points combined with our completion dates to right now for a good cycle time estimate (we're mainly using this for changes to existing system, not for new product development).  However, the value I see in points would be that when a team estimates a change to something really high, we would break that down into a more managable change (probably multiple changes pointed out).  This keeps the tasks managable for the team, and helps us truly know what's in the backlog.
                         
                        Even though a work request can be any size, that doesn't mean it should be.  One benefit I've seen for agile is the ability for teams to finish work quickly, and this relates back to getting the work in manageable "chunks".  Also, when you do planning poker, a lot of information comes out about the feature or change that you don't see at first glance.  In my opinion, once you do this, you can talk to your customers about average cycle times etc.  This then helps the team determine when we need to work on items that have a higher priority.  But if you follow Corbis' example, the priorities are set by customers, so these estimates would be helpful in explaining to the customers, this change is a larger change, and will take more time, so you prioritize.
                         
                        That being said, sometimes we have to work lot's of hours because there is a deadline we can't miss.  But I believe with this process, those types of issues almost disappear, because of the communication between all team members.  HTH
                         
                        Eric Landes
                        http://aspadvice.com/blogs/elandes


                        From: kanbandev@yahoogroups.com [mailto:kanbandev@yahoogroups.com] On Behalf Of Martin Schapendonk
                        Sent: Friday, February 01, 2008 9:50 AM
                        To: kanbandev@yahoogroups.com
                        Subject: Re: [kanbandev] How to handle strict deadlines in a kanban?

                        Eric, thanks for your comments.

                        I'm familiar with the point system and planning poker. But, I know it
                        in relation to Scrum, with fixed sprint length. IMHO, such a system
                        has a bigger need for estimates, to determine if something fits within
                        a sprint.

                        A kanban system has no iterations and a work request can be any size.
                        There is no real need to see if it fits, because if it can be worked
                        on, it can be put in the queue (or did I misinterpret something?).

                        Do you use point value to estimate lead time? E.g. a kanban estimated
                        10 points will take us (estimate! average!) 20 days and 15 points will
                        take us 30 days?

                        What do you answer (based on what information) when the business asks
                        "what's the planning, when do I get it"?

                        Martin

                        On 2/1/08, Landes Eric (CI/AMM1-NA) <eric.landes@ us.bosch. com> wrote:
                        >
                        >
                        > Not sure if this is helpful Martin, but we are trying to estimate each work item using a point system. This is more to help the team understand work in the queue and over time, we can report back to upper management on what's actually in the queue. For these items our team does planning poker. But for us, since we do a FIFO process to select from our backlog, the estimation is more for management reporting than for the developers.
                        >
                        > Eric Landes
                        >
                        >
                        >
                        >
                        > ____________ _________ _________ __
                        From: kanbandev@yahoogrou ps.com
                        [mailto:kanbandev@yahoogrou ps.com] On Behalf Of Martin Schapendonk
                        > Sent: Friday, February 01, 2008 4:11 AM
                        > To: kanbandev@yahoogrou ps.com
                        > Subject: Re: [kanbandev] How to handle strict deadlines in a kanban?
                        >
                        >
                        >
                        >
                        >
                        >
                        > OK, sounds good.
                        >
                        > As you mentioned, work requests can vary greatly in size. When does a
                        > kanban team estimate the size of a work request? Is any effort spend
                        > on estimating the expected lead time for a specific work request?
                        >
                        > Martin
                        >
                        > On 1/31/08, Corey Ladas <coreyl@...> wrote:
                        > > 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.schapend onk.org/blog/
                        > > > <http://www.schapend onk.org/blog/>
                        > > >
                        > > >
                        > >
                        > >
                        > >
                        > >
                        > > Yahoo! Groups Links
                        > >
                        > >
                        > >
                        > >
                        >
                        > --
                        > Martin Schapendonk, http://www.schapend onk.org/blog/
                        >
                        >
                        >

                        --
                        Martin Schapendonk, http://www.schapend onk.org/blog/

                      Your message has been successfully submitted and would be delivered to recipients shortly.