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

Re: [scrumdevelopment] Re: How do you choose an iteration length?

Expand Messages
  • Mark Levison
    Very quick reply - to me this is big smell tasks that can t broken down. If you look at any of Poppendieck s books you will see the effect of task size. In
    Message 1 of 13 , Feb 28, 2009
    • 0 Attachment
      Very quick reply - to me this is big smell tasks that can't broken down. If you look at any of Poppendieck's books you will see the effect of task size. In you're next retrospective I would survey team members to find out why tasks are so large and take steps to break them down. Repeat until the average task size is less than 8hrs.


      On Wed, Feb 25, 2009 at 4:30 PM, jpetrangelo1 <jeanne@...> wrote:

      --- In scrumdevelopment@yahoogroups.com, Mark Levison <mark@...> wrote:

      > On Wed, Feb 25, 2009 at 3:53 PM, jpetrangelo1 <jeanne@...> wrote:
      > > Advantages of longer iterations:
      > > - Less overhead.
      > Really what makes you say that? The meetings scale with the length of
      > the sprint. I'm not sure what other overhead you can find. Please
      > share.

      Thank you for questioning these assumptions! This one is one I've
      heard around so I passed it on. The assumption is that meeting lengths
      (iteration planning, retrospectives, etc.) would be capped because
      people can't tolerate very long meetings. Thus the meetings wouldn't
      really scale. Of course the corollary is if you don't give yourself
      the time you truly need, your meetings aren't going to be as effective.

      > > - Work can be broken down into longer units, which might be a better
      > > fit for certain environments. For example it may just not be realistic
      > > to have work that takes half a day to two days to complete, versus two
      > > to four days. If you need longer work items, it's a challenge to pick
      > > a good set of work that fits in a shorter iteration. This seems more
      > > of a technical limitation that might end up being the deciding factor.
      > Why would you tolerate work being done in such large chunks? What
      > stops it being broken down? I'm interested because I've yet to see
      > work that couldn't be broken down in chunks of less than a day.

      It would be people's natural tendencies here to create chunks of work
      that take 2-5 days, because our traditionally managed tasks are
      typically 3 days to two weeks. Why? Because breaking it down more than
      that makes Gantt tracking even more painful. So people here are
      assuming breaking down the work chunks to 2-5 days is really tiny, and
      less than that is absurdly small. I might add that seeing examples
      from non-embedded projects does not have any influence. In our build
      environment, it takes 15 minutes to build with no changes at all, and
      you don't even want to know how long it takes for a full build with
      changes (hours). That won't change, even if we could get our unit
      tests to run on the host instead of the target, allowing us to avoid
      the time consuming step of downloading sw to the target in order to
      see it run. Depending on the hardware configuration, I may need to
      let my build go overnight before I can run it. If you don't count the
      build step, the work might take less than a day, but in the meantime
      my ability to tackle other tasks (multitask) is similarly limited.


      Mark Levison
      Blog: http://www.notesfromatooluser.com/
      Recent Entries: Agile/Scrum Smells:  http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
      Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html
    Your message has been successfully submitted and would be delivered to recipients shortly.