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

User Stories vs. Agile Use Cases

Expand Messages
  • peterstev
    Hi everyone, I m working in a project where there are two development centers, one on each side of the Atlantic. Each team has a coach, one would like to user
    Message 1 of 15 , Nov 28, 2008
    • 0 Attachment
      Hi everyone,

      I'm working in a project where there are two development centers, one
      on each side of the Atlantic. Each team has a coach, one would like to
      user User Stories à la Mike Cohn to define the system, the other would
      like to use Agile Use Cases à la Alistair Cockburn.

      Has anyone out there worked with both? Any comments on the strengths
      and weaknesses of the two strategies?

      Thanks in advance!

      Peter

      --
      Peter Stevens, CSM, CSP
      http://tinyurl.com/Scrum-In-House-Training
      http://scrum-breakfast.com
      tel: +41 44 586 6450
    • Tom Mellor
      The use case / user story discussion/debate can perpetuate for eternity. It s really not a matter that warrants much discussion. The scenario seems to imply
      Message 2 of 15 , Nov 29, 2008
      • 0 Attachment
        Re:User Stories vs. Agile Use Cases

        The use case / user story discussion/debate can perpetuate for eternity.  It's really not a matter that warrants much discussion. The scenario seems to imply that the 2 teams are sharing the development of a single product. Perhaps the best way to approach this issue is to ask the one team why it desires use cases.  Some people (and organizations) are not comfortable with the simplicity and minimalist composition of a user story.  We know that thousands or very good programs have been written using stories (and use cases) and the details (requirements) needed to code the stories are always driven out at some point.  The issue may simply be one of the extent of documentation desired/required by the team and/or the organization.  While we don't advocate documentation as a means of communication, it does convey information and that is important to a team. Information is best exchanged in face-to-face communication, but if the teams are sharing the development and virtual synchronous communication isn't possible, then one team may desire more detail. If the teams are working on different products, then it probably ought to be at the discretion of each team as to whether it uses use cases or user stories.

        Tom Mellor
        Certified Scrum Trainer

      • Peter Stevens
        Hi Tom, Thanks for the info! Your analysis is correct. Two teams, one product, one product backlog. Because this project is a joint venture between 2
        Message 3 of 15 , Nov 29, 2008
        • 0 Attachment
          Hi Tom,

          Thanks for the info!

          Your analysis is correct. Two teams, one product, one product backlog. Because this project is a joint venture between 2 companies, there is two of everything else. I'm coaching one of the teams, I've never really worked with use cases (except to read proponents of user stories explain why use cases are bad.)

          I have in the mean time found some interesting discussions from Alistair Cockburn and Jens Coldewey. At least I understand the context somewhat better, even if I don't have the solution to my problem yet...

          So it looks like if we start with identifying the users of system, then identifying their top level goals (eg. "As a Manager, I want to hire top people to fill vacant positions), then refining those goals into system goals  (... I want to publish a want ad, I want to triage applications, etc.),  we would (potentially) have the titles for our use cases, which could be elaborated as described by Cockburn or refined into smaller stories à la Cohn.

          Does that seem about right?

          Thanks again,

          Peter



          Tom Mellor schrieb:

          The use case / user story discussion/debate can perpetuate for eternity.  It's really not a matter that warrants much discussion. The scenario seems to imply that the 2 teams are sharing the development of a single product. Perhaps the best way to approach this issue is to ask the one team why it desires use cases.  Some people (and organizations) are not comfortable with the simplicity and minimalist composition of a user story.  We know that thousands or very good programs have been written using stories (and use cases) and the details (requirements) needed to code the stories are always driven out at some point.  The issue may simply be one of the extent of documentation desired/required by the team and/or the organization.  While we don't advocate documentation as a means of communication, it does convey information and that is important to a team. Information is best exchanged in face-to-face communication, but if the teams are sharing the development and virtual synchronous communication isn't possible, then one team may desire more detail. If the teams are working on different products, then it probably ought to be at the discretion of each team as to whether it uses use cases or user stories.

          Tom Mellor
          Certified Scrum Trainer




          -- 
          Peter Stevens, CSM, CSP
          www.tinyurl.com/Scrum-In-House-Training
          www.scrum-breakfast.com
          tel: +41 44 586 6450 
          
        • Elizabeth V Woodward
          Hi Peter, I m actually a strong proponent of using both user stories and use cases. Working with teams that are transitioning to agile, we sometimes find a
          Message 4 of 15 , Nov 29, 2008
          • 0 Attachment

            Hi Peter,

            I'm actually a strong proponent of using both user stories and use cases. Working with teams that are transitioning to agile, we sometimes find a large number of requirements in the backlog without a good understanding of who made the request or the real business need and value that drove the request in the first place. Getting teams to think in terms of user stories--with their simple, brief format-- helps us to ensure that we're delivering value to our stakeholders and helps the product owner with prioritization based on delivering highest value and expected ROI. Splitting larger user stories or epics into smaller user stories that fit within a sprint also helps us to ensure we're focused on delivering value at the end of each sprint. The other things we love about user stories are the clear yes/no, pass/fail identification of acceptance criteria and the emphasis on whole-team verbal conversation to ensure we're all on the same page. I can't tell you how many times we've found that carefully written text means something very different to different members of the team!

            On the other hand, use cases are a great way to flesh out requirements as we begin to implement a user story. It's a good communication tool to help the team discuss the interaction between the system and the actor. We also think in terms of use cases sometimes when we split user stories... The examples that Cohn gives in Chapter 12 of Agile Estimating and Planning (love that book!) can map at a high level to use case basic flows and alternative flows. The main things we have to watch for with the use cases is that we don't get too wrapped up in developing super lengthy, verbose documentation, that any stories related to alternative flows are put on the product backlog with a high prioritization and that the PO knows those are required for the product to truly be shippable. (I know our goal is shippable at the end of each sprint, but there are times where we're only going to get so far...)

            -elizabeth


            Inactive hide details for "peterstev" <peterstev@...>"peterstev" <peterstev@...>


                    "peterstev" <peterstev@...>
                    Sent by: scrumdevelopment@yahoogroups.com

                    11/28/2008 07:59 AM

                    Please respond to
                    scrumdevelopment@yahoogroups.com


            To

            scrumdevelopment@yahoogroups.com

            cc


            Subject

            [scrumdevelopment] User Stories vs. Agile Use Cases
            Hi everyone,

            I'm working in a project where there are two development centers, one
            on each side of the Atlantic. Each team has a coach, one would like to
            user User Stories à la Mike Cohn to define the system, the other would
            like to use Agile Use Cases à la Alistair Cockburn.

            Has anyone out there worked with both? Any comments on the strengths
            and weaknesses of the two strategies?

            Thanks in advance!

            Peter

            --
            Peter Stevens, CSM, CSP

            http://tinyurl.com/Scrum-In-House-Training
            http://scrum-breakfast.com
            tel: +41 44 586 6450


          • Gerard Meszaros
            I too like to use both user stories and use cases together as I find them to be complementary views of the system. Use cases catalog the major transactions
            Message 5 of 15 , Nov 30, 2008
            • 0 Attachment
              I too like to use both user stories and use cases together as I find them to be complementary views of the system. Use cases catalog the major transactions while user stories and the units of incremental development. The use cases provide a framework of transactions that the user stories add meat to. Many user stories span several use cases and add to one or more of them. So stories are in fact a good way to "grow" the use case model incrementally to avoid the analysis paralysis that comes from trying to define the entire use case model. The use cases, meanwhile, provide the structure that helps us understand the context of the user stories.

              I'd add that I would only write fully fleshed out use cases if there was some business need for them after the software already exists. Otherwise I would stick with the agile use cases.

              So, my suggestion is don't choose, use both.

              Best,

              Gerard
              -- 
              Gerard Meszaros
              Lean/Agile Coach/Mentor/Trainer
              http://www.gerardmeszaros.com 
              1-403-827-2967
              
              Author of the Jolt Productivity Award winning book "xUnit Test Patterns - Refactoring Test Code". Learn more at http://xunitpatterns.com/index.html


              Elizabeth V Woodward wrote:

              Hi Peter,

              I'm actually a strong proponent of using both user stories and use cases. Working with teams that are transitioning to agile, we sometimes find a large number of requirements in the backlog without a good understanding of who made the request or the real business need and value that drove the request in the first place. Getting teams to think in terms of user stories--with their simple, brief format-- helps us to ensure that we're delivering value to our stakeholders and helps the product owner with prioritization based on delivering highest value and expected ROI. Splitting larger user stories or epics into smaller user stories that fit within a sprint also helps us to ensure we're focused on delivering value at the end of each sprint. The other things we love about user stories are the clear yes/no, pass/fail identification of acceptance criteria and the emphasis on whole-team verbal conversation to ensure we're all on the same page. I can't tell you how many times we've found that carefully written text means something very different to different members of the team!

              On the other hand, use cases are a great way to flesh out requirements as we begin to implement a user story. It's a good communication tool to help the team discuss the interaction between the system and the actor. We also think in terms of use cases sometimes when we split user stories... The examples that Cohn gives in Chapter 12 of Agile Estimating and Planning (love that book!) can map at a high level to use case basic flows and alternative flows. The main things we have to watch for with the use cases is that we don't get too wrapped up in developing super lengthy, verbose documentation, that any stories related to alternative flows are put on the product backlog with a high prioritization and that the PO knows those are required for the product to truly be shippable. (I know our goal is shippable at the end of each sprint, but there are times where we're only going to get so far...)

              -elizabeth


              Inactive hide details for "peterstev" <peterstev@...>"peterstev" <peterstev@...>



              To

              scrumdevelopment@yahoogroups.com

              cc


              Subject

              [scrumdevelopment] User Stories vs. Agile Use Cases

              Hi everyone,

              I'm working in a project where there are two development centers, one
              on each side of the Atlantic. Each team has a coach, one would like to
              user User Stories à la Mike Cohn to define the system, the other would
              like to use Agile Use Cases à la Alistair Cockburn.

              Has anyone out there worked with both? Any comments on the strengths
              and weaknesses of the two strategies?

              Thanks in advance!

              Peter

              --
              Peter Stevens, CSM, CSP

              http://tinyurl.com/Scrum-In-House-Training
              http://scrum-breakfast.com
              tel: +41 44 586 6450



              
              
              
              
            • aacockburn
              ... Use cases are good for showing people the shape of the system to be, while user stories are good for breaking down work into small enough pieces to fit
              Message 6 of 15 , Nov 30, 2008
              • 0 Attachment
                --- In scrumdevelopment@yahoogroups.com, "peterstev" <peterstev@...>
                wrote:
                >
                > I'm working in a project where there are two development
                > centers, one on each side of the Atlantic. Each team has a
                > coach, one would like to user User Stories à la Mike Cohn to
                > define the system, the other would like to use Agile Use Cases
                > à la Alistair Cockburn.
                >
                > Has anyone out there worked with both? Any comments on the
                > strengths and weaknesses of the two strategies?

                Use cases are good for showing people the shape of the system to be,
                while user stories are good for breaking down work into small enough
                pieces to fit into iterations.

                IMHO they serve different purposes. I've seen a number of projects
                get into trouble because they only used user stories and never had
                the picture of the what and why.

                On the other hand, I've seen as many or more projects get into
                trouble from writing 20-30 page use cases. Keep your use cases
                to mostly less than one page, occasional 2-pages, rarest case 3, then
                you'll be OK on them, and can connect them to your user stories.

                Alistair
              • Steven Mak
                I think they serve different purposes. http://www.infoq.com/news/2008/07/use-case-or-user-story Use case is very good for a permanent document, in case the
                Message 7 of 15 , Nov 30, 2008
                • 0 Attachment
                  I think they serve different purposes.

                  http://www.infoq.com/news/2008/07/use-case-or-user-story

                  Use case is very good for a permanent document, in case the customer
                  wants one.

                  Moreover, I believe it also depends on how well the team is familiar
                  with them.

                  --- In scrumdevelopment@yahoogroups.com, "Tom Mellor"
                  <tom.mellor.c5t2@...> wrote:
                  >
                  > The use case / user story discussion/debate can perpetuate for eternity.
                  > It's really not a matter that warrants much discussion. The scenario
                  > seems to imply that the 2 teams are sharing the development of a single
                  > product. Perhaps the best way to approach this issue is to ask the one
                  > team why it desires use cases. Some people (and organizations) are not
                  > comfortable with the simplicity and minimalist composition of a user
                  > story. We know that thousands or very good programs have been written
                  > using stories (and use cases) and the details (requirements) needed to
                  > code the stories are always driven out at some point. The issue may
                  > simply be one of the extent of documentation desired/required by the
                  > team and/or the organization. While we don't advocate documentation as
                  > a means of communication, it does convey information and that is
                  > important to a team. Information is best exchanged in face-to-face
                  > communication, but if the teams are sharing the development and virtual
                  > synchronous communication isn't possible, then one team may desire more
                  > detail. If the teams are working on different products, then it probably
                  > ought to be at the discretion of each team as to whether it uses use
                  > cases or user stories.
                  >
                  > Tom Mellor
                  > Certified Scrum Trainer
                  >
                • Tom Mellor
                  Alistair makes good points. We find use cases more valuable when we are producing a new system and we want to see the flow, the pre-conditions,
                  Message 8 of 15 , Dec 1, 2008
                  • 0 Attachment
                    Re: User Stories vs. Agile Use Cases

                    Alistair makes good points.  We find use cases more valuable when we are producing a new system and we want to see the flow, the pre-conditions, post-conditions, assumptions, etc.  Obviously we don't try to drive out the requirement details for the system in use cases, but rather we use them to tie the components of the system together for a big picture view.  In existing systems that we are upgrading, rewriting, etc., we typically only compose user stories, even if use cases for the system have not been created.  One thing about use cases that is potentially unfavorable is that they decay over time unless they are properly updated for changes.  Therein lies the problem - who takes the responsibility and realizes they need to be updated.  User stories don't typically decay as readily. 

                    Tom Mellor
                    Certified Scrum Trainer
                    tom.mellor.c5t2@...
                    309.846.4899 (Work and Cell)
                     

                  • aacockburn
                    Good points, Tom. This sort of discussion gets me to note that the workers working on my house have a belt sander and also a chisel. I ve seen them use both.
                    Message 9 of 15 , Dec 1, 2008
                    • 0 Attachment
                      Good points, Tom.

                      This sort of discussion gets me to note that the workers working on
                      my house have a belt sander and also a chisel. I've seen them use
                      both. I've not yet seen them argue over, "Should we get rid of the
                      belt sander and only keep the chisel, or vice versa?"

                      I also can't see the workmen saying, "I'm not going to learn how to
                      use a belt sander - this chisel works fine for me."

                      The way of phrasing the question about use cases versus user stories
                      already presupposes that an either/or choice is appropriate.

                      They are both tools. Learn them both. We are all professionals -- it
                      behooves us to know the tools available to us.

                      Alistair


                      --- In scrumdevelopment@yahoogroups.com, "Tom Mellor"
                      <tom.mellor.c5t2@...> wrote:
                      >
                      > Alistair makes good points. We find use cases more valuable when
                      we are
                      > producing a new system and we want to see the flow, the pre-
                      conditions,
                      > post-conditions, assumptions, etc. Obviously we don't try to drive
                      out
                      > the requirement details for the system in use cases, but rather we
                      use
                      > them to tie the components of the system together for a big picture
                      > view. In existing systems that we are upgrading, rewriting, etc.,
                      we
                      > typically only compose user stories, even if use cases for the
                      system
                      > have not been created. One thing about use cases that is
                      potentially
                      > unfavorable is that they decay over time unless they are properly
                      > updated for changes. Therein lies the problem - who takes the
                      > responsibility and realizes they need to be updated. User stories
                      don't
                      > typically decay as readily.
                      >
                      > Tom Mellor
                      > Certified Scrum Trainer
                      > tom.mellor.c5t2@...
                      > 309.846.4899 (Work and Cell)
                      >
                    • peterstev
                      Lady & Gentlemen, Yes, I have learned a lot from this discussion as well, including the value of well equipped tool box ;-) Kind regards, Peter
                      Message 10 of 15 , Dec 1, 2008
                      • 0 Attachment
                        Lady & Gentlemen,

                        Yes, I have learned a lot from this discussion as well, including the
                        value of well equipped tool box ;-)

                        Kind regards,

                        Peter

                        --- In scrumdevelopment@yahoogroups.com, "aacockburn" <acockburn@...>
                        wrote:
                        >
                        > Good points, Tom.
                        >
                        > This sort of discussion gets me to note that the workers working on
                        > my house have a belt sander and also a chisel. I've seen them use
                        > both. I've not yet seen them argue over, "Should we get rid of the
                        > belt sander and only keep the chisel, or vice versa?"
                        >
                        > I also can't see the workmen saying, "I'm not going to learn how to
                        > use a belt sander - this chisel works fine for me."
                        >
                        > The way of phrasing the question about use cases versus user stories
                        > already presupposes that an either/or choice is appropriate.
                        >
                        > They are both tools. Learn them both. We are all professionals -- it
                        > behooves us to know the tools available to us.
                        >
                        > Alistair
                        >
                        >
                        > --- In scrumdevelopment@yahoogroups.com, "Tom Mellor"
                        > <tom.mellor.c5t2@> wrote:
                        > >
                        > > Alistair makes good points. We find use cases more valuable when
                        > we are
                        > > producing a new system and we want to see the flow, the pre-
                        > conditions,
                        > > post-conditions, assumptions, etc. Obviously we don't try to drive
                        > out
                        > > the requirement details for the system in use cases, but rather we
                        > use
                        > > them to tie the components of the system together for a big picture
                        > > view. In existing systems that we are upgrading, rewriting, etc.,
                        > we
                        > > typically only compose user stories, even if use cases for the
                        > system
                        > > have not been created. One thing about use cases that is
                        > potentially
                        > > unfavorable is that they decay over time unless they are properly
                        > > updated for changes. Therein lies the problem - who takes the
                        > > responsibility and realizes they need to be updated. User stories
                        > don't
                        > > typically decay as readily.
                        > >
                        > > Tom Mellor
                        > > Certified Scrum Trainer
                        > > tom.mellor.c5t2@
                        > > 309.846.4899 (Work and Cell)
                        > >
                        >
                      • David H.
                        ... If the value the chisel returned would gradually move towards zero I stipulate that discussion would come up more and more. ... You have obviously never
                        Message 11 of 15 , Dec 1, 2008
                        • 0 Attachment
                          2008/12/1 aacockburn <acockburn@...>:
                          > Good points, Tom.
                          >
                          > This sort of discussion gets me to note that the workers working on
                          > my house have a belt sander and also a chisel. I've seen them use
                          > both. I've not yet seen them argue over, "Should we get rid of the
                          > belt sander and only keep the chisel, or vice versa?"
                          >
                          If the value the chisel returned would gradually move towards zero I
                          stipulate that discussion would come up more and more.

                          > I also can't see the workmen saying, "I'm not going to learn how to
                          > use a belt sander - this chisel works fine for me."
                          >
                          You have obviously never met my steph father (who happens to be a
                          structural engineer for car bodies) and swears to certain ways of
                          doing it and completely disregarding others. Apparently it works for
                          him, he is still quite respected in his community.

                          > The way of phrasing the question about use cases versus user stories
                          > already presupposes that an either/or choice is appropriate.
                          >
                          > They are both tools. Learn them both. We are all professionals -- it
                          > behooves us to know the tools available to us.
                          >
                          We are also human and thus we are limited in what we can learn. I
                          would suggest we only learn the things that return most value to us in
                          the context we need to learn them in. If knowing a lot about Use Cases
                          enables me to write better User Stories in the end, then I am all for
                          learning about them.

                          I do not know anything noteworthy about Use Cases and yet I seem to be
                          capable of writing User Stories for complex problems. I would really
                          like to know whether learning about Use Cases can improve my
                          abilities. Any suggestions?

                          -d

                          --
                          Sent from gmail so do not trust this communication.
                          Do not send me sensitive information here, ask for my none-gmail accounts.

                          "Therefore the considerations of the intelligent always include both
                          benefit and harm." - Sun Tzu
                        • aacockburn
                          I learned long ago that there are people who will only learn a new tool or technique when faced with abject failure. Short of that, they say -- no matter what
                          Message 12 of 15 , Dec 1, 2008
                          • 0 Attachment
                            I learned long ago that there are people who will only learn a new
                            tool or technique when faced with abject failure. Short of that, they
                            say -- no matter what difficulties they encounter along the way --
                            "See, I told my tool box was sufficient for the job."

                            Best wishes with your tool box. May you one day learn to spot the
                            empty spaces in it.

                            Alistair

                            --- In scrumdevelopment@yahoogroups.com, "David H." <dmalloc@...>
                            wrote:
                            >
                            > 2008/12/1 aacockburn <acockburn@...>:
                            > > Good points, Tom.
                            > >
                            > > This sort of discussion gets me to note that the workers working
                            on
                            > > my house have a belt sander and also a chisel. I've seen them use
                            > > both. I've not yet seen them argue over, "Should we get rid of the
                            > > belt sander and only keep the chisel, or vice versa?"
                            > >


                            > If the value the chisel returned would gradually move towards zero I
                            > stipulate that discussion would come up more and more.
                            >
                            > > I also can't see the workmen saying, "I'm not going to learn how
                            to
                            > > use a belt sander - this chisel works fine for me."
                            > >
                            > You have obviously never met my steph father (who happens to be a
                            > structural engineer for car bodies) and swears to certain ways of
                            > doing it and completely disregarding others. Apparently it works for
                            > him, he is still quite respected in his community.
                            >
                            > > The way of phrasing the question about use cases versus user
                            stories
                            > > already presupposes that an either/or choice is appropriate.
                            > >
                            > > They are both tools. Learn them both. We are all professionals --
                            it
                            > > behooves us to know the tools available to us.
                            > >
                            > We are also human and thus we are limited in what we can learn. I
                            > would suggest we only learn the things that return most value to us
                            in
                            > the context we need to learn them in. If knowing a lot about Use
                            Cases
                            > enables me to write better User Stories in the end, then I am all
                            for
                            > learning about them.
                            >
                            > I do not know anything noteworthy about Use Cases and yet I seem to
                            be
                            > capable of writing User Stories for complex problems. I would really
                            > like to know whether learning about Use Cases can improve my
                            > abilities. Any suggestions?
                            >
                            > -d
                            >
                            > --
                            > Sent from gmail so do not trust this communication.
                            > Do not send me sensitive information here, ask for my none-gmail
                            accounts.
                            >
                            > "Therefore the considerations of the intelligent always include both
                            > benefit and harm." - Sun Tzu
                            >
                          • George Dinwiddie
                            ... There s a /really/ good book on Use Cases, though Alistair may be too modest to mention it. I think you would find reading it worth your time.
                            Message 13 of 15 , Dec 1, 2008
                            • 0 Attachment
                              David H. wrote:
                              > We are also human and thus we are limited in what we can learn. I
                              > would suggest we only learn the things that return most value to us in
                              > the context we need to learn them in. If knowing a lot about Use Cases
                              > enables me to write better User Stories in the end, then I am all for
                              > learning about them.
                              >
                              > I do not know anything noteworthy about Use Cases and yet I seem to be
                              > capable of writing User Stories for complex problems. I would really
                              > like to know whether learning about Use Cases can improve my
                              > abilities. Any suggestions?

                              There's a /really/ good book on Use Cases, though Alistair may be too
                              modest to mention it. I think you would find reading it worth your
                              time. http://www.amazon.com/exec/obidos/ISBN=0201702258/

                              I've also seen people use Use Cases like a carpenter using a chisel for
                              a screwdriver. I couldn't get them to take a look at the book. I also
                              couldn't get them to throw out "use cases" where there was no user, just
                              another part of the same system.

                              I wouldn't say Use Cases are /necessary/ "for showing people the shape
                              of the system to be," but they're a good tool to know.

                              - George

                              --
                              ----------------------------------------------------------------------
                              * George Dinwiddie * http://blog.gdinwiddie.com
                              Software Development http://www.idiacomputing.com
                              Consultant and Coach http://www.agilemaryland.org
                              ----------------------------------------------------------------------
                            • Raghuram
                              I agree that use cases are surely a good tool to know. People who have been using use cases earlier and changed over to user stories, in my opinion, can write
                              Message 14 of 15 , Dec 1, 2008
                              • 0 Attachment
                                I agree that use cases are surely a good tool to know. People who have been using use cases earlier and changed over to user stories, in my opinion, can write better stories.  But people who already have started using user stories before knowing anything about use cases may feel it a bit redundant.
                                 
                                K.V.M.Raghuram,



                                From: George Dinwiddie <lists@...>
                                To: scrumdevelopment@yahoogroups.com
                                Sent: Tuesday, 2 December, 2008 8:21:14 AM
                                Subject: Re: [scrumdevelopment] Re: User Stories vs. Agile Use Cases

                                David H. wrote:

                                > We are also human and thus we are limited in what we can learn. I
                                > would suggest we only learn the things that return most value to us in
                                > the context we need to learn them in. If knowing a lot about Use Cases
                                > enables me to write better User Stories in the end, then I am all for
                                > learning about them.
                                >
                                > I do not know anything noteworthy about Use Cases and yet I seem to be
                                > capable of writing User Stories for complex problems. I would really
                                > like to know whether learning about Use Cases can improve my
                                > abilities. Any suggestions?

                                There's a /really/ good book on Use Cases, though Alistair may be too
                                modest to mention it. I think you would find reading it worth your
                                time. http://www.amazon.. com/exec/ obidos/ISBN= 0201702258/

                                I've also seen people use Use Cases like a carpenter using a chisel for
                                a screwdriver. I couldn't get them to take a look at the book. I also
                                couldn't get them to throw out "use cases" where there was no user, just
                                another part of the same system.

                                I wouldn't say Use Cases are /necessary/ "for showing people the shape
                                of the system to be," but they're a good tool to know.

                                - George

                                --
                                ------------ --------- --------- --------- --------- --------- -
                                * George Dinwiddie * http://blog. gdinwiddie. com
                                Software Development http://www.idiacomp uting.com
                                Consultant and Coach http://www.agilemar yland.org
                                ------------ --------- --------- --------- --------- --------- -



                                Add more friends to your messenger and enjoy! Invite them now.
                              • David H.
                                ... Thanks... as he goes and buys it... -d -- Sent from gmail so do not trust this communication. Do not send me sensitive information here, ask for my
                                Message 15 of 15 , Dec 2, 2008
                                • 0 Attachment
                                  2008/12/2 George Dinwiddie <lists@...>:
                                  > David H. wrote:
                                  >> We are also human and thus we are limited in what we can learn. I
                                  >> would suggest we only learn the things that return most value to us in
                                  >> the context we need to learn them in. If knowing a lot about Use Cases
                                  >> enables me to write better User Stories in the end, then I am all for
                                  >> learning about them.
                                  >>
                                  >> I do not know anything noteworthy about Use Cases and yet I seem to be
                                  >> capable of writing User Stories for complex problems. I would really
                                  >> like to know whether learning about Use Cases can improve my
                                  >> abilities. Any suggestions?
                                  >
                                  > There's a /really/ good book on Use Cases, though Alistair may be too
                                  > modest to mention it. I think you would find reading it worth your
                                  > time. http://www.amazon.com/exec/obidos/ISBN=0201702258/
                                  >
                                  Thanks... as he goes and buys it...

                                  -d

                                  --
                                  Sent from gmail so do not trust this communication.
                                  Do not send me sensitive information here, ask for my none-gmail accounts.

                                  "Therefore the considerations of the intelligent always include both
                                  benefit and harm." - Sun Tzu
                                Your message has been successfully submitted and would be delivered to recipients shortly.