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

Opinion on user story detail...

Expand Messages
  • Casey Manus
    All, Our team is starting our first real project with Scrum. We are preparing to coach our business owners on user stories and what we expect from a user
    Message 1 of 6 , Jan 30, 2007
    • 0 Attachment
      All,

      Our team is starting our first real project with Scrum. We are
      preparing to coach our business owners on user stories and what we
      expect from a user story.

      As a team, we are struggling to find the "sweet spot" for acceptance
      criteria as part of the story....consider these two examples:

      Example 1:
      A practice adminstrator needs to be able to search for practices to
      view practice settings.

      Acceptance Criteria:
      * verify that the user can search by practice name, city and
      zipcode
      * verify that the result set can be sorted by any field
      * verify that the result set can be printed with the chosen sort
      applied
      * verify that a search by name contains any instance of a
      practices name "containing" the search by name criteria ie, like %
      criteria%

      Or Example 2:
      A practice adminstrator needs to be able to search for practices
      to
      view practice settings.

      Acceptance Criteria:
      * verify search results
      * verify results are printable


      I know these are pretty trivial examples, but that gives you an idea
      of the detail level we are struggling with. Any feed back would be
      greatly appreciated.
    • Casey Manus
      I think there is maybe another another level of detail to consider, not at the accetance criteria area, but at the story level itself. Maybe the story should
      Message 2 of 6 , Jan 30, 2007
      • 0 Attachment
        I think there is maybe another another level of detail to consider, not
        at the accetance criteria area, but at the story level itself.

        Maybe the story should be broken down into multiple stories.

        The geographic practice searcher needs to be able to search for
        practices within a zip/code to find local practices.

        The practice searcher needs to be able to search for practices by name
        to find a specific practice

        etc....
      • Steven Gordon
        Casey, I prefer example 1. Do note that the detail of the acceptance criteria should evolve over time. In other words, the product owner: - should not let an
        Message 3 of 6 , Jan 30, 2007
        • 0 Attachment
          Casey,

          I prefer example 1.

          Do note that the detail of the acceptance criteria should evolve over
          time. In other words, the product owner:
          - should not let an inability to come up with sufficiently detailed
          acceptance criteria become a blockage or consume too much of their
          time,
          - should expect that the planning session for the sprint in which the
          story is scheduled to be worked on will include discussions with the
          developers that will usually lead to changes in the acceptance
          criteria and an increase in specificity.

          Steve

          On 1/30/07, Casey Manus <caseymanus@...> wrote:
          >
          >
          >
          >
          >
          >
          > All,
          >
          > Our team is starting our first real project with Scrum. We are
          > preparing to coach our business owners on user stories and what we
          > expect from a user story.
          >
          > As a team, we are struggling to find the "sweet spot" for acceptance
          > criteria as part of the story....consider these two examples:
          >
          > Example 1:
          > A practice adminstrator needs to be able to search for practices to
          > view practice settings.
          >
          > Acceptance Criteria:
          > * verify that the user can search by practice name, city and
          > zipcode
          > * verify that the result set can be sorted by any field
          > * verify that the result set can be printed with the chosen sort
          > applied
          > * verify that a search by name contains any instance of a
          > practices name "containing" the search by name criteria ie, like %
          > criteria%
          >
          > Or Example 2:
          > A practice adminstrator needs to be able to search for practices
          > to
          > view practice settings.
          >
          > Acceptance Criteria:
          > * verify search results
          > * verify results are printable
          >
          > I know these are pretty trivial examples, but that gives you an idea
          > of the detail level we are struggling with. Any feed back would be
          > greatly appreciated.
        • Wolfgang Schulze Zachau
          I would like to suggest that this is a very good example for the usage of FIT/Fitnesse. The developers build the test framework and the product owners can then
          Message 4 of 6 , Jan 30, 2007
          • 0 Attachment
            I would like to suggest that this is a very good example for the usage of FIT/Fitnesse. The developers build the test framework and the product owners can then fill it with their own test data. On a programmer's level you would probably want some unit testing (i.e. making sure that from a given set of practices that are populated at the start of the test, a given search will return a defined set of practices, etc.), but on the user acceptance leve, this can easily become too technical.
            This approach is particularly useful if the product owner/customers are not entirely sure that they know exactly where to draw the line. They can use this to play around with the test settings and eventually they will have figure out what a useful set of tests/results is. That can then be documented as the basis for the future.
             

            Regards,

            Wolfgang

          • Ron Jeffries
            Hello, Casey. I don t understand what the difference is between your two examples. On Tuesday, January 30, 2007, at 8:24:58 AM, you ... Ron Jeffries
            Message 5 of 6 , Jan 30, 2007
            • 0 Attachment
              Hello, Casey. I don't understand what the difference is between your
              two examples. On Tuesday, January 30, 2007, at 8:24:58 AM, you
              wrote:

              > Our team is starting our first real project with Scrum. We are
              > preparing to coach our business owners on user stories and what we
              > expect from a user story.

              > As a team, we are struggling to find the "sweet spot" for acceptance
              > criteria as part of the story....consider these two examples:

              > Example 1:
              > A practice adminstrator needs to be able to search for practices to
              > view practice settings.

              > Acceptance Criteria:
              > * verify that the user can search by practice name, city and
              > zipcode
              > * verify that the result set can be sorted by any field
              > * verify that the result set can be printed with the chosen sort
              > applied
              > * verify that a search by name contains any instance of a
              > practices name "containing" the search by name criteria ie, like %
              > criteria%

              > Or Example 2:
              > A practice adminstrator needs to be able to search for practices
              > to
              > view practice settings.

              > Acceptance Criteria:
              > * verify search results
              > * verify results are printable


              > I know these are pretty trivial examples, but that gives you an idea
              > of the detail level we are struggling with. Any feed back would be
              > greatly appreciated.



              Ron Jeffries
              www.XProgramming.com
              Design is the thinking one does before, during, and after
              implementation. It works best for me with a little up front, most of
              it during implementation, and very little after it's too late.
            • mpkirby
              ... If the question is whether or not to have more detail (like example 1) in test cases, or less detail (like example 2), then the answer is must definitely
              Message 6 of 6 , Feb 1, 2007
              • 0 Attachment
                Casey Manus wrote:
                > All,
                >
                > Our team is starting our first real project with Scrum. We are
                > preparing to coach our business owners on user stories and what we
                > expect from a user story.
                >
                > As a team, we are struggling to find the "sweet spot" for acceptance
                > criteria as part of the story....consider these two examples:
                >
                > [SNIP ]
                >
                >
                > I know these are pretty trivial examples, but that gives you an idea
                > of the detail level we are struggling with. Any feed back would be
                > greatly appreciated.
                >
                If the question is whether or not to have more detail (like example 1)
                in test cases, or less detail (like example 2), then the answer is must
                definitely 1.

                Think of it this way. Perhaps you do manual testing right now. Sure,
                we could use verbal communication so the tester knows what to test.
                Then he gets hit by a truck, and you decide to automate your tests to
                avoid that happening again. There's no way to do that now. The
                knowledge of the detail of the last 2 years of tests were in his head.

                Are you going to go back to the product owner? They'll say "do what the
                program does now." That's never a good idea (getting test cases from
                your application's apparent behavior).

                Put the detail in the test cases, automate if possible. Don't put them
                in the stories. And further, try to avoid extraordinary detail on UI
                operability unless it's critical to the success of the feature (e.g.
                like the iphone's test cases might have been).

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