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

Re: [XP] Re: Origins of user stories

Expand Messages
  • Steven Gordon
    Agreed. Scrum has a minimum of the drawn communication paths - nothing prohibits adding more. ... [Non-text portions of this message have been removed]
    Message 1 of 24 , Mar 24, 2013
    • 0 Attachment
      Agreed.

      Scrum has a minimum of the drawn communication paths - nothing prohibits
      adding more.

      On Sun, Mar 24, 2013 at 11:40 AM, Adrian Howard <adrianh@...>wrote:

      > **
      >
      >
      > On 24 March 2013 17:56, Steven Gordon <sgordonphd@...> wrote:
      > > Scrums says:
      > >
      > > [ development team ]
      > > |
      > > [ product owner ] --- [ users ]
      > > |
      > > [ stakeholders (marketing, management, ...) ]
      > >
      > > I believe this is also compatible with XP.
      >
      > That's not what Scrum says - although it is what a fair number of
      > Scrum teams do.
      >
      > All Scrum says is that the PO owns the product decisions, and that the
      > Team own the development decisions.
      >
      > There is nothing - in the Scrum definition - that prevents PO, dev
      > team & users and stakeholders all getting in a room and working
      > together to decide the product and sprint backlogs.
      >
      > I've worked with Scrum teams where users and the dev team interact all
      > of the time. The dev team own their process - if they decide they need
      > to talk to users to get their work done (by - for example - doing
      > in-sprint usability testing) then there is nothing in Scrum that
      > prevents it.
      >
      > People - on the other hand...
      >
      > Cheers,
      >
      > Adrian
      > --
      > http://quietstars.com adrianh@... twitter.com/adrianh
      > t. +44 (0)7752 419080 skype adrianjohnhoward pinboard.in/u:adrianh
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Bill Wake
      I first heard the term user story from Kent Beck, maybe at OOPSLA 97 or 98? My recollection is the term was his. For the concept - There was some related
      Message 2 of 24 , Mar 24, 2013
      • 0 Attachment
        I first heard the term "user story" from Kent Beck, maybe at OOPSLA '97 or
        '98? My recollection is the term was his.

        For the concept -
        There was some related work from the HCI community - I had a course from
        John Carroll in 1993 or so that was basically looking at a bunch of
        different approaches for this. He used the term scenario-based design, but
        there were other terms floating around. These tended to be a bit more
        (literary) story-like than XP user stories. Unfortunately, I tossed a bunch
        of my grad school notes over the holidays, and I can't remember what else
        we looked at but this was a seminar class where we read a couple related
        papers a week. Carroll has a couple books published on scenario-based
        design & you could probably get more references from them. (I hadn't
        explicitly made the link before, but I'm sure exposure to this made the XP
        approach feel natural to me.)

        You can go back to structured analysis too. I've got my copy of Modern
        Structured Analysis by Yourdon in 1989. One of the appendices has "process
        specifications" for a book-selling company - with titles like "Edit order
        details", "Check book in stock", "Send invoices", "Advice[sic] accounting
        of need for refund", "Place print order", ... While I guess it would be
        the "neo-modern" style to also say "who" is using the feature, the story
        names in XP1E were similar. (Where the structured analysis process specs
        differ is that the details they go on to give are more procedural than
        would be the case for teams I've worked with.)

        I dug out a couple older analysis books - Essential Systems Analysis (1984)
        by McMenamin & Palmer (great book on this stuff) and DeMarco's Structured
        Systems Analysis and System Specification (1978/1979) - that use some
        similar type phrasing for naming processes but it doesn't feel as
        "up-front" and isn't really treated as a primary artifact in the sense user
        stories are in XP. (All the structured analysis stuff I've seen tends to
        have several key top-level things going on, eg. data flow diagrams).

        Presumably you could keep going back - the notion of doing things users
        need isn't SO far fetched:)

        --Bill



        On Sun, Mar 24, 2013 at 7:51 AM, william.syntagm <
        william.hudson@...> wrote:

        > I'm researching the origins of the term and concept 'user story'. The
        > first mention in print is Kent Beck's Extreme Programming in 1999, but the
        > first XP project started in 1996 (according to Wikipedia) but were stories
        > a part of it? Where did they come from? The prevalent approach at the time
        > was use cases.
        >
        > I have already done quite a bit of web searching on this so I'm not
        > looking for Google hits<g>. Please let me know if you have some information
        > that a web search wouldn't readily turn up.
        >
        > Thanks in advance.
        >
        > Regards,
        >
        > William
        >

        --
        Bill Wake
        Industrial Logic, Inc. http://industriallogic.com @IndustrialLogic
        Coaching | Training | Assessment | eLearning


        [Non-text portions of this message have been removed]
      • Steven Gordon
        The main point is that it is often necessary to factor in stakeholders involved beyond the direct users. If there are a lot of stakeholders with competing
        Message 3 of 24 , Mar 24, 2013
        • 0 Attachment
          The main point is that it is often necessary to factor in stakeholders
          involved beyond the direct users. If there are a lot of stakeholders with
          competing interests, it is best to have a product owner to mediate those
          competing interests instead of having the development team thrash to try to
          meet them.

          On Sun, Mar 24, 2013 at 12:35 PM, Steven Gordon <sgordonphd@...>wrote:

          > Agreed.
          >
          > Scrum has a minimum of the drawn communication paths - nothing prohibits
          > adding more.
          >
          >
          > On Sun, Mar 24, 2013 at 11:40 AM, Adrian Howard <adrianh@...>wrote:
          >
          >> **
          >>
          >>
          >> On 24 March 2013 17:56, Steven Gordon <sgordonphd@...> wrote:
          >> > Scrums says:
          >> >
          >> > [ development team ]
          >> > |
          >> > [ product owner ] --- [ users ]
          >> > |
          >> > [ stakeholders (marketing, management, ...) ]
          >> >
          >> > I believe this is also compatible with XP.
          >>
          >> That's not what Scrum says - although it is what a fair number of
          >> Scrum teams do.
          >>
          >> All Scrum says is that the PO owns the product decisions, and that the
          >> Team own the development decisions.
          >>
          >> There is nothing - in the Scrum definition - that prevents PO, dev
          >> team & users and stakeholders all getting in a room and working
          >> together to decide the product and sprint backlogs.
          >>
          >> I've worked with Scrum teams where users and the dev team interact all
          >> of the time. The dev team own their process - if they decide they need
          >> to talk to users to get their work done (by - for example - doing
          >> in-sprint usability testing) then there is nothing in Scrum that
          >> prevents it.
          >>
          >> People - on the other hand...
          >>
          >> Cheers,
          >>
          >> Adrian
          >> --
          >> http://quietstars.com adrianh@... twitter.com/adrianh
          >> t. +44 (0)7752 419080 skype adrianjohnhoward pinboard.in/u:adrianh
          >>
          >>
          >>
          >
          >


          [Non-text portions of this message have been removed]
        • Adrian Howard
          ... I ve certainly had people tell me that some of the pre-XP Scrum teams had things that looked very story-ish as product/sprint backlog items. Adrian --
          Message 4 of 24 , Mar 24, 2013
          • 0 Attachment
            On 24 March 2013 19:38, Bill Wake <bill@...> wrote:
            > Presumably you could keep going back - the notion of doing things users
            > need isn't SO far fetched:)

            I've certainly had people tell me that some of the pre-XP Scrum teams
            had things that looked very story-ish as product/sprint backlog items.

            Adrian
            --
            http://quietstars.com adrianh@... twitter.com/adrianh
            t. +44 (0)7752 419080 skype adrianjohnhoward pinboard.in/u:adrianh
          • Adrian Howard
            ... The competing interests certainly need to be managed. I d question whether having a single PO being the only person in the Scrum team being involved in
            Message 5 of 24 , Mar 24, 2013
            • 0 Attachment
              On 24 March 2013 19:39, Steven Gordon <sgordonphd@...> wrote:
              > The main point is that it is often necessary to factor in stakeholders
              > involved beyond the direct users. If there are a lot of stakeholders with
              > competing interests, it is best to have a product owner to mediate those
              > competing interests instead of having the development team thrash to try to
              > meet them.

              The competing interests certainly need to be managed. I'd question
              whether having a single PO being the only person in the Scrum team
              being involved in that is necessarily the best solution in all
              contexts.

              Cheers,

              Adrian
              --
              http://quietstars.com adrianh@... twitter.com/adrianh
              t. +44 (0)7752 419080 skype adrianjohnhoward pinboard.in/u:adrianh
            • Charlie Poole
              XP generalizes this with the notion that the Customer speaks with one voice. This leaves unstated whether the Customer is one person or several, and makes no
              Message 6 of 24 , Mar 24, 2013
              • 0 Attachment
                XP generalizes this with the notion that "the Customer speaks with one
                voice." This leaves unstated whether the Customer is one person or several,
                and makes no particular statement of whether the Customer is a direct user
                of the system or not. One of my best all-time Customers was a sales
                manageer, who needed features that would be saleable to corporate
                decision-makers and usable by the end user.

                Charlie


                On Sun, Mar 24, 2013 at 12:44 PM, Adrian Howard <adrianh@...>wrote:

                > **
                >
                >
                > On 24 March 2013 19:39, Steven Gordon <sgordonphd@...> wrote:
                > > The main point is that it is often necessary to factor in stakeholders
                > > involved beyond the direct users. If there are a lot of stakeholders with
                > > competing interests, it is best to have a product owner to mediate those
                > > competing interests instead of having the development team thrash to try
                > to
                > > meet them.
                >
                > The competing interests certainly need to be managed. I'd question
                > whether having a single PO being the only person in the Scrum team
                > being involved in that is necessarily the best solution in all
                > contexts.
                >
                >
                > Cheers,
                >
                > Adrian
                > --
                > http://quietstars.com adrianh@... twitter.com/adrianh
                > t. +44 (0)7752 419080 skype adrianjohnhoward pinboard.in/u:adrianh
                >
                >
                >


                [Non-text portions of this message have been removed]
              • william.syntagm
                Ron - Many thanks (and to Bill Wake too) for your helpful comments. If anyone s interested - and the issue seems to have sparked some debate - I ve been
                Message 7 of 24 , Mar 25, 2013
                • 0 Attachment
                  Ron -

                  Many thanks (and to Bill Wake too) for your helpful comments. If anyone's interested - and the issue seems to have sparked some debate - I've been running workshops and webinars on the vexed issue of user-centred design in Agile for some years. You can see my article on this topic in Agile Record - https://www.syntagm.co.uk/design/articles/userreq21c.htm - or find out about the webinars at www.guerrillaucd.com.

                  Regards,

                  William Hudson
                  User Experience Strategist
                  Syntagm Ltd

                  --- In extremeprogramming@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                  >
                  >
                  > On Mar 24, 2013, at 8:51 AM, "william.syntagm" <william.hudson@...> wrote:
                  >
                  > > I'm researching the origins of the term and concept 'user story'. The first mention in print is Kent Beck's Extreme Programming in 1999, but the first XP project started in 1996 (according to Wikipedia) but were stories a part of it? Where did they come from? The prevalent approach at the time was use cases.
                  > >
                  > > I have already done quite a bit of web searching on this so I'm not looking for Google hits<g>. Please let me know if you have some information that a web search wouldn't readily turn up.
                  >
                  >
                  > I was on the first XP project, starting in 1996. We had "user stories" from the very beginning. AFAIK, Kent invented the term. We were all quite familiar with the notion of "use cases" at that time. User stories are not use cases. Alistair Cockburn called them "two bit" use cases, meaning the number of bits of information, not their price or value.
                  >
                  > User stories -- perhaps better named as "customer stories" -- were unique in that they belonged to the XP "customer", analogous to the Scrum "Product Owner". They were far less formal than use cases, see for example the "Three C's" notion.
                  >
                  > Bottom line they were there from the beginning and as far as I know Kent came up with the term. The idea of doing what one's customer wants had of course been around for a long long time.
                  >
                  > Ron Jeffries
                  > www.XProgramming.com
                  > You never know what is enough unless you know what is more than enough. -- William Blake
                  >
                  >
                  >
                  > [Non-text portions of this message have been removed]
                  >
                • kentlbeck
                  There are three antecedents I can think of: * Use Cases, which were a revelation to me. Imagine, measuring progress using units the customer cares about!
                  Message 8 of 24 , Mar 26, 2013
                  • 0 Attachment
                    There are three antecedents I can think of:
                    * Use Cases, which were a revelation to me. Imagine, measuring progress using units the customer cares about! Before that we'd have a pile of requirements, extract technical tasks, and measure progress based on the tasks. The idea that half way through a project half of the features would be usable was revolutionary.
                    * A story Kristen Nygaard told me about dock workers (maybe) helping to design the software they would use. I loved the breakdown of the patronizing attitude I had as a programmer (especially since said attitude often concealed ignorance and terror).
                    * One day at a mutual fund I heard an expert user excitedly telling another user about this great new feature--just type in a zip code and the city and state are filled in automatically. That gave me the "story" metaphor--these are stories the user would like to tell about the system (btw I don't like prepending "user", but whatever).

                    The hardest part of applying stories doesn't appear to be decomposition, but rather giving up disproportionate power. Programmers have been high priests from the days of the raised floor. Accepting that other groups should an appropriate level of power in projects (with all the conflict that implies) is uncomfortable. Hence all the attempts to slyly snatch power back.

                    Kent

                    --- In extremeprogramming@yahoogroups.com, "william.syntagm" <william.hudson@...> wrote:
                    >
                    > I'm researching the origins of the term and concept 'user story'. The first mention in print is Kent Beck's Extreme Programming in 1999, but the first XP project started in 1996 (according to Wikipedia) but were stories a part of it? Where did they come from? The prevalent approach at the time was use cases.
                    >
                    > I have already done quite a bit of web searching on this so I'm not looking for Google hits<g>. Please let me know if you have some information that a web search wouldn't readily turn up.
                    >
                    > Thanks in advance.
                    >
                    > Regards,
                    >
                    > William
                    >
                  • JeffGrigg
                    ... That doesn t make it untrue. I would have to agree that the ideal situation is that the Customer (who speaks with one voice) is the end user of the
                    Message 9 of 24 , Apr 1, 2013
                    • 0 Attachment
                      > --- "Malapine" <madbadrabbit@...> wrote:
                      >> Ideal communication path:
                      >> [ developer ] <--> [ user ]
                      >>
                      >> Actual communication path:
                      >> (vendor side)
                      >> [ developer ] <- [ tech lead ] <- [ architect ] <- [ marketing ] ...
                      >> (customer side)
                      >> ... [ purchasing ] <- [ IT architect ] <- [ IT manager ] -x- [ user ]

                      --- Ron Jeffries <ronjeffries@...> wrote:
                      > That's not what Agile says. That's not what XP says.

                      That doesn't make it untrue.

                      I would have to agree that the ideal situation is that the Customer (who speaks with one voice) is the end user of the software we are delivering.

                      But that's a relatively rate occurrence. Most software is used by a number of people. Some software is used by a great many people.

                      Even if they knew what would be of most benefit to them, it's probably impractical for everyone on the development team to speak with all current and potential users about every question, and get good answers.

                      So if the user community is clear on the value and urgency of its needs, then having a single person to communicate with the user community and consolidate this information can be quite valuable.

                      And sometimes the expected user community does not really know what is needed -- the project will provide a visionary new service or product that will change the way the customers think about their needs. In that case, you need a good visionary. [How do you know you have a good visionary? Well, after it's all over, gobs of money falls on your heads. ;-> ]
                    • JeffGrigg
                      ... The stakeholder thing can be overdone, if we re not careful. Yes, I see the value of identifying all stakeholders, and considering their interests. And,
                      Message 10 of 24 , Apr 1, 2013
                      • 0 Attachment
                        --- Steven Gordon <sgordonphd@...> wrote:
                        > The main point is that it is often necessary to factor
                        > in stakeholders involved beyond the direct users. If there
                        > are a lot of stakeholders with competing interests, ...

                        The "stakeholder" thing can be overdone, if we're not careful.

                        Yes, I see the value of identifying all stakeholders, and considering their interests. And, generally, it's a good idea to strive to satisfy all of them.

                        But let's consider a corner case:
                        - The prisoners are stakeholders in a jail.

                        Yes, I can conceive of all kinds of wonderful ways in which prisoner stakeholder input can make prisons a much more humane and successful institution. But face it: The typical prisoner's primary value would be to be set free, to do what they want. And that's not exactly what we're trying to achieve with the whole "jail" thing.

                        Some stakeholder desires may not be the kinds of things we are trying to achieve.

                        It may be healthy to mediate "stakeholder input" with "we are getting paid $X to accomplish 'Y'." Hey; some people may just not like that.
                      • Theresa Jayne Forster
                        We just had a similar thing where I currently work, we are getting ready to go live with our project so we got in a user group to review our offering, Really
                        Message 11 of 24 , Apr 1, 2013
                        • 0 Attachment
                          We just had a similar thing where I currently work, we are getting ready to
                          go live with our project so we got in a user group to review our offering,

                          Really good feedback, they love what we have and offered suggestions to how
                          to improve it.



                          Theresa



                          From: extremeprogramming@yahoogroups.com
                          [mailto:extremeprogramming@yahoogroups.com] On Behalf Of JeffGrigg
                          Sent: 01 April 2013 10:29
                          To: extremeprogramming@yahoogroups.com
                          Subject: [XP] Re: Origins of user stories





                          --- Steven Gordon <sgordonphd@...> wrote:
                          > The main point is that it is often necessary to factor
                          > in stakeholders involved beyond the direct users. If there
                          > are a lot of stakeholders with competing interests, ...

                          The "stakeholder" thing can be overdone, if we're not careful.

                          Yes, I see the value of identifying all stakeholders, and considering their
                          interests. And, generally, it's a good idea to strive to satisfy all of
                          them.

                          But let's consider a corner case:
                          - The prisoners are stakeholders in a jail.

                          Yes, I can conceive of all kinds of wonderful ways in which prisoner
                          stakeholder input can make prisons a much more humane and successful
                          institution. But face it: The typical prisoner's primary value would be to
                          be set free, to do what they want. And that's not exactly what we're trying
                          to achieve with the whole "jail" thing.

                          Some stakeholder desires may not be the kinds of things we are trying to
                          achieve.

                          It may be healthy to mediate "stakeholder input" with "we are getting paid
                          $X to accomplish 'Y'." Hey; some people may just not like that.





                          [Non-text portions of this message have been removed]
                        • Steven Gordon
                          The inmate example is an interesting case. For some applications, the inmates might be the *users*, not just stakeholders. ... [Non-text portions of this
                          Message 12 of 24 , Apr 1, 2013
                          • 0 Attachment
                            The inmate example is an interesting case. For some applications, the
                            inmates might be the *users*, not just stakeholders.

                            >
                            > From: extremeprogramming@yahoogroups.com
                            > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of JeffGrigg
                            > Sent: 01 April 2013 10:29
                            > To: extremeprogramming@yahoogroups.com
                            > Subject: [XP] Re: Origins of user stories
                            >
                            > --- Steven Gordon <sgordonphd@...> wrote:
                            > > The main point is that it is often necessary to factor
                            > > in stakeholders involved beyond the direct users. If there
                            > > are a lot of stakeholders with competing interests, ...
                            >
                            > The "stakeholder" thing can be overdone, if we're not careful.
                            >
                            > Yes, I see the value of identifying all stakeholders, and considering their
                            > interests. And, generally, it's a good idea to strive to satisfy all of
                            > them.
                            >
                            > But let's consider a corner case:
                            > - The prisoners are stakeholders in a jail.
                            >
                            > Yes, I can conceive of all kinds of wonderful ways in which prisoner
                            > stakeholder input can make prisons a much more humane and successful
                            > institution. But face it: The typical prisoner's primary value would be to
                            > be set free, to do what they want. And that's not exactly what we're trying
                            > to achieve with the whole "jail" thing.
                            >
                            > Some stakeholder desires may not be the kinds of things we are trying to
                            > achieve.
                            >
                            > It may be healthy to mediate "stakeholder input" with "we are getting paid
                            > $X to accomplish 'Y'." Hey; some people may just not like that.
                            >
                            > [Non-text portions of this message have been removed]
                            >
                            >
                            >


                            [Non-text portions of this message have been removed]
                          • Malapine
                            ... For any application, you can think of anti-stories that would please some users, but harm other users or stakeholders. These are often useful for testing
                            Message 13 of 24 , Apr 1, 2013
                            • 0 Attachment
                              --- Steven Gordon <sgordonphd@...> wrote:
                              > The inmate example is an interesting case. For some applications,
                              > the inmates might be the *users*, not just stakeholders.

                              For any application, you can think of anti-stories that would
                              please some users, but harm other users or stakeholders. These
                              are often useful for testing purposes.

                              As an ATM user, I want the machine to dispense money without
                              debiting my account, so I can spend more.

                              As an elevator passenger, I want the car to take me straight to
                              the lobby and not stop on any other floors, so I can get out
                              of the building sooner.

                              etc.
                            • Theresa Forster (home)
                              Your ATM story is interesting but wouldn t that be in odds with the epic, of A machine to dispense cash from the users account if they have the funds. Stories
                              Message 14 of 24 , Apr 1, 2013
                              • 0 Attachment
                                Your ATM story is interesting but wouldn't that be in odds with the epic, of
                                A machine to dispense cash from the users account if they have the funds.

                                Stories are good for exploring the functionality of a system and showing up edge cases. I remember reading somewhere that user stories are a reminder for the developer to have the conversation. And that is usually with the stakeholder who is part of your team and not all users of the system. For instance an accountant who works for sage when you are working on the next version of sage, any company who purchases the product is potentially the stakeholder but there is a designated person who speaks for the stakeholder.

                                Theresa

                                Sent from my iPad

                                On 1 Apr 2013, at 19:38, "Malapine" <madbadrabbit@...> wrote:

                                >
                                >
                                > --- Steven Gordon <sgordonphd@...> wrote:
                                > > The inmate example is an interesting case. For some applications,
                                > > the inmates might be the *users*, not just stakeholders.
                                >
                                > For any application, you can think of anti-stories that would
                                > please some users, but harm other users or stakeholders. These
                                > are often useful for testing purposes.
                                >
                                > As an ATM user, I want the machine to dispense money without
                                > debiting my account, so I can spend more.
                                >
                                > As an elevator passenger, I want the car to take me straight to
                                > the lobby and not stop on any other floors, so I can get out
                                > of the building sooner.
                                >
                                > etc.
                                >
                                >


                                [Non-text portions of this message have been removed]
                              • Larry Brunelle
                                ... [snip] ... [snip] Are you running for election somewhere? :-)
                                Message 15 of 24 , Apr 1, 2013
                                • 0 Attachment
                                  Malapine wrote:
                                  >
                                  [snip]

                                  > As an ATM user, I want the machine to dispense money without
                                  > debiting my account, so I can spend more.

                                  [snip]

                                  Are you running for election somewhere? :-)
                                • JeffGrigg
                                  ... Since when are the users of a system not stakeholders? They re the ones who have to live with the system every day.
                                  Message 16 of 24 , Apr 2, 2013
                                  • 0 Attachment
                                    --- Steven Gordon <sgordonphd@...> wrote:
                                    > The inmate example is an interesting case. For some
                                    > applications, the inmates might be the *users*, not
                                    > just stakeholders.

                                    Since when are the users of a system not stakeholders?

                                    They're the ones who have to live with the system every day.
                                  • Chet Hendrickson
                                    It is the Customer s job to balance the desires of all the stakeholders. In the inmate case, it may be prudent for her to not provide all the features they
                                    Message 17 of 24 , Apr 2, 2013
                                    • 0 Attachment
                                      It is the Customer's job to balance the desires of all the stakeholders. In the inmate case, it may be prudent for her to not provide all the features they may wish.

                                      chet


                                      Chet Hendrickson
                                      lists@...



                                      On Apr 2, 2013, at 4:00 AM, JeffGrigg <jeffreytoddgrigg@...> wrote:

                                      > --- Steven Gordon <sgordonphd@...> wrote:
                                      > > The inmate example is an interesting case. For some
                                      > > applications, the inmates might be the *users*, not
                                      > > just stakeholders.
                                      >
                                      > Since when are the users of a system not stakeholders?
                                      >
                                      > They're the ones who have to live with the system every day.
                                      >
                                      >



                                      [Non-text portions of this message have been removed]
                                    Your message has been successfully submitted and would be delivered to recipients shortly.