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

Re: [XP] Splitting Story Mid-Iteration

Expand Messages
  • Brian Spears
    We have debated that ourselves. In general, we do not if something was a 3 and looks like a 4 or 5, for example (scales are relative, we are doing 35 story
    Message 1 of 9 , Jan 24, 2007
    • 0 Attachment
      We have debated that ourselves. In general, we do not if
      something was a 3 and looks like a 4 or 5, for example
      (scales are relative, we are doing 35 story points per 2
      week iteration to give you an idea of our scale). We
      ballpark some wrong (high) and other wrong (low) and it
      tends to even out.

      Now if we break it down and realize it's a 10 instead of a
      2 because we totally forgot about something in ballparking,
      then we need to do something - probably break it into
      multiple stories and re-assign ball parks.

      Brian

      --- kognition2006 <kognition@...> wrote:

      > Thank you for input Brian, it is very helpful.
      >
      > During iteration planning, when we break down a story
      > into tasks, we
      > often realise that the story estimate (in points) is
      > wrong. Should
      > we change it here, to include the uptodate information?
      >
      >
      > --- In extremeprogramming@yahoogroups.com, Brian Spears
      > <wormdrowner1@...> wrote:
      > >
      > >
      > > If part of the story is split part way through the
      > > iteration because the story was bigger/more difficult
      > than
      > > expected, we would typically consider the part we
      > completed
      > > to be 2 story points.
      > >
      > > What is split off is a new story - ballpark it as such
      > as
      > > accurately as you can. You know more about the
      > challenges
      > > and pitfalls you missed on the first ballpark and
      > hopefully
      > > the remaining work is more accurately ballparked.
      > >
      > > Another thing to consider - if you have learned a lot
      > this
      > > iteration and you suddenly realize some other report
      > > stories coming up were ballparked way too low, you
      > might
      > > have to A) reballpark - you have more information; or
      > B)
      > > leave the ballparks alone and consider your velocity to
      > be
      > > lower.
      > >
      > > The purpose of velocity is to have a simple, reasonable
      > > prediction of how much work you can get done in the
      > next
      > > iteration (and maybe a few beyond) and keep the
      > customer
      > > informed so they can continue to make prioritization
      > > decisions - in my mind you have some flexibility on
      > what
      > > you do with future points so long as you are working to
      > > make your predictions more accurate for the customer.
      > >
      > > Brian
      > >
      > > --- kognition2006 <kognition@...> wrote:
      > >
      > > > Brian,
      > > >
      > > > How do you handle the story points? If a story is
      > > > estimated as 2
      > > > points, but is split, what do you do with the
      > estimate
      > > > for velocity?
      > > >
      > > > We do spikes, but we need to get better with it!
      > > >
      > > > Thanks!
      > > >
      > > > Karl.
      > > >
      > > > --- In extremeprogramming@yahoogroups.com, Brian
      > Spears
      > > > <wormdrowner1@> wrote:
      > > > >
      > > > >
      > > > > That is correct. We do our best to ballpark and
      > use
      > > > our
      > > > > velocity to predict how much we can get done in an
      > > > > iteration. Then when we task out in iteration
      > > > planning,
      > > > > and based on the task days, we sometimes we add a
      > story
      > > > or
      > > > > push a story or part of a story (by breaking it
      > into 2
      > > > > parts) into the next iteration. Customer, of
      > course,
      > > > has
      > > > > input in what gets moved to next iteration because
      > the
      > > > > customer sets priorities. Sometimes it is hard to
      > > > admit a
      > > > > bad ballpark, but you have to do it - customer
      > needs
      > > > the
      > > > > real picture.
      > > > >
      > > > > The sooner in the iteration you realize it, the
      > better,
      > > > but
      > > > > we've done exactly what you say part way through an
      > > > > iteration. We don't do it lightly, but iterations
      > need
      > > > to
      > > > > end on time and on quality.
      > > > >
      > > > ...
      > > > >
      > > > > Good luck.
      > > > >
      > > >
      > > >
      > > >
      > >
      > >
      > >
      > >
      > >
      >
      _____________________________________________________________________
      > _______________
      > > No need to miss a message. Get email on-the-go
      > > with Yahoo! Mail for Mobile. Get started.
      > > http://mobile.yahoo.com/mail
      > >
      >
      >
      >




      ____________________________________________________________________________________
      Cheap talk?
      Check out Yahoo! Messenger's low PC-to-Phone call rates.
      http://voice.yahoo.com
    Your message has been successfully submitted and would be delivered to recipients shortly.