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

Re: [XP] Re: User Story Assumptions

Expand Messages
  • Ryan Cooper
    These days, I avoid indicating story risk with story points. When I have tried that in the past, it sometimes had the opposite effect from the one I intended.
    Message 1 of 86 , Apr 2, 2007
    • 0 Attachment
      These days, I avoid indicating story risk with story points. When I have
      tried that in the past, it sometimes had the opposite effect from the one I
      intended. Naturally, you want risky stories to be dealt with early in a
      release. However, when I increased the story point estimate for a story to
      indicate the risk involved, this generally caused it to drop down further on
      the product backlog. (PO's thinking: "Oh, that's more expensive than I
      thought; well, lets not tackle it until cheaper stories are done.") This bit
      us in the ass late in a release a few times.

      a more explicit way to track risk is to separate your estimate of story size
      from your estimate of risk, by giving a three-part estimate: the best-case
      scenario, the worst-case scenario, and the most-likely scenario. (Notice
      that the most likely scenario is rarely the midpoint between best-case and
      worst-case.) This makes it easier to determine which stories are risky and
      how much risk remains unresolved overall. However, this approach does
      complicate things, so you have to decide whether it's worth it in your
      context.

      Tom DeMarco and Tim Lister discuss this approach in their book "Waltzing
      With Bears." Although they don't talk explicitly about Agile/XP, their ideas
      are pretty compatible with agile thinking. I recommend it, whether you think
      this approach is right for you or not.

      Cheers,
      Ryan Cooper
      http://www.onagile.com

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