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

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

Expand Messages
  • 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 1 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.

      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

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

      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.
      > My strategy using use cases has been to address them as a living form
      > requirements documentation during a sprint, and then baseline
      > (along with the code) at the end of the sprint. My QA guy does most
      > his testing a sprint behind and bases alot of it on the use cases.
      > receives both a nicely packaged version of the application and
      > 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
      > 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
      > development team is 9 recent CS grads who have a total of about
      > years experience between them. I chose use cases because I felt
      > would help show the value of exploring your requirements before
      > 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.