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

RE: [XP] Value of Time-Boxed iterations?

Expand Messages
  • Jeff Nielsen
    Time-boxed iterations require the team to work together to learn how to hit a date. Making a date requires the efforts of the whole team, as they learn to
    Message 1 of 9 , Jan 3, 2007
    • 0 Attachment
      Time-boxed iterations require the team to work together to learn how to
      "hit a date." Making a date requires the efforts of the whole team, as
      they learn to trade off what is most important for what is less
      important (there are always more things that we can think of than we
      have time to do). Time-boxed iterations fix time and resources, and
      give the team lots of practice answering the question, "How much can we
      consistently get done in this amount of time?" As teams practice making
      commitments and meeting a date in very short timeframes, they are better
      able to do this for timeframe of the entire project, and for the dates
      that really count.

      Feature-boxed iterations try to fix the scope (the features) and have
      the team predict how much time it will take to build those features.
      It's a subtle difference but a significant one. It sometimes leads to
      answers like, "It will be done when it's done." Since it's often easier
      in the real world to fix time and resources than it is to fix
      requirements, the former approach seems to work better for many teams.

      Jeff Nielsen
      Digital Focus
      www.digitalfocus.com

      > -----Original Message-----
      > From: extremeprogramming@yahoogroups.com
      > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Dylan Smith
      > Sent: Tuesday, January 02, 2007 2:38 PM
      > To: extremeprogramming@yahoogroups.com
      > Subject: [XP] Value of Time-Boxed iterations?
      >
      > I've always heard that time-boxed iterations are an important part of
      > the agile/xp process. I'm currently using something that I
      > guess would
      > be called feature-boxed iterations. More accurately we're basically
      > treating each feature as its own iteration, and have multiple
      > features/iterations being developed in parallel. I have a
      > blog post that
      > elaborates a bit on how we operate here:
      > http://geekswithblogs.net/optikal/archive/2006/12/31/102381.aspx
      >
      >
      >
      > The process we're using appears to be working out well for us, and
      > ultimately that's what matters. But I'd like to get a better
      > understanding of time-boxed iterations and why they appear to be so
      > popular. Are there benefits to doing time-boxing that we are missing
      > out on by using our process? Does anybody else here use an
      > agile/xp-ish
      > process without time-boxing? If so how has it worked out for you?
      >
      >
      >
      > Cheers,
      >
      > Dylan Smith
      >
      >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >
    • Kent Beck
      Dear Dylan, It sounds like you have found a process that works well for you and that matches XP values well. It also supports the lean manufacturing principle
      Message 2 of 9 , Jan 8, 2007
      • 0 Attachment
        Dear Dylan,

        It sounds like you have found a process that works well for you and that
        matches XP values well. It also supports the lean manufacturing principle of
        not leaving work half done.

        I think I use feature-boxed iterations too, but I try to have my features
        small enough that I can still have a time-box rhythm going at a larger
        scale. So, for example, we work weekly on JUnit--adding a little feature or
        two or fixing a bug or two, but we're going to a monthly release cycle. The
        advantage of the time box for me is that it encourages scope decisions where
        I pick the most important half of a feature to implement and it encourages
        me to finish items instead of leaving them half done. A regular rhythm also
        gives external customers something to count on.

        Regards,

        Kent Beck
        Three Rivers Institute


        _____

        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Dylan Smith
        Sent: Tuesday, January 02, 2007 11:38 AM
        To: extremeprogramming@yahoogroups.com
        Subject: [XP] Value of Time-Boxed iterations?



        I've always heard that time-boxed iterations are an important part of
        the agile/xp process. I'm currently using something that I guess would
        be called feature-boxed iterations. More accurately we're basically
        treating each feature as its own iteration, and have multiple
        features/iterations being developed in parallel. I have a blog post that
        elaborates a bit on how we operate here:
        http://geekswithblo
        <http://geekswithblogs.net/optikal/archive/2006/12/31/102381.aspx>
        gs.net/optikal/archive/2006/12/31/102381.aspx

        The process we're using appears to be working out well for us, and
        ultimately that's what matters. But I'd like to get a better
        understanding of time-boxed iterations and why they appear to be so
        popular. Are there benefits to doing time-boxing that we are missing
        out on by using our process? Does anybody else here use an agile/xp-ish
        process without time-boxing? If so how has it worked out for you?

        Cheers,

        Dylan Smith

        [Non-text portions of this message have been removed]







        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.