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

1976RE: [scrumdevelopment] Re: flattened cost of change curve

Expand Messages
  • Ilja Preuss
    Oct 6, 2003
    • 0 Attachment
      Edmund Schweppe wrote:
      > Ilja Preuss wrote:
      > > Actually I'd
      >> think that having to "make a change" invariably had to be a reaction
      >> to a "defect in the requirements" for him. At least that's the only
      >> way I can imagine introducing a "bug" in the "analysis phase" at
      >> all...
      >
      > I can imagine two scenarios:
      > 1) When I'm initially gathering requirements from you, you tell me
      > that the app needs to display information in both English and German.
      > I misunderstand you (or lose my notes) and deliver an English-only
      > app. That would be a "requirements bug".

      Yep.

      > 2) When I'm initially gathering requirements from you, you tell me
      > that the app needs to display information in English. I deliver an
      > English-only app; then you tell me that you also need the app to
      > display information in German. (For instance, you might have been
      > building a payroll system for an American automotive manufacturer who
      > subsequently was purchased by a German one :-) That, to me, is a
      > change that's not due to a bug in the requirements; instead, it's due
      > to a change in the environment.

      Yes - though I think in a waterfallish environment it could be seen as a
      bug, too. You simply didn't do enough analysis upfront - else you should
      have known that you could need a different language version in the
      future. Because you didn't, you have to restart the whole development
      cycle.

      To an agile team, of course, *both* scenarios just result in another
      feature to be added incrementally. That's why I think that "requirement
      bugs" aren't that important in agile development.

      Regards, Ilja
    • Show all 30 messages in this topic