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

RE: [scrumdevelopment] Defining your product backlog

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