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

Starting XP and splitting user stories

Expand Messages
  • Brian Victor
    Hi all! I ve read much about XP and agile programming over the years, and gleaned many gems of information off the c2 wiki. Although I haven t tried it
    Message 1 of 12 , Dec 21, 2005
    • 0 Attachment
      Hi all! I've read much about XP and agile programming over the years,
      and gleaned many gems of information off the c2 wiki. Although I
      haven't tried it completely yet, I have put some of the attitudes (TDD,
      constant refactoring) into use in my own code and have been pleased.

      I'm trying to begin to use XP as a whole at my workplace, and I have one
      coworker who seems to be ready to come along for the ride. We are
      trying an XP approach to a development effort that the two of us are
      working on for the next couple of months. I pointed him at c2, and I'm
      trying to reinforce concepts as they become relevant. One of the first
      ones that came up was user stories.

      My question is with regard to how to split broad user stories into more
      estimable pieces. We have an existing system that needs to receive data
      from a new device, and the story was essentially, "acquire data from the
      device and run it through the existing system." Because of the way the
      existing software is designed, this touches several modules, and my
      coworker and I were drawn into splitting it into technical details that
      weren't really relevant to the user.

      Is it your sense that user stories should explicitly not contain
      under-the-cover details? Are there better ways to split something like
      this which is, to the user, a single task?

      Thank you all for your insights. Even as a lurker I have found this
      list to be very thoughtful and informative.

      --
      Brian
    • Steven Gordon
      I recommend the book at the bottom of this web page: http://www.mountaingoatsoftware.com/ Also, there are some useful presentations about user stories on that
      Message 2 of 12 , Dec 21, 2005
      • 0 Attachment
        I recommend the book at the bottom of this web page:
        http://www.mountaingoatsoftware.com/

        Also, there are some useful presentations about user stories on that same
        site.


        On 12/21/05, Brian Victor <workusenet1@...> wrote:
        >
        > Hi all! I've read much about XP and agile programming over the years,
        > and gleaned many gems of information off the c2 wiki. Although I
        > haven't tried it completely yet, I have put some of the attitudes (TDD,
        > constant refactoring) into use in my own code and have been pleased.
        >
        > I'm trying to begin to use XP as a whole at my workplace, and I have one
        > coworker who seems to be ready to come along for the ride. We are
        > trying an XP approach to a development effort that the two of us are
        > working on for the next couple of months. I pointed him at c2, and I'm
        > trying to reinforce concepts as they become relevant. One of the first
        > ones that came up was user stories.
        >
        > My question is with regard to how to split broad user stories into more
        > estimable pieces. We have an existing system that needs to receive data
        > from a new device, and the story was essentially, "acquire data from the
        > device and run it through the existing system." Because of the way the
        > existing software is designed, this touches several modules, and my
        > coworker and I were drawn into splitting it into technical details that
        > weren't really relevant to the user.
        >
        > Is it your sense that user stories should explicitly not contain
        > under-the-cover details? Are there better ways to split something like
        > this which is, to the user, a single task?
        >
        > Thank you all for your insights. Even as a lurker I have found this
        > list to be very thoughtful and informative.
        >
        > --
        > Brian
        >
        >


        [Non-text portions of this message have been removed]
      • Ron Jeffries
        ... Are there different elements of data? Different ways of running it through the system? Will there be a queue of data from the new device separate from the
        Message 3 of 12 , Dec 21, 2005
        • 0 Attachment
          On Wednesday, December 21, 2005, at 9:08:53 AM, Brian Victor wrote:

          > My question is with regard to how to split broad user stories into more
          > estimable pieces. We have an existing system that needs to receive data
          > from a new device, and the story was essentially, "acquire data from the
          > device and run it through the existing system." Because of the way the
          > existing software is designed, this touches several modules, and my
          > coworker and I were drawn into splitting it into technical details that
          > weren't really relevant to the user.

          > Is it your sense that user stories should explicitly not contain
          > under-the-cover details? Are there better ways to split something like
          > this which is, to the user, a single task?

          Are there different elements of data? Different ways of running it
          through the system? Will there be a queue of data from the new
          device separate from the old devices?

          Could we read a subset of the data from the device and show that it
          is correctly formatted, then expand the subset? Could we gin up a
          queue of data as if from the new device and show that it can run
          through the system once we get it collected?

          Ron Jeffries
          www.XProgramming.com
          You don't need to see my identification.
          These aren't the ideas you're looking for. Move along.
        • Kent Beck
          Brian, When I try to create bite-sized stories, I often need to let go of my desire to do all of everything at once. For example, I was talking to a team who
          Message 4 of 12 , Dec 22, 2005
          • 0 Attachment
            Brian,

            When I try to create bite-sized stories, I often need to let go of my desire
            to do all of everything at once. For example, I was talking to a team who
            needed to produce weekly activity reports in PDF so their customer could
            bill his clients. My suggestion was to just produce comma-separated files at
            first. I think what I noticed about the original story was the goal, "...so
            their customer could bill his clients." The more I write stories from the
            point of view of the customer's needs, the better job I seem to do.

            With your example, I would ask myself what would make an effective demo. If
            just acquiring data from the new source would be seen as progress, then just
            do that and output the data in the cheapest possible format, like numbers
            spewing out of a terminal emulator.

            Sincerely yours,

            Kent Beck
            Three Rivers Institute

            > -----Original Message-----
            > From: extremeprogramming@yahoogroups.com
            > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Brian Victor
            > Sent: Wednesday, December 21, 2005 6:09 AM
            > To: extremeprogramming@yahoogroups.com
            > Subject: [XP] Starting XP and splitting user stories
            >
            > Hi all! I've read much about XP and agile programming over the years,
            > and gleaned many gems of information off the c2 wiki. Although I
            > haven't tried it completely yet, I have put some of the
            > attitudes (TDD,
            > constant refactoring) into use in my own code and have been pleased.
            >
            > I'm trying to begin to use XP as a whole at my workplace, and
            > I have one
            > coworker who seems to be ready to come along for the ride. We are
            > trying an XP approach to a development effort that the two of us are
            > working on for the next couple of months. I pointed him at
            > c2, and I'm
            > trying to reinforce concepts as they become relevant. One of
            > the first
            > ones that came up was user stories.
            >
            > My question is with regard to how to split broad user stories
            > into more
            > estimable pieces. We have an existing system that needs to
            > receive data
            > from a new device, and the story was essentially, "acquire
            > data from the
            > device and run it through the existing system." Because of
            > the way the
            > existing software is designed, this touches several modules, and my
            > coworker and I were drawn into splitting it into technical
            > details that
            > weren't really relevant to the user.
            >
            > Is it your sense that user stories should explicitly not contain
            > under-the-cover details? Are there better ways to split
            > something like
            > this which is, to the user, a single task?
            >
            > Thank you all for your insights. Even as a lurker I have found this
            > list to be very thoughtful and informative.
            >
            > --
            > Brian
            >
            >
            >
            > To Post a message, send it to: extremeprogramming@...
            >
            > To Unsubscribe, send a blank message to:
            > extremeprogramming-unsubscribe@...
            >
            > ad-free courtesy of objectmentor.com
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >
          • Brian Victor
            ... [snip] ... There is header information, then a single raw stream of data. There is a single entry point to the analysis, which currently reads from files.
            Message 5 of 12 , Dec 23, 2005
            • 0 Attachment
              Ron Jeffries wrote:
              > On Wednesday, December 21, 2005, at 9:08:53 AM, Brian Victor wrote:
              >>My question is with regard to how to split broad user stories into more
              >>estimable pieces. We have an existing system that needs to receive data
              >>from a new device, and the story was essentially, "acquire data from the
              >>device and run it through the existing system." Because of the way the
              >>existing software is designed, this touches several modules, and my
              >>coworker and I were drawn into splitting it into technical details that
              >>weren't really relevant to the user.
              [snip]
              > Are there different elements of data? Different ways of running it
              > through the system? Will there be a queue of data from the new
              > device separate from the old devices?

              There is header information, then a single raw stream of data. There is
              a single entry point to the analysis, which currently reads from files.
              These files can already be generated from the device with
              post-processing, but the goal of this story is to stream the data
              straight from the device to the analysis.

              > Could we read a subset of the data from the device and show that it
              > is correctly formatted, then expand the subset? Could we gin up a
              > queue of data as if from the new device and show that it can run
              > through the system once we get it collected?

              To the degree that a file can simulate data from the device, we're
              already doing that. There are really three distinct things involved in
              this story. One is to allow the analysis program to read data from a
              stream rather than a file. One is to write the layer to push data from
              the device into the analysis stream. One is to write the GUI to handle
              these tasks. The user won't really see the story as complete until all
              these things are done.

              It should be noted that this project is replacing an existing system,
              and the motive behind this particular story is to "do things the way the
              current system does them." There could very well be a way that provides
              better busines value that we're not seeing because we have blinders on.

              --
              Brian
            • Brian Victor
              ... Kent, This is a good insight. I think we definitely have a desire to get grandiose features working in a single iteration, a desire that probably isn t
              Message 6 of 12 , Dec 23, 2005
              • 0 Attachment
                Kent Beck wrote:
                > Brian,
                >
                > When I try to create bite-sized stories, I often need to let go of my desire
                > to do all of everything at once. For example, I was talking to a team who
                > needed to produce weekly activity reports in PDF so their customer could
                > bill his clients. My suggestion was to just produce comma-separated files at
                > first. I think what I noticed about the original story was the goal, "...so
                > their customer could bill his clients." The more I write stories from the
                > point of view of the customer's needs, the better job I seem to do.
                >
                > With your example, I would ask myself what would make an effective demo. If
                > just acquiring data from the new source would be seen as progress, then just
                > do that and output the data in the cheapest possible format, like numbers
                > spewing out of a terminal emulator.

                Kent,

                This is a good insight. I think we definitely have a desire to get
                grandiose features working in a single iteration, a desire that probably
                isn't very productive.

                I think my concern is that "data will be displayed in a terminal
                emulator" isn't something that the customer would be likely to suggest,
                because it has no particular business value. Do you feel this this is
                that something that the developers could propose as an interim story?
                From my reading it seems that would run counter to the idea of
                customer-driven story writing, but I am new at this so I'm perfectly
                willing to be wrong.

                --
                Brian
              • Ron Jeffries
                ... IANK, but I think it s perfectly fine for developers to /propose/ stories. We can t quite accomplish that, but what we could do ... There will be some
                Message 7 of 12 , Dec 23, 2005
                • 0 Attachment
                  On Friday, December 23, 2005, at 11:09:11 AM, Brian Victor wrote:

                  > I think my concern is that "data will be displayed in a terminal
                  > emulator" isn't something that the customer would be likely to suggest,
                  > because it has no particular business value. Do you feel this this is
                  > that something that the developers could propose as an interim story?
                  > From my reading it seems that would run counter to the idea of
                  > customer-driven story writing, but I am new at this so I'm perfectly
                  > willing to be wrong.

                  IANK, but I think it's perfectly fine for developers to /propose/
                  stories. "We can't quite accomplish that, but what we could do ..."

                  There will be some give and take in this, and then the team, though
                  discussion, discovers something that the developers can do and the
                  customer recognizes as valuable progress.

                  Ron Jeffries
                  www.XProgramming.com
                  The man happy in his work is not the narrow specialist,
                  nor the well-rounded man, but the man who is doing
                  what he loves to do. You must fall in love with some activity.
                  --Richard P. Feynman
                • Ron Jeffries
                  ... A valuable trick is to find ways to break stories down so that the customers can see their business value building up as each story gets done. Contrast
                  Message 8 of 12 , Dec 23, 2005
                  • 0 Attachment
                    On Friday, December 23, 2005, at 10:38:57 AM, Brian Victor wrote:

                    > To the degree that a file can simulate data from the device, we're
                    > already doing that. There are really three distinct things involved in
                    > this story. One is to allow the analysis program to read data from a
                    > stream rather than a file. One is to write the layer to push data from
                    > the device into the analysis stream. One is to write the GUI to handle
                    > these tasks. The user won't really see the story as complete until all
                    > these things are done.

                    A valuable trick is to find ways to break stories down so that the
                    customers can see their business value building up as each story
                    gets done. Contrast this to building the system up by creating
                    various infrastructure stuff, where the customer can't see it.

                    The business value approach, IME, builds trust better and yields
                    better product results.

                    > It should be noted that this project is replacing an existing system,
                    > and the motive behind this particular story is to "do things the way the
                    > current system does them." There could very well be a way that provides
                    > better busines value that we're not seeing because we have blinders on.

                    Yes. Again IME, this kind of project definition is almost invariably
                    weak. There's almost always an 80-20 thing going on. If the existing
                    system worked well, we wouldn't be wanting to replace it. So there's
                    a reason to fix it ... let's find that reason, and fix that part.

                    Not always easy. Always worth looking hard to find the way, I
                    believe.

                    Ron Jeffries
                    www.XProgramming.com
                    I could be wrong. I frequently am.
                  • Steven Gordon
                    You do not necessarily have to be able to find the problems in the old system and design fixes for them before the project begins. You can harness the
                    Message 9 of 12 , Dec 23, 2005
                    • 0 Attachment
                      You do not necessarily have to be able to find the problems in the old
                      system and design fixes for them before the project begins. You can harness
                      the customer to help discover improvements during the course of the project.

                      Delivering stories with visible business value early and often provides the
                      customer with a series of opportunities to:
                      - notice an imperfection that was there in the old system, but was not
                      readily apparent before.
                      - notice a business value, which was not available in the old system, that
                      can now be obtained.

                      These discoveries can be acted upon when developing iteratively, unlike
                      under big bang approaches. The exciting opportunity to work with the
                      customer to discover these hidden treasures and create a better system than
                      the one originally envisioned is what I like best about agile software
                      development.

                      The reason that the customer can readily notice these things is because
                      early deliveries do not yet have all the complexity and constraints of the
                      old system, yet it is working software that they can touch and feel. It is
                      like wet clay in our hands. But, you have to foster an atomsphere that
                      facilitates trust and communication to open the customer up to the
                      possibility of creating a much more useful result than a mere replacement
                      for the old system by giving each delivery a fresh look and not being afraid
                      to adjust the requirements during the project.

                      Steven Gordon


                      On 12/23/05, Ron Jeffries <ronjeffries@...> wrote:
                      >
                      > On Friday, December 23, 2005, at 10:38:57 AM, Brian Victor wrote:
                      >
                      > > To the degree that a file can simulate data from the device, we're
                      > > already doing that. There are really three distinct things involved in
                      > > this story. One is to allow the analysis program to read data from a
                      > > stream rather than a file. One is to write the layer to push data from
                      > > the device into the analysis stream. One is to write the GUI to handle
                      > > these tasks. The user won't really see the story as complete until all
                      > > these things are done.
                      >
                      > A valuable trick is to find ways to break stories down so that the
                      > customers can see their business value building up as each story
                      > gets done. Contrast this to building the system up by creating
                      > various infrastructure stuff, where the customer can't see it.
                      >
                      > The business value approach, IME, builds trust better and yields
                      > better product results.
                      >
                      > > It should be noted that this project is replacing an existing system,
                      > > and the motive behind this particular story is to "do things the way the
                      > > current system does them." There could very well be a way that provides
                      > > better busines value that we're not seeing because we have blinders on.
                      >
                      > Yes. Again IME, this kind of project definition is almost invariably
                      > weak. There's almost always an 80-20 thing going on. If the existing
                      > system worked well, we wouldn't be wanting to replace it. So there's
                      > a reason to fix it ... let's find that reason, and fix that part.
                      >
                      > Not always easy. Always worth looking hard to find the way, I
                      > believe.
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > I could be wrong. I frequently am.
                      >


                      [Non-text portions of this message have been removed]
                    • Jim Standley
                      Amen. I just went through one of these and we all thought the old system is the requirements for the new system was very harmful. It prevented us from doing
                      Message 10 of 12 , Dec 24, 2005
                      • 0 Attachment
                        Amen. I just went through one of these and we all thought "the old
                        system is the requirements for the new system" was very harmful. It
                        prevented us from doing better things, caused us to duplicate some
                        defects and turned any improvements we did come up with into a time /
                        budget problem. Ouch.


                        >>It should be noted that this project is replacing an existing system,
                        >>and the motive behind this particular story is to "do things the way the
                        >>current system does them." There could very well be a way that provides
                        >>better busines value that we're not seeing because we have blinders on.
                        >
                        >
                        > Yes. Again IME, this kind of project definition is almost invariably
                        > weak. There's almost always an 80-20 thing going on. If the existing
                        > system worked well, we wouldn't be wanting to replace it. So there's
                        > a reason to fix it ... let's find that reason, and fix that part.
                        >
                        > Not always easy. Always worth looking hard to find the way, I
                        > believe.
                        >
                        > Ron Jeffries
                        > www.XProgramming.com
                        > I could be wrong. I frequently am.
                      • Kent Beck
                        Brian, In your case, it sounded like you and your customer both needed more-frequent feedback than you would get with the stories they could write alone.
                        Message 11 of 12 , Jan 3, 2006
                        • 0 Attachment
                          Brian,

                          In your case, it sounded like you and your customer both needed
                          more-frequent feedback than you would get with the stories they could write
                          alone. That's a good time to start a conversation around the stories, "I
                          understand that you want to see the data run all the way through the system.
                          That's certainly my goal too. At the moment, though, I am worried about just
                          acquiring the data first. I will have that done on Friday, but it won't be
                          going through the rest of the system yet." This is the start of the
                          conversation. From there the customer could say, "Yes, fine," or "I'd rather
                          just see our test data run through the rest of the system," or "I'm not
                          interested in seeing a demo until I can see the whole thing" to which I can
                          reply, "Fine, but I'll send you a status report Friday to confirm that I'm
                          on target."

                          Encouraging customers to express themselves through stories is intended to
                          give customers an avenue of expression, not remove an avenue of expression
                          for programmers.

                          Sincerely yours,

                          Kent Beck
                          Three Rivers Institute

                          > -----Original Message-----
                          > From: extremeprogramming@yahoogroups.com
                          > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Brian Victor
                          > Sent: Friday, December 23, 2005 8:09 AM
                          > To: extremeprogramming@yahoogroups.com
                          > Subject: [XP] Re: Starting XP and splitting user stories
                          >
                          > I think my concern is that "data will be displayed in a terminal
                          > emulator" isn't something that the customer would be likely
                          > to suggest,
                          > because it has no particular business value. Do you feel
                          > this this is
                          > that something that the developers could propose as an interim story?
                          > From my reading it seems that would run counter to the idea of
                          > customer-driven story writing, but I am new at this so I'm perfectly
                          > willing to be wrong.
                        • J. B. Rainsberger
                          ... Ask: What s the good business reason for doing this? Make that your first-cut story. Now ask: What s the thinnest end-to-end slice I can build that
                          Message 12 of 12 , Jan 12, 2006
                          • 0 Attachment
                            Brian Victor wrote:

                            > My question is with regard to how to split broad user stories into more
                            > estimable pieces. We have an existing system that needs to receive data
                            > from a new device, and the story was essentially, "acquire data from the
                            > device and run it through the existing system." Because of the way the
                            > existing software is designed, this touches several modules, and my
                            > coworker and I were drawn into splitting it into technical details that
                            > weren't really relevant to the user.

                            Ask: "What's the good business reason for doing this?" Make that your
                            first-cut story.

                            Now ask: "What's the thinnest end-to-end slice I can build that would do
                            something useful?" The words 'end-to-end' are important here. That
                            becomes your first split-off story from the big one.

                            > Is it your sense that user stories should explicitly not contain
                            > under-the-cover details? Are there better ways to split something like
                            > this which is, to the user, a single task?

                            Stories are about delivering value; tasks are about how we make that
                            happen. Stories are "vertical"; tasks are "horizontal". Splitting a
                            story into tasks--if we bother to do that--is about understanding how to
                            solve the problem. Splitting a story into smaller stories is about
                            understanding the scope of the problem.

                            I hope that helps.
                            --
                            J. B. (Joe) Rainsberger :: http://www.jbrains.info
                            Your guide to software craftsmanship
                            JUnit Recipes: Practical Methods for Programmer Testing
                            2005 Gordon Pask Award for contribution Agile Software Practice
                          Your message has been successfully submitted and would be delivered to recipients shortly.