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
  • Steven Gordon
    Instead of attempting a functional or structural breakdown of an epic, try splitting epics into distinct, specific, end-to-end scenarios. Typically, the first
    Message 1 of 256 , Apr 1, 2008
    • 0 Attachment
      Instead of attempting a functional or structural breakdown of an epic,
      try splitting epics into distinct, specific, end-to-end scenarios.

      Typically, the first scenario will allow many components to simply be
      hard-coded, so you can prove out in a short period of time the
      component architecture and the intended functionality in software that
      only works for a specific scenario. Then, after getting feedback to
      clear up any misunderstandings about the intended functionality, you
      can proceed to implement more scenarios in customer priority order.
      Each scenario will require fleshing out some of the components
      further. This keeps the stories vertical slices instead of just
      working on horizontal components divorced from visible business value.
      Eventually, most of the scenarios not yet developed will already be
      working (or very nearly so) when you get to them.

      This approach not only makes it easier and faster to break down
      stories, but it also makes it easier to write the automated acceptance
      tests, know whether or not development is done on each story,
      facilitates attaining a steady velocity, and allows the customer more
      flexibility in driving the project (important scenarios of a totally
      undeveloped epic may be higher priority than the final few scenarios
      of an ongoing epic).

      Steven Gordon

      On Tue, Apr 1, 2008 at 8:08 AM, Kristoffer Roupe
      <kristoffer.roupe@...> wrote:
      >
      >
      >
      >
      >
      >
      > Hi all!
      >
      > I've just come out of a sprint planning meeting here (yesterday) where we
      > spent almost 1h/story in break downs. Now, we are a 12 man team, thinking of
      > splitting in 2, just to get some better output. One of our main issues is
      > that we have about 7-8 products that is in development. Which makes about 1
      > product per 2 man team! Surely enough this becomes an issue, we context
      > switch a lot, and that takes time.
      >
      > Now, our product owners /customers are quite new to storytelling, so they
      > do produce epics. We try to narrow them down, but that (I guess) is one of
      > the reasons why break down takes such a long time... we just can't
      > understand how the heck to do the stories. Yesterday, the PO's was out of
      > office, so that being a sprint planning day just made thing even worse; we
      > had no one to ask.
      >
      > Now, back to the main object (not me crying over how bad we did), how do I
      > get my product owner to start splitting her stories? We've tried to educate
      > our product owners about how to write a proper story, and that it shouldn't
      > be to "big". We've also introduced a quick "estimation calculation" that
      > gives them a hint about the overall complexity of the story. So that we
      > don't have to break it down first. But they just keep ignoring our demands
      > on "breaking them down into smaller parts". One of the arguments heard from
      > PO's is that they lose the eagle eye view when things get to small. This is
      > understandable, so I'm in the writing of a small wiki-topic about "release
      > planning", just to get them started. But I feel that this might just not be
      > enough!
      >
      > This is why I now ask you guys. Because I know that there's a lot of people
      > on this list that have more experience than me on XP/Scrum/Agile/Lean etc.
      > and I'm eager to know if there's some "hidden tricks" out there that I could
      > use.
      >
      > If I'm just blathering here, please let me know.
      >
      > Kristoffer Roupé
      >
      > Lead Programmer
      >
      > Cint AB
      >
      > Torsgatan 8
      >
      > SE111 23 STOCKHOLM, Sweden
      >
      > Mobile: +46 70 487 72 03
      >
      > e-mail: kristoffer.roupe@... <mailto:kristoffer.roupe@...>
      >
      > webb: www.cint.com <http://www.cint.com/>
      >
      > It is dangerous to be right when the government is wrong - Voltaire
      >
    • 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
      • 0 Attachment
        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.