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

Re: Defining your product backlog

Expand Messages
  • 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 1 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 2 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.