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

126729[XP] Re: User Story Assumptions

Expand Messages
  • dnicolet99
    Apr 1, 2007
      --- In extremeprogramming@yahoogroups.com, "Kelly Anderson"
      <kellycoinguy@...> wrote:
      > I assume, in an Agile shop that those kinds of risks are dealt with by
      > the Customer. I am interested only in technical risks.
      > Business people often inject goo into the engineering discipline over
      > the objections of engineers. The least risky technical approach,
      > therefore, is to never do spikes. At least you should never ever show
      > spikes to business people! They'll think you're almost done and
      > schedule a release party!

      Ah, so I was right: It *is* a question of engineering discipline.

      > How does the Agile team deal with
      > technical risk if not by making higher estimates for higher risk
      > items?

      A spike would be an agile approach to the problem. Making higher
      estimates (adding a "fudge factor") is old school. At that point the
      team has basically given up and fallen back to old practices.

      Scrum defines a role to help mitigate these problems (insertion of
      "goo", etc.) called the ScrumMaster. Agile teams that don't explicitly
      use Scrum often have a similar role. I've heard it called "process
      facilitator," for instance. Short of a specific role to ensure
      productive interaction with the customer, it falls (IMO) to the PM to
      deal with these issues.

      The plain truth is that the customer stands the best chance of
      receiving the value he/she is hoping for from a project if he/she
      leaves the technical details to the technical team. When the customer
      tries to inject "goo" into the process, it's a problem and should be
      addressed squarely, not "worked around" with Band-Aids like fudging
      estimates. Otherwise, the same problem will come up again and again.

      If the customer doesn't understand the value of a spike (or any other
      issue), he/she needs to learn to understand it. The "solution" to
      his/her lack of understanding is not simply to throw the team back
      into the 1980s.
    • Show all 86 messages in this topic