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

Defining your product backlog

Expand Messages
  • bryan_zarnett
    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
    Message 1 of 4 , Jun 3, 2002
    • 0 Attachment
      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.
    • 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 2 of 4 , Jun 3, 2002
      • 0 Attachment

        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 3 of 4 , Jun 3, 2002
        • 0 Attachment
          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 4 of 4 , Jun 7, 2002
          • 0 Attachment

            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.