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

RE: [scrumdevelopment] Defining your product backlog

Expand Messages
  • Mike Cohn
    Bryan- I ve used a number of approaches to this, including: --XP stories (although I refuse to write them on paper when I have a perfectly decent computer)
    Message 1 of 4 , Jun 3, 2002

      Bryan

       

      I’ve used a number of approaches to this, including:

      --XP stories (although I refuse to write them on paper when I have a perfectly decent computer)

      --use cases

      --lines in an excel spreadsheet

      --test cases

       

      Of these, use-cases was the only approach that didn’t work well but I think that was more the fault of the existing corporate culture and one or two people who valued their work by the pound.

       

      I really like the idea of capturing requirements as test cases but have had trouble so far getting others on board.

       

      Right now the projects I’m working on are using just an Excel spreadsheet. I put backlog items in the excel spreadsheet. Each item is then captured in probably no more than 10-15 words. (The cell will wrap so it can go longer if necessary.) If I need more text I put that in as an Excel cell comment so it’s visible when the mouse hovers over the cell. I’ll probably stick with some variation of this but realize we need a way to relate a bit more information to each backlog item. One of the developers commented on Friday, “one of the problems with tracking backlog this way is that sometimes I forget what an item meant.”  I’m actually not sure that’s a bad thing! When we can’t remember what an “important” item even refers to and the product manager can’t either I’m usually pretty glad we didn’t implement it!

       

      In general one of the nice things about Scrum is that you can layer it into most existing techniques a company may have. If your company already uses any reasonable approach to documenting requirements you can probably make it work with Scrum—just capture a small amount of detail to start with and as backlog items near inclusion in a sprint you can fill in more detail.

       

      --Mike

       

      -----Original Message-----
      From: bryan_zarnett [mailto:bryan_zarnett@...]
      Sent: Monday, June 03, 2002 6:48 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Defining your product backlog

       

      I was curious as to what form of documentation people's requirements
      take that are included in the backlogs. Does anyone prefer a common
      template such as the XP Story Card, or Use Cases, or something custom
      driven?

      I know scrum does not mention a specific format for the documentation
      of requirements, but I am curious as to what people use and how
      effective they find specific documentation formats to be in a SCRUM-
      based management environment.

      B.


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


      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

    • Paul Hodgetts
      ... Our Product Owner/Customer wrote the requirements as light weight use cases (similar to Constantine s essential use cases or Cockburn s casual format).
      Message 2 of 4 , Jun 3, 2002
        bryan_zarnett wrote:

        > I was curious as to what form of documentation people's requirements
        > take that are included in the backlogs. Does anyone prefer a common
        > template such as the XP Story Card, or Use Cases, or something custom
        > driven?

        Our Product Owner/Customer wrote the requirements as light weight use
        cases (similar to Constantine's essential use cases or Cockburn's
        casual format). These contained each use case, and the various
        scenarios of each that were considered important. They were written
        incrementally by the PO, collaborating with the stakeholders and
        testers and developers to get just enough detail for estimating and
        testing and developing at each point in the process.

        The use cases were just written in MS Word, with each use case getting
        it's own "chapter." The use cases were used to communicate the
        requirements across the group of stakeholders, and were constantly
        referred to by different groups, so we needed something that could
        be easily duplicated and passed around as well as having permanence
        to the medium.

        The use cases were not, however, a "work unit" for development. I
        hate to call a work unit a "story" because I don't think we viewed
        them the same as an XP story, even though we called them "stories" in
        our culture. They were a token for a unit of work that the PO wanted
        done to the system, but they were not the requirements. They were
        not a use case. Some might call them a change request. The backlog
        was a collection of these work units, prioritized.

        The work units mapped to the use cases by specifying the overall
        functionality that was needed (the use case), the "breadth" of the
        functionality (the scenarios that were targeted), and the "depth" of
        the functionality (the amount of detail for the targeted scenarios).

        For example, we might target a use case of "Shopping Cart Checkout."
        The work unit might specify that we're only handling the positive path
        scenario this time. And it might specify that we're leaving out the
        calculation of taxes and fees right now. So the work unit kind of
        picks out the parts of the use case that the PO wants implemented for
        this iteration.

        The PO entered the work units into our issue tracking system
        (StarTeam) as change requests. We didn't really use them for cross-
        group communication or permanence, just for directing the short-term
        iteration work. Once they were marked complete by the testers, they
        weren't referred to much. I think the PO looked at them from time to
        time to remind himself what had been completed. In retrospect, we
        could have just as easily used index cards on a cork board, but we'd
        already laid out thousands of $$$ on StarTeam, so maybe we felt
        obligated to use it. ;-)

        The PO marked the work units with a priority, based on how they
        mapped to the particular goals at the time (reducing customer service
        calls, revenue gains, etc.), and just pulled enough off the top of
        the backlog to fill the next iteration. We had a pretty fluid dot-
        com business, so the backlog changed priorities a lot, and longer-
        term release plans (anything out more than a couple of months), while
        done from time to time to get a feel for potential longer-term
        progress, didn't have as much importance.

        To clarify how we used use cases and work units, the collection of
        use cases represented the overall functionality of the system (as it
        was known at a given point in time, not BDUF'ed). The work units
        represented how we were going to implement all that functionality.
        The work units were the puzzle pieces that were incrementally placed
        in the overall use case puzzle.

        This sounds a bit more formal than it was in practice. We kept
        things pretty light weight and it flowed pretty easily with the
        process. It was a smaller team -- one Product Owner, one Tester,
        one Coach/Manager, and four to six Developers. There were a group
        of stakeholders, ranging from end-user customers, to CSRs, to back
        office folks, so the PO had some challenges in building a single
        product vision from them all. I was involved with the project for
        about a year, it had some great success, and it's still ongoing.

        I'm sorry if that was too long-winded. Questions/comments welcome.

        Regards,
        Paul
        -----
        Paul Hodgetts -- Principal Consultant
        Agile Logic -- www.agilelogic.com
        Training, Mentoring, Development -- Agile Processes, XP, Java, J2EE, C++
        -----
        Don't miss XP/Agile Universe, August 4-7, 2002 -- www.xpuniverse.com
        See our tutorial -- Beyond the Customer: Agile Business Practices for XP
      • alice.o'hanlon@rich.frb.org
        Hallelujah - Common Sense! Alice S. O Hanlon Federal Reserve Bank of Richmond Success Begins With IDEAS! Inter-District Enterprise Application Solutions
        Message 3 of 4 , Jun 7, 2002

          Hallelujah - Common Sense!



          Alice S. O'Hanlon
          Federal Reserve Bank of Richmond

          Success Begins With IDEAS!
          Inter-District Enterprise Application Solutions


          804-697-8617      
          alice.o'hanlon@...



          "Mike Cohn" <mike@...>

          06/03/2002 11:31 AM
          Please respond to scrumdevelopment

                 
                  To:        <scrumdevelopment@yahoogroups.com>
                  cc:        
                  Subject:        RE: [scrumdevelopment] Defining your product backlog


          Bryan—
           
          I've used a number of approaches to this, including:
          --XP stories (although I refuse to write them on paper when I have a perfectly decent computer)
          --use cases
          --lines in an excel spreadsheet
          --test cases
           
          Of these, use-cases was the only approach that didn't work well but I think that was more the fault of the existing corporate culture and one or two people who valued their work by the pound.
           
          I really like the idea of capturing requirements as test cases but have had trouble so far getting others on board.
           
          Right now the projects I'm working on are using just an Excel spreadsheet. I put backlog items in the excel spreadsheet. Each item is then captured in probably no more than 10-15 words. (The cell will wrap so it can go longer if necessary.) If I need more text I put that in as an Excel cell comment so it's visible when the mouse hovers over the cell. I'll probably stick with some variation of this but realize we need a way to relate a bit more information to each backlog item. One of the developers commented on Friday, "one of the problems with tracking backlog this way is that sometimes I forget what an item meant."  I'm actually not sure that's a bad thing! When we can't remember what an "important" item even refers to and the product manager can't either I'm usually pretty glad we didn't implement it!
           
          In general one of the nice things about Scrum is that you can layer it into most existing techniques a company may have. If your company already uses any reasonable approach to documenting requirements you can probably make it work with Scrum—just capture a small amount of detail to start with and as backlog items near inclusion in a sprint you can fill in more detail.
           
          --Mike
           
          -----Original Message-----
          From:
          bryan_zarnett [mailto:bryan_zarnett@...]
          Sent:
          Monday, June 03, 2002 6:48 AM
          To:
          scrumdevelopment@yahoogroups.com
          Subject:
          [scrumdevelopment] Defining your product backlog

           
          I was curious as to what form of documentation people's requirements
          take that are included in the backlogs. Does anyone prefer a common
          template such as the XP Story Card, or Use Cases, or something custom
          driven?

          I know scrum does not mention a specific format for the documentation
          of requirements, but I am curious as to what people use and how
          effective they find specific documentation formats to be in a SCRUM-
          based management environment.

          B.


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


          Your use of Yahoo! Groups is subject to the
          Yahoo! Terms of Service.

          Yahoo! Groups Sponsor
          ADVERTISEMENT



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


          Your use of Yahoo! Groups is subject to the
          Yahoo! Terms of Service.

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