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

Re: [scrumdevelopment] Re: 4 Week vs 3 Week vs 2 Week Cycle

Expand Messages
  • Steven Gordon
    ... Longer makes it harder to recover from a problem because the problem generally becomes bigger before you discover it is a problem. Also, with longer
    Message 1 of 19 , Feb 28, 2007
    • 0 Attachment
      On 2/28/07, Pascal Thivent <pascal@...> wrote:
      >
      > Hi all,
      >
      > regarding the iteration size, RUP (which is more heavy on ceremonies) says something like "your iteration should allow the team to implement at least a complete UC or UC scenario" (2 or 3 are better IMO). If I transpose this to SCRUM, I would say "your iteration should be long enough to allow the team to implement enough shippable items". And OFC, this depends on the team size, items size, velocity...
      >
      > Then, regarding long vs short sprints :
      > - short are good : "agile" (you can change your mind often), more feedback, less time spent doing a wrong thing...
      > - long are good : easier to recover from a problem, less overhead in ceremonies (sprint planning meeting, demo, retrospective)

      Longer makes it harder to recover from a problem because the problem
      generally becomes bigger before you discover it is a problem. Also,
      with longer iterations, you tend to give a problem more time to fix
      itself.

      Longer just makes the meetings proportionally longer, so the overhead
      ratio is the same either way, but it is much harder to schedule and
      stay focussed in longer meetings than a shorter ones. This is
      especially true when comparing a 4-hour sprint planning meeting to a
      2-hour one.

      I see absolutely no advantage to sprints being longer than 2 weeks in practice.

      > I don't spend too much time in analysing the ideal sprint length. Just choose a decent length (2 weeks seem to be a common length for agile methodologies) and start experimenting, then adapt if required.
      >
      > And about the size of your items :
      > - too big = more risks to not complete an item, big items are more difficult to plan (over commitment or under commitment)
      > - too small = you're doing too much micromanagement
      > For these reasons, I think (and I may be wrong too) that the size of the iteration can impact the size of your items backlog and force you to review the breakdown.
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.