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

Re: Acceptance criteria in User Stories

Expand Messages
  • Geir Amsjo
    Thanks for the good advice. I guess we will try to wait as log as possible to break down the epics. We are not exactly shure how to handle the hiarchy of User
    Message 1 of 4 , Sep 11, 2008
    • 0 Attachment
      Thanks for the good advice. I guess we will try to wait as log as
      possible to break down the epics. We are not exactly shure how to
      handle the hiarchy of User Stories in excel then.. But that is
      solvable of course.

      -geir



      --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...>
      wrote:
      >
      > A question, comment, about User Stories.
      >
      > Is it a reasonable 'rule of thumb' to suggest that if the
      words 'and' and 'or' appear in the User Story, then the User Story
      could be split?
      > This was a useful suggestion when talking about programmed
      functions and procedures. If you were describing the function and
      included 'and' (maybe not so much 'or') then you were probable
      talking about a multi-purpose function, thus not fully cohesive, and
      two functions should be written. If you then wanted to .and. the
      functions together in your code, then just call the 2 functions
      sequentially.
      >
      > I try to apply the 'old' ideas of coupling and cohesion to entity
      modelling (an entity should be fully cohesive, and any coupling must
      be done exclusively through a relationship). Perhaps the same
      thinking can be applied to User Stories.
      >
      > What say you?
      >
      > Regards,
      > Roy Morien
      >
      >
      >
      > To: scrumdevelopment@...: mike@...: Tue, 9 Sep 2008 12:22:11 -
      0600Subject: Re: [scrumdevelopment] Acceptance criteria in User
      Stories
      >
      >
      >
      >
      > Congratulations on what sounds like a productive meeting and a good
      start with user stories.
      >
      > One of the best ways is to keep the larger stories intact until its
      necessary to work on them. If you split the story up in a more real-
      time manner you'll be less likely to forget the big picture reason
      behind the smaller stories.
      >
      > Regards,
      >
      >
      >
      >
      > Mike Cohn
      > Author:
      > Agile Estimating and Planning
      > User Stories Applied
      > www.mountaingoatsoftware.com
      >
      > On Sep 9, 2008, at 11:03 AM, Geir Amsjo wrote:
      >
      >
      >
      >
      >
      > With a lot of enthusiasm we have spent the day defining User
      Stories for the first time. For every story we also define acceptence
      criteria. The overall experience is positive, but we have discussed
      the relationshop between the "effect part" and the acceptance
      criteria. When we break down epics into stories the "So that" part
      becomes very detailed and concrete. We sort of miss the overall goal.
      Does anybody have a good advice to not miss the overall goal?BR Geir
      >
      >
      >
      >
      >
      >
      > _________________________________________________________________
      > Are you paid what you're worth? Find out: SEEK Salary Centre
      > http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%
      2Ecom%2Eau%2Fcareer%2Dresources%2Fsalary%2Dcentre%2F%3Ftracking%3Dsk%
      3Ahet%3Asc%3Anine%3A0%3Ahot%
      3Atext&_t=764565661&_r=OCT07_endtext_salary&_m=EXT
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.