Re: Re: User Story Assumptions

On 4/1/07, dnicolet99 <dnicolet <at> hotmail.com> wrote:
>
>
>
>
>
>
> --- In extremeprogramming <at> yahoogroups.com, "Steven Gordon"
>  <sgordonphd <at> ...> 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.
>

Maybe so, but there would seem to be a direct correlation between not
knowing enough to be sure what deisgn will work and not being able to
give a reasonably bounded estimate.  Is it really possible to assign
story points to a story where we are missing information so vital to
the design that we will need to spike on later?

In a software development approach where we give rough estimates to
stories before implementing them in order to facilitate the customer
driving business value, it is best to inform the customer of the need
for a spike at estimation time rather than later when we are just
about to try to implement it.  So, pragmatically, we can and should
recognize the need for spikes at story estimate time.

Futhermore, the decision whether or not to proceed with a spike is
best explained to the customer as an investment in better information
about the relative cost of implementing the story to facilitate better
release and iteration planning.

Steve

>  Dave
>

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com