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

Re: User Story Assumptions

Expand Messages
  • Joe Baldwin
    ... I agree with you this make it almost impostable to make some project work during the planning game and size the critical piece of the project. I must say
    Message 1 of 86 , Apr 1, 2007
      --- In extremeprogramming@yahoogroups.com, Adrian Howard <adrianh@...>
      wrote:
      >
      >
      > On 31 Mar 2007, at 18:52, Joe Baldwin wrote:
      >
      > > I like what you are say but we have had problems with the customer
      > > under standing the idea of a spike when a store has risk.
      >
      > What were the problems?
      >
      > > The way that
      > > we have we work are round our in ability to get our customer to under
      > > stand the value of a spike is to have the customer give us a % of the
      > > project for the unknown. which we use for spikes and then bring the
      > > finish real size of a story to our customers. I think having a
      > > business unit understand that spending money on something that we will
      > > mostly like through away and that money is buying you a better
      > > product.
      >
      > I'm curious why you had problems with the customer allowing you time
      > for a spike to help resolve a specific area of risk, but was
      > comfortable giving you N% of a project for "stuff"?
      >
      > I would have thought the spike time would sound less open to abuse.
      >
      > > When the project are small by the world standards. It make it
      > > hard to make the business unit understand that you are not just going
      > > of playing it is this distrust is the heart of all of our problems.
      >
      > Indeed :)
      >
      > That said taking a certain % of project time for spokes sounds like
      > it would be difficult to manage in an XP project. If a high-priority
      > story can't be estimated well in the planning game because you need a
      > spike, what do you say to your customer?
      >
      I agree with you this make it almost impostable to make some project
      work during the planning game and size the critical piece of the
      project. I must say that is XP teams our inability to explain the need
      or sell this idea to our customers that the team as a whole will
      benefit from a spik

      My rant about work -
      In the past before XP tech department was an equal in the business
      decision.
      (during this time of equally the process and idea for improving the
      company came from the programmers. I the 3 year under XP the old time
      manger are taking control all idea must come from management. After
      all the ground troop are expendable and some one on the ground could
      not understand what is truly going on.)

      I this movement to take control of Idea generation the management will
      only allow a small level of trust to develop between the XP team and
      the Customers.
      If the XP say they to take time to do a skip and we try to size even
      if it place as the 1 priority to the project the costumer and
      management will not allow it to be done first.




      > Cheers,
      >
      > Adrian
      >
    • 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.