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

[XP] Re: User Story Assumptions

Expand Messages
  • dnicolet99
    Everyone, Points are just supposed to represent a general gut feel of relative story size. If we try to make too much out of it, we ll start spinning our
    Message 1 of 86 , Mar 30, 2007
      Everyone,

      Points are just supposed to represent a general "gut feel" of relative
      story size. If we try to make too much out of it, we'll start spinning
      our wheels and losing value.

      Neither points nor ideal time are supposed to represent,
      simultaneously, a measure of risk, scope, difficulty, complexity,
      time, human resource requirements, and anything else we can think of.

      And it's not so important whether you use a linear scale, a Fibonacci
      sequence, fractions, giant integers, ping pong balls, gummi bears,
      large-medium-small, or whatever you please. There is rationale and
      experience behind some of that - for instance, keeping the range
      within a single order of magnitude makes sizing easier for humans to
      grasp intuitively - but it's supposed to be a simple, useful tool.

      This stuff isn't that complicated!

      Dave


      --- In extremeprogramming@yahoogroups.com, "Seyit Caglar Abbasoglu"
      <scabbasoglu@...> wrote:
      >
      > I did not used points to express risks, but this is something I
      should think
      > of. As the amount of points rises then the uncertainity rises
      >
      > For the talent (or especially cost), I think it's better to state those
      > directly than using points to express implicitly.
      >
      > On 29 Mar 2007 19:53:08 -0700, Kelly Anderson <kellycoinguy@...>
      > wrote:
      > >
      > > On 3/28/07, Seyit Caglar Abbasoglu
      <scabbasoglu@...<scabbasoglu%40gmail.com>>
      > > wrote:
      > > > By 2-times harder, you mean "It will take 2-times longer", right?
      > >
      > > Not necessarily. It might be twice as risky. Or it might require twice
      > > the talent to get done (meaning it can only be accomplished by the
      > > most experienced programmers). It might mean that you have to buy
      > > additional hardware to get done. There are lots of other dimensions to
      > > "hard" than just time.
      > >
      > > -Kelly
      > >
      > >
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • 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
        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.