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

Re: Origins of user stories

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.