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

[XP] Re: User Story Assumptions

Expand Messages
  • dnicolet99
    ... Ah, so I was right: It *is* a question of engineering discipline. ... A spike would be an agile approach to the problem. Making higher estimates (adding a
    Message 1 of 86 , Apr 1 7:57 AM
    View Source
    • 0 Attachment
      --- 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.
    • Simon Jones
      I give one estimate which makes no assumptions about the order i.e. each story is sufficiently estimated to be built without the other. This assumes the there
      Message 86 of 86 , May 7, 2007
      View Source
      • 0 Attachment
        I give one estimate which makes no assumptions about the order i.e.
        each story is sufficiently estimated to be built without the other.
        This assumes the there isn't a *vast* difference and given we like
        story sizes that number a handful of days this is usually the case.
        If the business happen to prioritise in such as way that they gain
        some additional time back.. great.. they can fit something else in :)

        On the odd occasion where the order makes a dramatic difference this
        implies a very tight coupling between the stories and more often
        than not we'll look to work with the business to re-do the stories
        and get them into a a better split.

        However, in the really rare circumstance that this can't be done,
        then we simply suggest adopting the most cost effective order and
        leave it to the business to decide.

        --- In extremeprogramming@yahoogroups.com, "Bob" <koss@...> wrote:
        >
        > I give 2 estimates on the story. One if done first and another if
        done after story X.
        >
        >
        > Sent from my Verizon Wireless BlackBerry
        >
        > -----Original Message-----
        > From: "Psychie Naill" <psychieslash@...>
        > Date: Thu, 22 Mar 2007 11:25:04
        > To:extremeprogramming <extremeprogramming@yahoogroups.com>
        > Subject: [XP] User Story Assumptions
        >
        > Hi there,
        >
        > While estimating a batch of stories for the first release of a new
        project I
        > noticed that some stories are, not dependant, but build on
        experience from
        > other stories, e.g. If I implement story A, I will be able to
        implement
        > story B because A has some similar obstacles as B.
        > Therefore, when estimating the points for story B, I was wondering
        should I
        > treat this as if Story A hasn't come round yet and therefore
        estimate it on
        > the full complexity, or allow for the fact that I may have already
        completed
        > Story A.
        > That's not a great description of what I'm trying to say. I
        suppose it's
        > obvious that I should split the similar parts of the stories into
        it's own
        > story but it's not the case that the stories have some similar
        > functionality, rather that they have a similar Spike requirements.
        > If I allow Story A to affect the estimate of Story B, wouldn't
        this be like
        > story dependencies? Therefore, the customer couldn't freely choose
        stories.
        > They'd have to choose the dependant stories before the depending
        stories,
        > wouldn't they.
        > Or would you recommending 'Stubbing' the dependencies?
        >
        > Sorry if this was confusing. I'm trying to piece together a
        thought I had
        > late last night.
        >
        > Cheers,
        >
        > Psychie
        >
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to: extremeprogramming-
        unsubscribe@...
        >
        > ad-free courtesy of objectmentor.com
        > Yahoo! Groups Links
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.