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

Re: [XP] XP Practices Question: Effort driven stories

Expand Messages
  • Kyle Cordes
    From: Chris Johnson ... The main hazard of throwing in some hours of effort work in each iteration, is that you re not getting
    Message 1 of 2 , Dec 1, 2003
    • 0 Attachment
      From: "Chris Johnson" <madprogramman@...>

      > driven story" every iteration. This is a story that doesn't have
      > clearly defined acceptance criteria, like "Improve performance" or
      > "Fix bugs." As developers, we've been pushing to have these broken
      > into actual stories that have a measurable goal but our
      > managers/customers (yes they are the same people) have been very
      > resistant. We basically assign these stories a velocity that
      > represents the amount of effort that will be put into them, instead of
      > the amount of effort it will take to complete them. At the end of the

      The main hazard of throwing in some "hours of effort" work in each
      iteration, is that you're not getting quite as much velocity feedback as you

      I'd guess that you have a list of bugs (electronic, or on paper/cards) that
      need to be fixed - could you make those in to schedulable stories? If they
      seem to numerous and small, how about grouping them together (for example
      "fix all the cosmetic bugs in reports A B and C")? The idea here is that
      it's nice for the customer to steer, even if their steering is at a pretty
      high level ("I value fixing the bugs in X subsystem more than the bugs in Y

      Perhaps you have a long list of not-very-important bugs, each one small and
      not sufficiently important for the customer to spend their valuable time
      discussion and prioritizing - yet fixing them is important to the customer
      overall. In that case, you may still want to choose some (on the programmer
      side) to estimate and work on each iteration, so that you can get real
      velocity feedback.

      For the performance improvement work, it's usually pretty easy to ask "what
      part of this thing is too slow?" "how fast would be fast enough?" If there
      is no part of the system that is too slow, it is surprising that the
      customers/managers want to allocate effort to improving that rather than
      adding functionality or resolving known bugs.

      [ Kyle Cordes * kyle@... * http://kylecordes.com ]
      [ Better processes, better design, better software. Java, ]
      [ Delphi, BDE Alternatives Guide, Enterprise apps, and more ]
    Your message has been successfully submitted and would be delivered to recipients shortly.