## [XP] Re: User Story Assumptions

Expand Messages
• 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]
>
• 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
> 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@...
>