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

Estimates, SLAs and Kanban Queues

Expand Messages
  • Karl Scotland
    I ve been thinking about how we achieve roadmap planning in a product development environment (as opposed to sustained engineering), were we need to give some
    Message 1 of 8 , Mar 4, 2008
    View Source
    • 0 Attachment
      I've been thinking about how we achieve roadmap planning in a product
      development environment (as opposed to sustained engineering), were we
      need to give some idea of a roadmap to the business so that they can
      make their own plans accordingly. What we've done so far is do some
      simple planning poker, t-shirt estimates for a quarter (which took
      around 2 hours), and use that put together a basic month by month
      roadmap. This seemed to minimise the amount of inventory invested in
      the estimated in order to give a high level forecast. However, the
      way development has turned put has proved even this time to be a
      waste.

      So how do set an appropriate level of expectation with the business so
      they know when they might get a feature? Cycle time and throughput
      help, but when features are of varying size, the calculation of when
      to prioritise can be complicated.

      Alistair Cockburn recently described the purpose of planning to be
      able to answer the question "With what we NOW know, what will the most
      useful system we can create look like on THAT date?" and it seems to
      me that an estimate is just a way of setting an SLA with the business
      so that they have confidence that if we start something NOW, then it
      will be done by THAT date.

      This probably makes estimating even simpler, because the business may
      only need SLAs of say 1, 2 and 4 weeks. In addition a weekly
      prioritisation meeting, rather than focussing on restocking the
      buffer, could ask two questions:
      1. Based on our SLAs, what do we commit to completing this week.
      2. What can we commit to starting this week..

      Thus, the business can easily determine, based on SLAs, when it needs
      to prioritise work in order to get it delivered by known dates, and
      the development team has clear commitments to dates on a feature by
      feature basis.

      Does this make sense? How does it fit with other views?

      Karl
    • Aaron Sanders
      Last quarter our teams started tracking fairly rigorously what projects are being worked on. there are workflow statuses of Unknown , In Discussion ,
      Message 2 of 8 , Mar 4, 2008
      View Source
      • 0 Attachment
        Last quarter our teams started tracking fairly rigorously what
        projects are being worked on. there are workflow statuses of
        'Unknown', 'In Discussion', 'Active', 'Committed', 'Completed',
        'Launched', 'Cancelled', 'On Hold'

        This quarter the group was able to force-rank all WIP (from 'in
        discussion' to 'launched', but not all on-hold projects. What I want
        look at the delta between the dates from first to last steps of
        discussion to launched.

        Then, I want to do a rough sizing (t-shirt? 1/2/4 week?) of everything
        that is upcoming from product for the year, and have these force
        ranked as well.

        The problem is coming up with the capacity of the group. Some projects
        span multiple teams. I think a 1:1 ratio of team:project would be good
        for WIP. It's been a tough sell, with functionally aligned distributed
        teams.

        I think we're close to being able to look at the product roadmap, and
        determine if the load is too much for the group, or at least determine
        of the projects in motion today when some of them might complete.
        Actually, I think it'll be easier at this higher level to get across
        the kanban wip limit and only start a new project when one finishes
        than on the team level, for some teams. The trouble is the system is
        over capacity, and there is no slack. Lead times are horrible, for
        both planned and urgent work.

        What would be the best way to calculate system capacity for a
        distributed, functionally aligned, multi-team system?



        --- In kanbandev@yahoogroups.com, "Karl Scotland" <kjscotland@...> wrote:
        >
        > I've been thinking about how we achieve roadmap planning in a product
        > development environment (as opposed to sustained engineering), were we
        > need to give some idea of a roadmap to the business so that they can
        > make their own plans accordingly. What we've done so far is do some
        > simple planning poker, t-shirt estimates for a quarter (which took
        > around 2 hours), and use that put together a basic month by month
        > roadmap. This seemed to minimise the amount of inventory invested in
        > the estimated in order to give a high level forecast. However, the
        > way development has turned put has proved even this time to be a
        > waste.
        >
        > So how do set an appropriate level of expectation with the business so
        > they know when they might get a feature? Cycle time and throughput
        > help, but when features are of varying size, the calculation of when
        > to prioritise can be complicated.
        >
        > Alistair Cockburn recently described the purpose of planning to be
        > able to answer the question "With what we NOW know, what will the most
        > useful system we can create look like on THAT date?" and it seems to
        > me that an estimate is just a way of setting an SLA with the business
        > so that they have confidence that if we start something NOW, then it
        > will be done by THAT date.
        >
        > This probably makes estimating even simpler, because the business may
        > only need SLAs of say 1, 2 and 4 weeks. In addition a weekly
        > prioritisation meeting, rather than focussing on restocking the
        > buffer, could ask two questions:
        > 1. Based on our SLAs, what do we commit to completing this week.
        > 2. What can we commit to starting this week..
        >
        > Thus, the business can easily determine, based on SLAs, when it needs
        > to prioritise work in order to get it delivered by known dates, and
        > the development team has clear commitments to dates on a feature by
        > feature basis.
        >
        > Does this make sense? How does it fit with other views?
        >
        > Karl
        >
      • David J Anderson
        Karl, Question 1. What do we commit to completing this week? Is pretty much the standard release cadence question asked at Corbis by the PM who coordinates the
        Message 3 of 8 , Mar 4, 2008
        View Source
        • 0 Attachment
          Karl,

          Question 1. What do we commit to completing this week? Is pretty much
          the standard release cadence question asked at Corbis by the PM who
          coordinates the releases. Corbis "commits" the release content 5
          business days ahead. And hence, it looks like the right thing to be
          doing to me.

          Question 2. What can we commit to starting this week? Sounds like a
          real options approach to restocking the buffer.

          I think you should be tracking and reporting due date performance
          against the SLA, so that you can give a "probability" on what you
          commit to starting this week, against the SLA and a range of variance.
          While noting that particularly important things may well be
          "expedited" upon customer/sponsor request.

          It's also worth noting that if you invested in analysis techniques
          that would narrow the variation in size of items then you'd be able to
          get back to a quarterly forecast and roadmap - just don't ever call it
          a plan because someone will hold you to it. Practice the paradigm that
          embraces variation and recognizes that all you can do is "forecast"
          and that you make your best efforts to meet SLAs and to improve the
          DDP month to month. Meanwhile, recognize that you have to be both
          confident and reliable on your promise to "what do we commit to
          completing this week?"

          David
          --
          Founder and Principal Consultant
          Modus Cooperandi
          http://www.moduscooperandi.com/

          --- In kanbandev@yahoogroups.com, "Karl Scotland" <kjscotland@...> wrote:
          >
          > I've been thinking about how we achieve roadmap planning in a product
          > development environment (as opposed to sustained engineering), were we
          > need to give some idea of a roadmap to the business so that they can
          > make their own plans accordingly. What we've done so far is do some
          > simple planning poker, t-shirt estimates for a quarter (which took
          > around 2 hours), and use that put together a basic month by month
          > roadmap. This seemed to minimise the amount of inventory invested in
          > the estimated in order to give a high level forecast. However, the
          > way development has turned put has proved even this time to be a
          > waste.
          >
          > So how do set an appropriate level of expectation with the business so
          > they know when they might get a feature? Cycle time and throughput
          > help, but when features are of varying size, the calculation of when
          > to prioritise can be complicated.
          >
          > Alistair Cockburn recently described the purpose of planning to be
          > able to answer the question "With what we NOW know, what will the most
          > useful system we can create look like on THAT date?" and it seems to
          > me that an estimate is just a way of setting an SLA with the business
          > so that they have confidence that if we start something NOW, then it
          > will be done by THAT date.
          >
          > This probably makes estimating even simpler, because the business may
          > only need SLAs of say 1, 2 and 4 weeks. In addition a weekly
          > prioritisation meeting, rather than focussing on restocking the
          > buffer, could ask two questions:
          > 1. Based on our SLAs, what do we commit to completing this week.
          > 2. What can we commit to starting this week..
          >
          > Thus, the business can easily determine, based on SLAs, when it needs
          > to prioritise work in order to get it delivered by known dates, and
          > the development team has clear commitments to dates on a feature by
          > feature basis.
          >
          > Does this make sense? How does it fit with other views?
          >
          > Karl
          >
        • David J Anderson
          Aaron, Have you taken a close look at the two-tiered kanban board approach from the major projects we were running at Corbis. The kanban board was for the
          Message 4 of 8 , Mar 4, 2008
          View Source
          • 0 Attachment
            Aaron,

            Have you taken a close look at the two-tiered kanban board approach
            from the major projects we were running at Corbis. The kanban board
            was for the project, but the swim lanes were for each team.

            WIP was controlled in two ways - the number of swim lanes - one for
            each team - and each swim lane effectively containing a MMF (though
            Corbis called the "requirements"). Within the swim lane the MMF was
            broken in to smaller items suitable for design, coding and testing in
            approximately 5 days lead time (Corbis called these "features").
            Different colored kanban tickets were used for the two different
            levels of the hierarchy.

            The target SLA on yellow (feature) tickets was 5 days, and the target
            SLA on green (requirement) tickets was more like 6 weeks.

            Teams (swim lanes) could function independently which allowed for
            "integration events" (equivalent of a release) to happen on a regular
            (release) cadence.

            If you want to see me present some of this stuff, come to the Agile
            Leadership event in San Francisco on May 5th - details from
            http://www.agilemanagement.net/ or Better Software in early June in
            Las Vegas.

            Karl, I'll also be presenting this material at QCon in London next
            week. Hope to see you there.

            David
            --
            Founder and Principal Consultant
            Modus Cooperandi
            http://www.moduscooperandi.com/


            --- In kanbandev@yahoogroups.com, "Aaron Sanders" <aremsan@...> wrote:
            >
            > The problem is coming up with the capacity of the group. Some projects
            > span multiple teams. I think a 1:1 ratio of team:project would be good
            > for WIP. It's been a tough sell, with functionally aligned distributed
            > teams.
            >
          • Karl Scotland
            ... Cool ... I hadn t thought about it that way, but yes. ... Agreed. ... We try to keep MMFs as Minimal as possible, but we have a wide variety of work,
            Message 5 of 8 , Mar 5, 2008
            View Source
            • 0 Attachment
              On 05/03/2008, David J Anderson <netherby_uk@...> wrote:
              > Karl,
              >
              > Question 1. What do we commit to completing this week? Is pretty much
              > the standard release cadence question asked at Corbis by the PM who
              > coordinates the releases. Corbis "commits" the release content 5
              > business days ahead. And hence, it looks like the right thing to be
              > doing to me.

              Cool

              > Question 2. What can we commit to starting this week? Sounds like a
              > real options approach to restocking the buffer.

              I hadn't thought about it that way, but yes.

              > I think you should be tracking and reporting due date performance
              > against the SLA, so that you can give a "probability" on what you
              > commit to starting this week, against the SLA and a range of variance.
              > While noting that particularly important things may well be
              > "expedited" upon customer/sponsor request.

              Agreed.

              > It's also worth noting that if you invested in analysis techniques
              > that would narrow the variation in size of items then you'd be able to
              > get back to a quarterly forecast and roadmap - just don't ever call it
              > a plan because someone will hold you to it. Practice the paradigm that
              > embraces variation and recognizes that all you can do is "forecast"
              > and that you make your best efforts to meet SLAs and to improve the
              > DDP month to month. Meanwhile, recognize that you have to be both
              > confident and reliable on your promise to "what do we commit to
              > completing this week?"

              We try to keep MMFs as "Minimal" as possible, but we have a wide
              variety of work, from very small things that take days, to larger
              things that take weeks. I fear that too much analysis to narrow the
              variation in size will generate waste and break up the one-piece flow.
              That being said, I agree that its a worthy goal and understand the
              benefits!

              Fully agree with the notion of forecasting as opposed to planning with
              a view to being committed and reliable.

              Thanks for the feedback.

              Karl
            • joe.arnold
              Right now we re using MMFs + Kanban on a brand-spank n new product. Here s what I ve noticed so far: We ve estimated the project, but only to determine
              Message 6 of 8 , Mar 5, 2008
              View Source
              • 0 Attachment
                Right now we're using MMFs + Kanban on a brand-spank'n new product.
                Here's what I've noticed so far:

                We've estimated the project, but only to determine feasibility within
                a time frame. Our launch date is what's driving us. MMFs come in one
                at a time and when our launch date comes, well, we're doing a launch.

                Our first MMFs are HUGE. They're several week-long efforts. The team
                choose to go from MMF -> tasks (rather than smaller features), so
                we've rigged up this 'double-decker' kanban board. The MMFs are on the
                top moving across right to left and tasks 'rain' down when they pass
                over a functional area. Think of the MMF as a rain cloud passing overhead.

                I don't have enough data to have any insight on MMF size, but I
                imagine we'll have the same variation issues. (Arlo Belshee mentioned
                he had a lot of variation too and he has a lot more data.) After our
                first few 'core' MMFs get built, I imagine we'll use story points to
                get relative sizing and do the velocity thing.

                -Joe Arnold
                --
                http://joearnold.com


                --- In kanbandev@yahoogroups.com, "Karl Scotland" <kjscotland@...> wrote:
                >
                > On 05/03/2008, David J Anderson <netherby_uk@...> wrote:
                > > Karl,
                > >
                > > Question 1. What do we commit to completing this week? Is pretty much
                > > the standard release cadence question asked at Corbis by the PM who
                > > coordinates the releases. Corbis "commits" the release content 5
                > > business days ahead. And hence, it looks like the right thing to be
                > > doing to me.
                >
                > Cool
                >
                > > Question 2. What can we commit to starting this week? Sounds like a
                > > real options approach to restocking the buffer.
                >
                > I hadn't thought about it that way, but yes.
                >
                > > I think you should be tracking and reporting due date performance
                > > against the SLA, so that you can give a "probability" on what you
                > > commit to starting this week, against the SLA and a range of
                variance.
                > > While noting that particularly important things may well be
                > > "expedited" upon customer/sponsor request.
                >
                > Agreed.
                >
                > > It's also worth noting that if you invested in analysis techniques
                > > that would narrow the variation in size of items then you'd be
                able to
                > > get back to a quarterly forecast and roadmap - just don't ever
                call it
                > > a plan because someone will hold you to it. Practice the paradigm
                that
                > > embraces variation and recognizes that all you can do is "forecast"
                > > and that you make your best efforts to meet SLAs and to improve the
                > > DDP month to month. Meanwhile, recognize that you have to be both
                > > confident and reliable on your promise to "what do we commit to
                > > completing this week?"
                >
                > We try to keep MMFs as "Minimal" as possible, but we have a wide
                > variety of work, from very small things that take days, to larger
                > things that take weeks. I fear that too much analysis to narrow the
                > variation in size will generate waste and break up the one-piece flow.
                > That being said, I agree that its a worthy goal and understand the
                > benefits!
                >
                > Fully agree with the notion of forecasting as opposed to planning with
                > a view to being committed and reliable.
                >
                > Thanks for the feedback.
                >
                > Karl
                >
              • David J Anderson
                Joe, Was there an image attached to this post? [your post didn t make it clear whether we were using our imagination or referring to a photograph] If so the
                Message 7 of 8 , Mar 5, 2008
                View Source
                • 0 Attachment
                  Joe,

                  Was there an image attached to this post? [your post didn't make it
                  clear whether we were using our imagination or referring to a
                  photograph] If so the group responder will have stripped it. You'll
                  need to upload it as an image to the group site. Thanks

                  David

                  --- In kanbandev@yahoogroups.com, "joe.arnold" <joe.arnold@...> wrote:
                  >
                  > Right now we're using MMFs + Kanban on a brand-spank'n new product.
                  > Here's what I've noticed so far:
                  >
                  > We've estimated the project, but only to determine feasibility within
                  > a time frame. Our launch date is what's driving us. MMFs come in one
                  > at a time and when our launch date comes, well, we're doing a launch.
                  >
                  > Our first MMFs are HUGE. They're several week-long efforts. The team
                  > choose to go from MMF -> tasks (rather than smaller features), so
                  > we've rigged up this 'double-decker' kanban board. The MMFs are on the
                  > top moving across right to left and tasks 'rain' down when they pass
                  > over a functional area. Think of the MMF as a rain cloud passing
                  overhead.
                  >
                  > I don't have enough data to have any insight on MMF size, but I
                  > imagine we'll have the same variation issues. (Arlo Belshee mentioned
                  > he had a lot of variation too and he has a lot more data.) After our
                  > first few 'core' MMFs get built, I imagine we'll use story points to
                  > get relative sizing and do the velocity thing.
                  >
                  > -Joe Arnold
                  > --
                  > http://joearnold.com
                  >
                  >
                  > --- In kanbandev@yahoogroups.com, "Karl Scotland" <kjscotland@> wrote:
                  > >
                  > > On 05/03/2008, David J Anderson <netherby_uk@> wrote:
                  > > > Karl,
                  > > >
                  > > > Question 1. What do we commit to completing this week? Is
                  pretty much
                  > > > the standard release cadence question asked at Corbis by the PM who
                  > > > coordinates the releases. Corbis "commits" the release content 5
                  > > > business days ahead. And hence, it looks like the right thing to be
                  > > > doing to me.
                  > >
                  > > Cool
                  > >
                  > > > Question 2. What can we commit to starting this week? Sounds like a
                  > > > real options approach to restocking the buffer.
                  > >
                  > > I hadn't thought about it that way, but yes.
                  > >
                  > > > I think you should be tracking and reporting due date performance
                  > > > against the SLA, so that you can give a "probability" on what you
                  > > > commit to starting this week, against the SLA and a range of
                  > variance.
                  > > > While noting that particularly important things may well be
                  > > > "expedited" upon customer/sponsor request.
                  > >
                  > > Agreed.
                  > >
                  > > > It's also worth noting that if you invested in analysis techniques
                  > > > that would narrow the variation in size of items then you'd be
                  > able to
                  > > > get back to a quarterly forecast and roadmap - just don't ever
                  > call it
                  > > > a plan because someone will hold you to it. Practice the paradigm
                  > that
                  > > > embraces variation and recognizes that all you can do is "forecast"
                  > > > and that you make your best efforts to meet SLAs and to improve the
                  > > > DDP month to month. Meanwhile, recognize that you have to be both
                  > > > confident and reliable on your promise to "what do we commit to
                  > > > completing this week?"
                  > >
                  > > We try to keep MMFs as "Minimal" as possible, but we have a wide
                  > > variety of work, from very small things that take days, to larger
                  > > things that take weeks. I fear that too much analysis to narrow the
                  > > variation in size will generate waste and break up the one-piece flow.
                  > > That being said, I agree that its a worthy goal and understand the
                  > > benefits!
                  > >
                  > > Fully agree with the notion of forecasting as opposed to planning with
                  > > a view to being committed and reliable.
                  > >
                  > > Thanks for the feedback.
                  > >
                  > > Karl
                  > >
                  >
                • Karl Scotland
                  I ve just posted a variation of this email as a blog. http://agilepractitionersforum.com/2008/03/20/kanban-commitment/ Karl
                  Message 8 of 8 , Mar 20, 2008
                  View Source
                  • 0 Attachment
                    I've just posted a variation of this email as a blog.

                    http://agilepractitionersforum.com/2008/03/20/kanban-commitment/

                    Karl

                    On 04/03/2008, Karl Scotland <kjscotland@...> wrote:
                    > I've been thinking about how we achieve roadmap planning in a product
                    > development environment (as opposed to sustained engineering), were we
                    > need to give some idea of a roadmap to the business so that they can
                    > make their own plans accordingly. What we've done so far is do some
                    > simple planning poker, t-shirt estimates for a quarter (which took
                    > around 2 hours), and use that put together a basic month by month
                    > roadmap. This seemed to minimise the amount of inventory invested in
                    > the estimated in order to give a high level forecast. However, the
                    > way development has turned put has proved even this time to be a
                    > waste.
                    >
                    > So how do set an appropriate level of expectation with the business so
                    > they know when they might get a feature? Cycle time and throughput
                    > help, but when features are of varying size, the calculation of when
                    > to prioritise can be complicated.
                    >
                    > Alistair Cockburn recently described the purpose of planning to be
                    > able to answer the question "With what we NOW know, what will the most
                    > useful system we can create look like on THAT date?" and it seems to
                    > me that an estimate is just a way of setting an SLA with the business
                    > so that they have confidence that if we start something NOW, then it
                    > will be done by THAT date.
                    >
                    > This probably makes estimating even simpler, because the business may
                    > only need SLAs of say 1, 2 and 4 weeks. In addition a weekly
                    > prioritisation meeting, rather than focussing on restocking the
                    > buffer, could ask two questions:
                    > 1. Based on our SLAs, what do we commit to completing this week.
                    > 2. What can we commit to starting this week..
                    >
                    > Thus, the business can easily determine, based on SLAs, when it needs
                    > to prioritise work in order to get it delivered by known dates, and
                    > the development team has clear commitments to dates on a feature by
                    > feature basis.
                    >
                    > Does this make sense? How does it fit with other views?
                    >
                    >
                    > Karl
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.