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

Re: [scrumdevelopment] Re: User stories - has it worked for you?

Expand Messages
  • Michael Hofmann, b+m Informatik AG
    Hello Ron, ... ... hm ... maybe I didn t catch the sentence. Thus, I ll give a brave answer: yes. To my knowledge, there are several alternative usage paths
    Message 1 of 28 , Jul 31, 2006
      Hello Ron,


      Ron Jeffries schrieb:
      > > I should have better written: I can not imagine a situation where it is
      > > useful to deliver a half implemented use case. But, the PO should decide.
      >
      > Many use cases include a "happy path" and many exception paths. Are
      > your like that?
      >
      > Ron Jeffries
      ... hm ... maybe I didn't catch the sentence. Thus, I'll give a brave
      answer: yes. To my knowledge, there are several alternative usage paths
      and one main path for each use case.

      Regards,

      Michael
    • Ron Jeffries
      Hello b+m, Thanks for your email. On Monday, July 31, 2006, at 9:05:14 AM, you ... Then why is, say, just implementing the main path not a useful step to
      Message 2 of 28 , Jul 31, 2006
        Hello b+m,

        Thanks for your email. On Monday, July 31, 2006, at 9:05:14 AM, you
        wrote:

        > Ron Jeffries schrieb:
        >> > I should have better written: I can not imagine a situation where it is
        >> > useful to deliver a half implemented use case. But, the PO should decide.
        >>
        >> Many use cases include a "happy path" and many exception paths. Are
        >> your like that?
        >>
        >> Ron Jeffries
        > ... hm ... maybe I didn't catch the sentence. Thus, I'll give a brave
        > answer: yes. To my knowledge, there are several alternative usage paths
        > and one main path for each use case.

        Then why is, say, just implementing the main path not a useful step
        to deliver?

        Ron Jeffries
        www.XProgramming.com
        My advice is to do it by the book, get good at the practices, then do as
        you will. Many people want to skip to step three. How do they know?
      • Timothy H. Lund
        Whether or not it is useful to deliver only the main path would depend on the use case, I would think. My strategy using use cases has been to address them as
        Message 3 of 28 , Jul 31, 2006
          Whether or not it is useful to deliver only the main path would depend on the use case, I would think.
           
          My strategy using use cases has been to address them as a living form of requirements documentation during a sprint, and then baseline them (along with the code) at the end of the sprint. My QA guy does most of his testing a sprint behind and bases alot of it on the use cases. He receives both a nicely packaged version of the application and the corresponding use cases for the newly implemented features at the end of a sprint.
           
          Therefore, if it were useful to deliver "just the main path" for a sprint, that's the only thing that would be in the use case corresponding to a given feature at the end of the sprint. If the team decides to add an alternate scenario during a later sprint, they add that to the use cases and that functionality will be expected in the application also.
           
          It should be noted that I'm working in a smaller company where the development team is 9 recent CS grads who have a total of about 10-15 years experience between them. I chose use cases because I felt they would help show the value of exploring your requirements before jumping in and hacking, even if they are a bit more formal. It seems like most of you fight the opposite battle -- getting changes done where alot of people are set in their ways.
           
          ~Tim Lund
           


          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
          Sent: Monday, July 31, 2006 1:09 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Re: User stories - has it worked for you?

          Hello b+m,

          Thanks for your email. On Monday, July 31, 2006, at 9:05:14 AM, you
          wrote:

          > Ron Jeffries schrieb:
          >> > I should
          have better written: I can not imagine a situation where it is
          >> >
          useful to deliver a half implemented use case. But, the PO should decide.
          >>
          >> Many use cases include a "happy path" and many
          exception paths. Are
          >> your like that?
          >>
          >> Ron
          Jeffries
          > ... hm ... maybe I didn't catch the sentence. Thus, I'll give a
          brave
          > answer: yes. To my knowledge, there are several alternative usage
          paths
          > and one main path for each use case.

          Then why is, say, just implementing the main path not a useful step
          to deliver?

          Ron Jeffries
          www.XProgramming. com
          My advice is to do it by the book, get good at the practices, then do as
          you will. Many people want to skip to step three. How do they know?

        • Ron Jeffries
          Hello Timothy, Thanks for your email. On Monday, July 31, 2006, at 3:00:38 PM, you ... Yes. For example, if they didn t really want it ever to work,
          Message 4 of 28 , Jul 31, 2006
            Hello Timothy,

            Thanks for your email. On Monday, July 31, 2006, at 3:00:38 PM, you
            wrote:

            > Whether or not it is useful to deliver only the main path would depend
            > on the use case, I would think.

            <smile>
            Yes. For example, if they didn't really want it ever to work, then
            the main path wouldn't be useful.

            But otherwise ... it seems to me to be pretty useful in every case.
            </smile>
            >
            > My strategy using use cases has been to address them as a living form of
            > requirements documentation during a sprint, and then baseline them
            > (along with the code) at the end of the sprint. My QA guy does most of
            > his testing a sprint behind and bases alot of it on the use cases. He
            > receives both a nicely packaged version of the application and the
            > corresponding use cases for the newly implemented features at the end of
            > a sprint.

            Ah. Well, if you want to test a sprint behind, then I suppose
            tossing a bunch of paper (probably electronic but you get my point)
            over the wall to your QA guy is as good a way to do it as any.
            >
            > Therefore, if it were useful to deliver "just the main path" for a
            > sprint, that's the only thing that would be in the use case
            > corresponding to a given feature at the end of the sprint. If the team
            > decides to add an alternate scenario during a later sprint, they add
            > that to the use cases and that functionality will be expected in the
            > application also.

            Yes. I think the OP was talking about a full-on use case with all
            its paths ... in fact I think he verified that. In that case, I'd
            think that the main part of the case could be quite valuable.
            >
            > It should be noted that I'm working in a smaller company where the
            > development team is 9 recent CS grads who have a total of about 10-15
            > years experience between them. I chose use cases because I felt they
            > would help show the value of exploring your requirements before jumping
            > in and hacking, even if they are a bit more formal. It seems like most
            > of you fight the opposite battle -- getting changes done where alot of
            > people are set in their ways.

            Well ... if I were starting with recent graduates, I wouldn't choose
            to contaminate their minds with use cases, but instead would
            contaminate their minds with flexibility. That's because I don't
            recommend jumping in and hacking, I recommend jumping in and
            implementing in a professional manner.

            But to each his own ...

            Ron Jeffries
            www.XProgramming.com
            That's my opinion and I agree with it. -- Julio Santos
          • Timothy H. Lund
            I apologize if you thought I was trying to imply that using User Stories (or anything other than use cases) was jumping in and hacking. I simply meant to
            Message 5 of 28 , Jul 31, 2006
              I apologize if you thought I was trying to imply that using User Stories (or anything other than use cases) was "jumping in and hacking." I simply meant to imply that most straight-out-of-college CS grads have little to no exposure or appreciation for any type of requirements gathering. However, I would also suggest that the use of use cases (or any type of development tool) does not indicate a lack or presence of flexibility. The process by which you develop software, and how it adapts to the different and changing constraints on the software system you're trying to construct, is the only thing that REALLY determines flexibility, IMHO.
               
              ~Tim
               


              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
              Sent: Monday, July 31, 2006 5:38 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: Re: [scrumdevelopment] Re: User stories - has it worked for you?

              Hello Timothy,

              Thanks for your email. On Monday, July 31, 2006, at 3:00:38 PM, you
              wrote:

              > Whether or not it is useful to deliver
              only the main path would depend
              > on the use case, I would
              think.

              <smile>
              Yes. For example, if they didn't really want it ever to work, then
              the main path wouldn't be useful.

              But otherwise ... it seems to me to be pretty useful in every case.
              </smile>
              >
              > My strategy using use cases has been to address them as a living form
              of
              > requirements documentation during a sprint, and then baseline
              them
              > (along with the code) at the end of the sprint. My QA guy does most
              of
              > his testing a sprint behind and bases alot of it on the use cases.
              He
              > receives both a nicely packaged version of the application and
              the
              > corresponding use cases for the newly implemented features at the
              end of
              > a sprint.

              Ah. Well, if you want to test a sprint behind, then I suppose
              tossing a bunch of paper (probably electronic but you get my point)
              over the wall to your QA guy is as good a way to do it as any.
              >
              > Therefore, if it were useful to deliver "just the main path" for
              a
              > sprint, that's the only thing that would be in the use case
              >
              corresponding to a given feature at the end of the sprint. If the team
              >
              decides to add an alternate scenario during a later sprint, they add
              >
              that to the use cases and that functionality will be expected in the
              >
              application also.

              Yes. I think the OP was talking about a full-on use case with all
              its paths ... in fact I think he verified that. In that case, I'd
              think that the main part of the case could be quite valuable.
              >
              > It should be noted that I'm working in a smaller company where
              the
              > development team is 9 recent CS grads who have a total of about
              10-15
              > years experience between them. I chose use cases because I felt
              they
              > would help show the value of exploring your requirements before
              jumping
              > in and hacking, even if they are a bit more formal. It seems
              like most
              > of you fight the opposite battle -- getting changes done where
              alot of
              > people are set in their ways.

              Well ... if I were starting with recent graduates, I wouldn't choose
              to contaminate their minds with use cases, but instead would
              contaminate their minds with flexibility. That's because I don't
              recommend jumping in and hacking, I recommend jumping in and
              implementing in a professional manner.

              But to each his own ...

              Ron Jeffries
              www.XProgramming. com
              That's my opinion and I agree with it. -- Julio Santos

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