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

[XP] Re: User Story Assumptions

Expand Messages
  • dnicolet99
    ... IMO it s more an investment in time to learn whether a proposed approach is sound. A spike can answer a question like, Can we meet the response time
    Message 1 of 86 , Apr 1, 2007
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "Steven Gordon"
      <sgordonphd@...> wrote:
      >
      > I coach that the primary purpose of spikes are when a story cannot be
      > estimated within reasonable bounds. In those cases, a spike is a fixed
      > amount of time invested to learning whatever is necessary to be able to
      > provide a better estimate. The team should estimate how much time is
      > required for the spike.

      IMO it's more an investment in time to learn whether a proposed
      approach is sound. A spike can answer a question like, "Can we meet
      the response time requirement under peak load using MySQL, or do we
      need to consider Oracle or DB2?" or "Is Tandem's MQSeries support
      compatible with IBM's Java MQSeries package?"

      I'm not so sure a spike can (usually) answer a question like, "Will
      this story take one day or five weeks?" except indirectly - maybe it
      will take five weeks to work around an incompatibility in MQSeries
      support, for instance. But even so, the purpose of the spike is to
      validate a proposed solution approach, and not to refine an estimate.
      A better estimate may result from the team's determination of which
      design approach will work, of course, but I see that as a side effect
      of the spike. The primary effect is confidence in the design approach.

      > It is always the customer's choice as to how to invest the team's
      time. The
      > customer decides whether providing a reasonable estimate for story A
      is of
      > higher or lower priority than implementing story B (A being higher
      priority
      > than B does not necessarily mean that a spike for A is higher
      priority than
      > B).

      +1.


      >
      > I believe this approach serves everyone better than fudging the
      estimates to
      > cover for uncertainty. Fudging not only deludes the customer into
      thinking
      > they are comparing apples with apples, but it makes velocity a much less
      > reliable measure of what is likely to be done for the next release.
      >

      +1



      > I agree also that costs are also orthogonal with story points. If
      cost is
      > an unusual factor of a specific story, the customer simply has to be
      made
      > aware of the cost prerequisites for implementing the story.
      >

      +1

      Dave
    • 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
      • 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.