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

RE: [scrumdevelopment] UseCases in the Backlog / WAS: Requirements for Mission Critical systems

Expand Messages
  • Mike Beedle
    ... Mike, Well, because the explanation of the Backlog Item in the product backlog can also be written like this: As a , I want to so
    Message 1 of 26 , May 31, 2005
    • 0 Attachment
      Mike Cohn wrote:
      > I don't understand your comment about true Scrummers should not
      > bother with either but should instead write "longish but concise
      > comment/explanation."

      Mike,

      Well, because the explanation of the Backlog Item in the product backlog can
      also be written like this:

      "As a <type of user>, I want to <goal> so that <reason>."

      My point is that as long as the UCs, stories, or backlog items are written
      following the same principles, it really doesn't matter how we call them.

      The documentation should be a concise, descriptive, goal-oriented,
      value-driven statement that states what a user wants or needs,

      - Mike
    • David A Barrett
      I wanted to go back to the original question; because I thought it was interesting in itself and I m not sure that the point of it wasn t missed. To me, the
      Message 2 of 26 , Jun 1, 2005
      • 0 Attachment
        I wanted to go back to the original question; because I thought it was
        interesting in itself and I'm not sure that the point of it wasn't missed.

        To me, the key factor was that the system was very low in user interface.
        This makes it difficult to write User Stories because so much of the
        specific things that need to happen are out of control of the user, or are
        hidden from them.

        So I was wondering, do the "users" in User Stories need to be people?
        Could you write a User Story that treats external systems and internal
        modules as "users"? Something like, "In order to notify the dispach
        processor of a completed request, the xyz system can send a request for a
        routing priority when the abc module is fully commited"?

        Am I crazy?


        Dave Barrett,
        Lawyers' Professional Indemnity Company
      • David Roberts
        Mitch, I agree that actor goal driven statements is a wonderful thing. It s nice to see someone from MS on this group :-) David Roberts InnovaSystems Intl
        Message 3 of 26 , Jun 1, 2005
        • 0 Attachment
          Re: [scrumdevelopment] UseCases in the Backlog / WAS: Requirements for Mission Critical systems

          Mitch,

           

          I agree that actor goal driven statements is a wonderful thing. It’s nice to see someone from MS on this group J

           

          David Roberts

          InnovaSystems Intl

          (619) 955-5864

           


          From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Mitch Lacey
          Sent: Tuesday, May 31, 2005 7:48 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] UseCases in the Backlog / WAS: Requirements for Mission Critical systems

           

          I was asked the question today, again, “why user stories – why not use cases in your project?”  Please keep in mind that a couple of years ago I was writing use cases like nobody's business, and became one of the key change agents in our organization to adopt use cases.

           

          Since moving to agile methodologies (Scrum/XP primarily) and adopting user stories, I have found that user stories are essential, and use cases help work out the bugs of the user stories.

           

          So that's all great, you say, but what is really mean?  Let me give you an example.  Our current product backlog has roughly 150 stories on it.  As the team bites off chunks, I (product owner) work with both the team in the stakeholders to identify key risks in the stories being worked on.  I couple is closely with user level use cases.  One of the key tools I use in identifying risks is listing out the exceptions on a Whiteboard in a use case type format.  The team then gets this "ahh" sensation, asks me a couple of questions, and then has enough information to continue working.

           

          I will take a photo of the use case on the Whiteboard, put it on our Wiki, and go back to other project work.

           

          Mitch Lacey

          Microsoft Corporation

          Converting our Company One Developer at a Time.

           

          PS - Mike's preferred user story format listed below is great.  I love it, the team loves it and most importantly are stakeholders love it.  J

           


          From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Mike Cohn
          Sent: Tuesday, May 31, 2005 6:11 PM
          To: Scrumdevelopment
          Subject: Re: [scrumdevelopment] UseCases in the Backlog / WAS: Requirements for Mission Critical systems

           

          Cockburn describes “use case narratives” in his Effective Use Cases book. These are close to Jacobsen’s description. Constantine describes “essential use cases” which are not quite as lightweight.

          I don’t understand your comment about true Scrummers should not bother with either but should instead write “longish but concise comment/explanation.”

          My preferred form for a user story is:

          “As a <type of user>, I want to <goal> so that <reason>.”

          That gives me a product backlog of similar sentences that I can read quickly and that the product owner can prioritize easily. Each sentence gives me a view of who it is that wants it, what they want and why they want it. It works wonderfully well.


          Mike Cohn
          Author of User Stories Applied for Agile Software Development
          www.mountaingoatsoftware.com


          On 5/31/05 2:07 PM, "Mike Beedle" <beedlem@...> wrote:


          Curiously, when Kent Beck wrote his first Extreme Programming book, the only reference to
          User Stories he provided was Ivar’s OOSE book, and the examples in Ivar’s book are closer
          to User Stories than they are to what we know as Use Cases now.
           
          Unfortunately, “Use Cases” as we know them now tend to be largish documentation – all useful,
          but somewhat distracting to get “executable releases”, specially in largish companies, where
          one can spend *months* getting the use case templates, the use cases, the use case packages,
          and of course in hiring and/or training the use case analysts ;-).
           
          Simply put User Stories are Ivar’s Use Cases so I would do User Stories instead:
           
                      Concentrate in getting working code not documents done!
           
          Now, if you are a true Scrummer, don’t bother with either, just write a longish but concise
          comment/explanation on the Product Backlog and you are done documenting stuff, because
          as you well know, the real requirements don’t come up until the user looks at some version of the
          system anyhow:
           
                      so produce software and get feedback on barely-enough-defined requirements
           
          is more or less the Scrum-mode,
           
          - Mike
           


          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of David Roberts
          Sent: Tuesday, May 31, 2005 2:27 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] UseCases in the Backlog / WAS: Requirements for Mission Critical systems

          Deb,
           
          I think that’s a good idea. On my project, we just do use cases as backlog items, and tasks/technical features as sprintlog items. I think it could go either way depending on your iteration and problem sizes.
           

          David Roberts
          InnovaSystems Intl
          (619) 955-5864
           


          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Deb
          Sent: Tuesday, May 31, 2005 11:12 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] UseCases in the Backlog / WAS: Requirements for Mission Critical systems

          I've been wondering about UseCases, too. I know they can be done at
          different levels of granularity - but I was thinking that one UC could
          spawn multiple stories. In this case, UCs could be product backlog
          items, and Stories could be sprint backlog items. And as we a given UC
          into sprints, some stories might go into the next sprint, and others
          not, so you'd have that increase in granularity one would expect at
          the top of the product backlog...

          Anyone done this? Is there already a thread here on this?

          thanks
          deb

          --- In scrumdevelopment@yahoogroups.com , " David Roberts "
          <droberts@i...> wrote:

          > Mike,

          > Assuming that user stories are your "framework" for requirements, could
          > you create a story called: "Do this Use Case" then document the
          > requirements as a use case.
          > ...
          > David Roberts





          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


          Yahoo! Groups Links

           




          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



        • David Roberts
          Mike, If we choose to care, my understanding was that stories can range from all levels, where as use cases (in the Cockburn methodology) have defined levels,
          Message 4 of 26 , Jun 1, 2005
          • 0 Attachment

            Mike,

             

            If we choose to care, my understanding was that stories can range from all levels, where as use cases (in the Cockburn methodology) have defined levels, ala summary->user-goal. I find constraining user-goal level use cases to elementary business process a useful aspect of use cases. Is there such a guideline for user stories?

             

            David Roberts

            InnovaSystems Intl

            (619) 955-5864

             


            From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Mike Beedle
            Sent: Tuesday, May 31, 2005 9:43 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] UseCases in the Backlog / WAS: Requirements for Mission Critical systems

             


            David Roberts wrote:
            > Where I'm as, we write use cases in a low-precision format.

            David,

            Good, then you are closer to stories then.  In most large corporate
            environments, UCs now range from 5 - 25 pages, way too long to be agile. 
            (I have worked with a myriad of templates that are in many cases even
            longer.)

            David Roberts wrote:
            > I think the principles you've defined can be kept in mind regardless of
            > whether you use use cases or user stories.

            I agree.

            As long as we use the same principles, in the end it doesn't matter how we
            call things, Use Cases, Stories or Backlog Items, if they convey the same
            information.

            - Mike




            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



          • Ron Jeffries
            ... User stories doesn t mean GUI users. ... Tell us what this system does. Who wants it, what do they want it to do? ... Quite possibly. I, on the other hand,
            Message 5 of 26 , Jun 1, 2005
            • 0 Attachment
              On Wednesday, June 1, 2005, at 9:55:44 AM, David A Barrett wrote:

              > I wanted to go back to the original question; because I thought it was
              > interesting in itself and I'm not sure that the point of it wasn't missed.

              > To me, the key factor was that the system was very low in user interface.
              > This makes it difficult to write User Stories because so much of the
              > specific things that need to happen are out of control of the user, or are
              > hidden from them.

              User stories doesn't mean GUI users.

              > So I was wondering, do the "users" in User Stories need to be people?
              > Could you write a User Story that treats external systems and internal
              > modules as "users"? Something like, "In order to notify the dispach
              > processor of a completed request, the xyz system can send a request for a
              > routing priority when the abc module is fully commited"?

              Tell us what this system does. Who wants it, what do they want it to
              do?

              > Am I crazy?

              Quite possibly. I, on the other hand, have release papers certifying
              that I am not. Nanner nanner.

              Ron Jeffries
              www.XProgramming.com
              Show me the features!
            • Mike Cohn
              I see no reason at all not to write stories where another system is the user. I ve done that many times. Mike Cohn Author of User Stories Applied for Agile
              Message 6 of 26 , Jun 1, 2005
              • 0 Attachment
                I see no reason at all not to write stories where another system is the
                user. I've done that many times.


                Mike Cohn
                Author of User Stories Applied for Agile Software Development
                www.mountaingoatsoftware.com


                On 6/1/05 7:55 AM, "David A Barrett" <dave.barrett@...> wrote:

                >
                >
                >
                >
                > I wanted to go back to the original question; because I thought it was
                > interesting in itself and I'm not sure that the point of it wasn't missed.
                >
                > To me, the key factor was that the system was very low in user interface.
                > This makes it difficult to write User Stories because so much of the
                > specific things that need to happen are out of control of the user, or are
                > hidden from them.
                >
                > So I was wondering, do the "users" in User Stories need to be people?
                > Could you write a User Story that treats external systems and internal
                > modules as "users"? Something like, "In order to notify the dispach
                > processor of a completed request, the xyz system can send a request for a
                > routing priority when the abc module is fully commited"?
                >
                > Am I crazy?
                >
                >
                > Dave Barrett,
                > Lawyers' Professional Indemnity Company
                >
                >
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@...
                > Yahoo! Groups Links
                >
                >
                >
                >
                >
              • Tobias Mayer
                I am working with a team that is building a large piece of infrastructure that has no apparent end user. The same issues were raised at the start of the
                Message 7 of 26 , Jun 3, 2005
                • 0 Attachment
                  I am working with a team that is building a large piece of infrastructure that has no apparent end user.  The same issues were raised at the start of the project.  We figured that every system has a human component: the person who wants the system to work, and will accept (or of course, reject) the slices/s of functionality you build.  Identify the human, and write the user story (customer story) for him/her.  There may be a number of different humans, at different phases of the project.  That is fine too.  The user story template that Mike Cohn recommends is wonderfully adaptable. 
                  Tobias


                  David A Barrett <dave.barrett@...> wrote:




                  I wanted to go back to the original question; because I thought it was
                  interesting in itself and I'm not sure that the point of it wasn't missed.

                  To me, the key factor was that the system was very low in user interface.
                  This makes it difficult to write User Stories because so much of the
                  specific things that need to happen are out of control of the user, or are
                  hidden from them.

                  So I was wondering, do the "users" in User Stories need to be people?
                  Could you write a User Story that treats external systems and internal
                  modules as "users"?  Something like, "In order to notify the dispach
                  processor of a completed request, the xyz system can send a request for a
                  routing priority when the abc module is fully commited"?

                  Am I crazy?


                  Dave Barrett,
                  Lawyers' Professional Indemnity Company



                  To Post a message, send it to:   scrumdevelopment@...
                  To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


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