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

RE: [XP] Problems with story splitting

Expand Messages
  • Charlie Poole
    Hi Manuel, I ve been given big specs. Some people feel that doing a planning game to create stories is a waste of time in such a situation. I don t. It s as if
    Message 1 of 20 , Sep 28, 2007
      Hi Manuel,

      I've been given big specs. Some people feel that doing a planning game
      to create stories is a waste of time in such a situation. I don't.

      It's as if you were given a large set of data, collected in various
      ways and recorded in different formats. You might spend time putting
      it all together as a graph or chart, just so you could understand it.

      Everything you are saying about your requirements below seems to
      indicate that they are not in a useful form, so creating stories
      explicitly might be just what you need.

      Doing this for a 300 page requirements doc on one occasion took
      us two days. Most stories echoed the requirements - we even stapled
      a cut-out strip from the document to the cards. But we ended up
      with 140 completely new stories. The Customer, of course, didn't
      think they were new - they were covered by his reading of the
      requrements doc. But they were definitely new in the sense that
      we wouldn't have implemented them if we hadn't found them.

      You can't split stories if you don't have stories.

      Charlie

      Charlie

      > -----Original Message-----
      > From: extremeprogramming@yahoogroups.com
      > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Manuel Klimek
      > Sent: Thursday, September 27, 2007 1:29 PM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: [XP] Problems with story splitting
      >
      > Hi,
      >
      > thanks for all your input.
      >
      > The problem with slicing horizontally is, well, that is how
      > we do it, but my question targeted at how to do it vertically
      > (I didn't say so, silly me :-)
      >
      > With regards to slicing it vertically: the "good case" is
      > easy. It's more or less trivial and that's exactly the
      > problem. Those 500 page specs are about "special cases". Now
      > that I write this I realize that perhaps this is exactly how
      > we /are/ splitting the story, though implicitly, not by
      > putting it on a card up-front. Which would be rather hard.
      >
      > The problem is that we seem slice the story the way the spec
      > is written. Mostly because nobody can memorize the whole spec.
      > So we usually do something like:
      > "Hey, are we sure that XY works correctly?" - "Oh, no, let's
      > grep the spec" - "Wow, here, on page 625 it says that if X we
      > must do Y, and look here, I think we didn't consider this,
      > too" - "What transactions are affected?"
      > "Payment, Reversal, and Tip, oh no, wait, not for tip, it
      > says for Tip chapter 3.5.3.2.3.2.1 is used"
      > "Well, let's do that later. So we need to implement this in
      > the process and call it for payment and reversal transactions..."
      >
      > If I'd read the spec up front to find out how to slice it up
      > in stories like "react with the correct error message, if the
      > card responds with a <insert silly TLA here> byte on the
      > authorize command for Payment and Reversal transactions", I'd
      > have forgotten all the silly details when I finally get to
      > implement it and would have to re-read the spec. Furthermore
      > we'd end up with lots of stories I'd consider too small, or
      > perhaps we just need a bigger story board? :-)
      >
      > I hope I could describe the problem more clearly.
      >
      > Cheers,
      > Manuel
      >
      > --
      > http://klimek.box4.net
      >
      >
      > [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
      >
      >
      >
      >
    • George Dinwiddie
      ... Why would he not look at those tests to understand, rather than going back to the spec? Are the tests not expressive enough to communicate? - George --
      Message 2 of 20 , Sep 28, 2007
        On Fri, September 28, 2007 12:09, Manuel Klimek wrote:
        > Cory,
        >
        > On 9/28/07, Cory Foy <usergroup@...> wrote:
        >> > the spec is not an API. The spec is a requirement document. There
        >> > are many specs each having many hundred pages of requirements.
        >>
        >> And who is the expert on the spec? Does every developer have to become
        >> an expert on the spec in order to do meaningful work?
        >
        > Yes. Otherwise he will add some new tests and change some code
        > and then wonder why half the other tests broke.

        Why would he not look at those tests to understand, rather than going back
        to the spec? Are the tests not expressive enough to communicate?

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Manuel Klimek
        George, ... Obviously they re not expressive enough :-) The problem is that when old tests break the probability that: - the old test is wrong - the new code
        Message 3 of 20 , Sep 29, 2007
          George,

          On 9/28/07, George Dinwiddie <lists@...> wrote:
          > Why would he not look at those tests to understand, rather than going back
          > to the spec? Are the tests not expressive enough to communicate?

          Obviously they're not expressive enough :-)
          The problem is that when old tests break the probability that:
          - the old test is wrong
          - the new code is wrong
          is about 50%.

          The specs are so ambiguous, coupled and non-orthogonal that it's
          so easy to misinterpret them.

          Manuel

          --
          http://klimek.box4.net
        • Daniel Wildt
          Agree. The team should be used to learn the application from the tests. If they can t, you can be sure that the code coverage from the unit tests is not as the
          Message 4 of 20 , Sep 29, 2007
            Agree.

            The team should be used to learn the application from the tests.

            If they can't, you can be sure that the code coverage from the unit tests is not as the expected from the team. If the tests are
            breaking, even worst.

            As a customer working in an Agile environment, I want to write testable specifications, so that development teams and acceptance
            test teams que easily prove the spects through the code being developed.

            Regards,
            Daniel Wildt
            http://danielwildt.blogspot.com



            > -----Mensagem original-----
            > De: extremeprogramming@yahoogroups.com
            > [mailto:extremeprogramming@yahoogroups.com] Em nome de Manuel Klimek
            > Enviada em: sábado, 29 de setembro de 2007 10:36
            > Para: extremeprogramming@yahoogroups.com
            > Assunto: Re: [XP] Problems with story splitting
            >
            > George,
            >
            > On 9/28/07, George Dinwiddie <lists@...> wrote:
            > > Why would he not look at those tests to understand, rather
            > than going
            > > back to the spec? Are the tests not expressive enough to
            > communicate?
            >
            > Obviously they're not expressive enough :-) The problem is
            > that when old tests break the probability that:
            > - the old test is wrong
            > - the new code is wrong
            > is about 50%.
            >
            > The specs are so ambiguous, coupled and non-orthogonal that
            > it's so easy to misinterpret them.
            >
            > Manuel
            >
            > --
            > http://klimek.box4.net

            No virus found in this outgoing message.
            Checked by AVG Free Edition.
            Version: 7.5.488 / Virus Database: 269.13.33/1036 - Release Date: 28/09/2007 15:40
          • Steven Gordon
            So, how else could you possibly figure out whether the spec is being interpretted correctly? I cannot think of a more effective way to evolve a consistent
            Message 5 of 20 , Sep 29, 2007
              So, how else could you possibly figure out whether the spec is being
              interpretted correctly?

              I cannot think of a more effective way to evolve a consistent
              interpretation than having tests that break whenever the spec is being
              interpretted in contradictory ways. Granted, you actually have to do
              some thinking/researching to figure out which test represents the
              intended interpretation. A domain expert is indispensable at those
              times.

              At each point in time, you will have the most evolved interpretation
              specified in a way that can be verified.


              On 9/29/07, Manuel Klimek <klimek@...> wrote:
              >
              >
              >
              >
              >
              >
              > George,
              >
              > On 9/28/07, George Dinwiddie <lists@...> wrote:
              > > Why would he not look at those tests to understand, rather than going
              > back
              > > to the spec? Are the tests not expressive enough to communicate?
              >
              > Obviously they're not expressive enough :-)
              > The problem is that when old tests break the probability that:
              > - the old test is wrong
              > - the new code is wrong
              > is about 50%.
              >
              > The specs are so ambiguous, coupled and non-orthogonal that it's
              > so easy to misinterpret them.
              >
              > Manuel
              >
              > --
              > http://klimek.box4.net
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.