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

Re: [XP] Spike stories - estimation and acceptance criteria ?

Expand Messages
  • James Grenning
    Yeah, like George says. thanks, James ... James Grenning Author of TDD for Embedded C www.renaissancesoftware.net http://pragprog.com/titles/jgade/
    Message 1 of 4 , Aug 24, 2013
    View Source
    • 0 Attachment
      Yeah, like George says.

      thanks, James

      --------------------------------------------------------------------------------------------
      James Grenning Author of TDD for Embedded C
      www.renaissancesoftware.net http://pragprog.com/titles/jgade/
      www.renaissancesoftware.net/blog
      www.twitter.com/jwgrenning

      On Aug 23, 2013, at 8:27 PM, George Dinwiddie wrote:

      > Ram,
      >
      > The purpose of a spike is to answer a question. Perhaps you're not sure
      > if a 3rd-party library will support the functionality you need. You
      > allocate how much time you're willing to spend and do just enough work
      > to answer the question. The spike is over when you run out of allocated
      > time, or you answer the question.
      >
      > If you run out of time, you want to make an explicit decision to budget
      > more time or to take a different approach.
      >
      > - George
      >
      > On 8/23/13 9:02 PM, Ram Srinivasan wrote:
      > > Hello Folks,
      > >
      > > My understanding is that there are 2 types of spikes - technical and
      > > functional. And that spike stories need not have an estimate (as they are
      > > time boxed to 1-2 days), and cannot be estimated (in story points), because
      > > it is research work, if we know what to do, we would build the feature and
      > > not do a spike. Is my understanding correct?
      > >
      > > Does Ron's 3Cs (Card, Confirmation, Conversation) apply to spike stories as
      > > well? Common sense tells me yes, and there is no harm. The acceptance
      > > criteria for a technical spike may be something like "the DB should be
      > > able to support 500K transactions without locking tables". Sometimes it may
      > > not be possible to have acceptance criteria, its research work, you are
      > > investigating it. I was looking at c2.com and xp123.com, but I could not
      > > find relevant material which could confirm my understanding
      > >
      > > Thanks,
      > > Ram
      > >
      > >
      > > [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.comYahoo! Groups Links
      > >
      > >
      > >
      > >
      >
      > --
      > ----------------------------------------------------------
      > * George Dinwiddie * http://blog.gdinwiddie.com
      > Software Development http://www.idiacomputing.com
      > Consultant and Coach http://www.agilemaryland.org
      > ----------------------------------------------------------
      >
      >



      [Non-text portions of this message have been removed]
    • Nancy Van Schooenderwoert
      Hi Ram, I agree with what George and James have said - and I d add that I have not heard of needing to treat technical spikes differently than functional
      Message 2 of 4 , Aug 25, 2013
      View Source
      • 0 Attachment
        Hi Ram,

        I agree with what George and James have said - and I'd add that I
        have not heard of needing to treat technical spikes differently than
        functional spikes.

        You ask if Ron Jeffries' 3Cs applies here - sure! The conversation
        should be to clarify just what question is being investigated, and what
        sort of time and other resources need to go into it.

        Packaging work into stories presupposes that we know what the work
        entails, and if we do then story points is a more intuitive estimation
        tool. (Well I think so, though there are good folks who prefer something
        else.)

        But if we don't know what is involved - because it's development and
        there are some things we need to figure out along the way - then I tell
        teams 'At least stay in control of your time'! As George said, budget
        the time you think it's worth and then be explicit about deciding
        whether you found out enough or should spend more time on that exploration.

        I have seen teams make a mistake with this advice. Basically they got
        so wrapped up in the investigation that they blew past their time box
        and couldn't complete other important work in that iteration. True, they
        weren't following the advice, but I mention it to acknowledge that the
        pursuit of new info can be awfully engaging, even addicting.

        - njv @vanschoo


        On 8/24/13 12:12 PM, James Grenning wrote:
        > Yeah, like George says.
        >
        > thanks, James
        >
        > --------------------------------------------------------------------------------------------
        > James Grenning Author of TDD for Embedded C
        > www.renaissancesoftware.net http://pragprog.com/titles/jgade/
        > www.renaissancesoftware.net/blog
        > www.twitter.com/jwgrenning
        >
        > On Aug 23, 2013, at 8:27 PM, George Dinwiddie wrote:
        >
        >> Ram,
        >>
        >> The purpose of a spike is to answer a question. Perhaps you're not sure
        >> if a 3rd-party library will support the functionality you need. You
        >> allocate how much time you're willing to spend and do just enough work
        >> to answer the question. The spike is over when you run out of allocated
        >> time, or you answer the question.
        >>
        >> If you run out of time, you want to make an explicit decision to budget
        >> more time or to take a different approach.
        >>
        >> - George
        >>
        >> On 8/23/13 9:02 PM, Ram Srinivasan wrote:
        >>> Hello Folks,
        >>>
        >>> My understanding is that there are 2 types of spikes - technical and
        >>> functional. And that spike stories need not have an estimate (as they are
        >>> time boxed to 1-2 days), and cannot be estimated (in story points), because
        >>> it is research work, if we know what to do, we would build the feature and
        >>> not do a spike. Is my understanding correct?
        >>>
        >>> Does Ron's 3Cs (Card, Confirmation, Conversation) apply to spike stories as
        >>> well? Common sense tells me yes, and there is no harm. The acceptance
        >>> criteria for a technical spike may be something like "the DB should be
        >>> able to support 500K transactions without locking tables". Sometimes it may
        >>> not be possible to have acceptance criteria, its research work, you are
        >>> investigating it. I was looking at c2.com and xp123.com, but I could not
        >>> find relevant material which could confirm my understanding
        >>>
        >>> Thanks,
        >>> Ram
        >>>
        >>>
        >>> [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.comYahoo! Groups Links
        >>>
        >>>
        >>>
        >>>
        >>
        >> --
        >> ----------------------------------------------------------
        >> * George Dinwiddie * http://blog.gdinwiddie.com
        >> Software Development http://www.idiacomputing.com
        >> Consultant and Coach http://www.agilemaryland.org
        >> ----------------------------------------------------------
        >>
        >>
        >
        >
        >
        > [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.comYahoo! Groups Links
        >
        >
        >
        >
        >

        --
        ............................................
        Agile hardware? Yes! Agile safety-critical Embedded Systems too

        Nancy Van Schooenderwoert, Lean-Agile Partners Inc.

        US mobile: 781 301 1822 nancyv@...
        Twitter: @vanschoo http://www.leanagilepartners.com
        ............................................
      Your message has been successfully submitted and would be delivered to recipients shortly.