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

Re: [XP] What to do when breaking down 5 stories takes a whole day?

Expand Messages
  • Jeff Grigg
    ... Now be prepared for the product manager to insist that there is /no possible way/ to deliver the product until /all/ the scenarios are /fully completed/.
    Message 1 of 256 , Apr 2, 2008
      --- "Steven Gordon" <sgordonphd@...> wrote:
      > For example, if the epic was "book a family vacation",
      > scenarios in order of complexity might include:
      > 1. rent a round-trip car at default rates from destination
      > to destination and being billed later (booking no hotels,
      > no air, no train, and no sites),
      > 2. rent a round-trip car at default rates from destination
      > to destination, booking 1 hotel stay and 1 amusement
      > park using paypal,
      > 3. book round-trip air travel from source to destination,
      > rent a local car at destination book 1 hotel stay, and
      > 1 amusement park using a combination of paypal and
      > credits from previous travel,
      > ...
      > and so on, adding additional hotel stays, legs of travel
      > and sites of various sorts using various other ways of paying.

      Now be prepared for the product manager to insist that there is /no
      possible way/ to deliver the product until /all/ the scenarios
      are /fully completed/. That's fine; we'll say the scenarios are
      needed for development and testing.

      And then when we get near the end of an iteration and find that we
      can't get it all done, and "they" demand a "solution" from us
      of "what we're going to do about it," show them the scenarios that do
      and work, and offer to let them select some scenarios that haven't
      been done yet to drop.

      They might still refuse to deliver the product to end users. They
      might even refuse to look at the product at all. But that's their
      choice. We are not preventing them from testing or using or
      releasing the product. It may sometimes make business sense for them
      to make a business decision to defer receiving available value from
      their business investment -- even to defer receiving and providing
      feedback -- due to other pressing priorities, for instance.

      On the other hand, this opens the door to higher business agility.
      They might choose to come through the door.
    • Niraj Khanna
      Hi Unmesh, Sorry for not responding in over 1 month. We were away on vacation. ... I think what you re describing maybe a symptom or practice of why some
      Message 256 of 256 , May 8, 2008
        Hi Unmesh,

        Sorry for not responding in over 1 month. We were away on vacation.
        > So to measure success or failure of "Agile" transition is to measure
        > if people are thinking for themselves, rather than blindly following
        > agile coach's advice and running behind agile buzzword. How can we
        > measure that?
        >

        I think what you're describing maybe a symptom or practice of why some
        agile transitions "succeed" over others that "fail". I'm just
        interested in measuring whether it succeeds or fails. A secondary and
        more useful study would be "why do agile transitions succeed/fail".
        Finally, to be quite honest, I wouldn't be surprised to see "Blindly
        following agile manual" in either the "success" or "failure" camp. I
        think Ron has discussed practicing all the XP practices before
        deciding which ones to drop, but I can also see how practicing and
        applying practices without an understanding of expected benefits
        coulod lead to adoption failure.

        Thanks,
        Niraj.
      Your message has been successfully submitted and would be delivered to recipients shortly.