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

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

Expand Messages
  • George Dinwiddie
    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
    Message 1 of 4 , Aug 23 6:27 PM
    • 0 Attachment
      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
      ----------------------------------------------------------------------
    • 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 2 of 4 , Aug 24 9:12 AM
      • 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 3 of 4 , Aug 25 1:02 PM
        • 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.