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

RE: [scrumdevelopment] Maintaining Product Backlog estimates

Expand Messages
  • Mike Cohn
    Convincing that group about mock objects hasn t gone so well yet. I showed them your example of mocking out the database in the login code. They didn t see the
    Message 1 of 13 , Sep 11, 2002

      Convincing that group about mock objects hasn’t gone so well yet. I showed them your example of mocking out the database in the login code. They didn’t see the value. I finally got them to understand that if each successive layer in an app is tested then the next layer only needs to test its own behavior—not everything beneath (e.g., the database). I’ll keep trying on them but for now I can’t convince them that they’re headed for trouble as the time it takes to run their unit tests gets very lengthy. Ugh.

       

      I’ve added XPlanner to my “check it out” list and will get to it as soon as I can. I never use index cards as my teams always seem to be distributed. I’ve actually never got the appeal to them when I’ve got a perfectly fine computer in front of me.

       

      --Mike

       

      -----Original Message-----
      From: John Goodsen [mailto:jgoodsen@...]
      Sent: Tuesday, September 10, 2002 11:48 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Maintaining Product Backlog estimates

       

      (Hi Mike - how's your mock injection going? ;-)

      Yes - we use XPlanner for distributed teams - I think there is a Oracle
      user out there somewhere.  It's not as handy as index cards but
      when your customer is somewhere else or part of the team is
      somewhere else, it really helps close the gap well:

      It's easy to setup and get running if you have a Tomcat server
      up and running...

      http://xplanner.sourceforge.net

      --
      John Goodsen           RADSoft / Rapid Software Delivery Specialists
      jgoodsen@...             eXtreme Java Internet Consultants
      http://www.radsoft.com           Toll Free: 866-RADSOFT (723-7638)


      Mike Cohn wrote:
      > I read it's homepage and was very intrigued but since I've already got
      > Oracle and SQL Server all over my machines I didn't have time to install
      > another database and check it out.
      >
      >
      >
      > I track things mostly via Excel spreadsheet but am currently configuring
      > a defect tracker (TestTrack from Seapine) to track my sprints for me.
      >
      >
      >
      > Have you used XPlanner? How good is it?
      >
      >
      >
      > --Mike
      >
      >
      >
      > -----Original Message-----
      > From: John Goodsen [mailto:jgoodsen@...]
      > Sent: Tuesday, September 10, 2002 10:56 AM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: Re: [scrumdevelopment] Maintaining Product Backlog estimates
      >
      >
      >
      > I'm curious - Is anyone using XPlanner to help manage distributed
      > SCRUM teams?


      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.
    • Ken Schwaber
      Tommy, The Product Backlog is maintained as often as needed by the product owner in response to changes in product requirements dictated by changes in the
      Message 2 of 13 , Sep 15, 2002
        Tommy,
        The Product Backlog is maintained as often as needed by the product owner in
        response to changes in product requirements dictated by changes in the
        business, changes in competition, changes regarding what will provide the
        most value, changes in technology ... the product backlog is meant to evolve
        as the technology, team, and business requirements evolve, so that the value
        of each deliverable is optimized. The product backlog is usually maintained
        on a public server, visible to all, at which the product owner can provide
        realtime updates. The product backlog is only affected by the sprint backlog
        at the end of each Sprint, when the uncompleted product backlog from that
        sprint is put back on the product backlog and reprioritized. The product
        backlog selected at the start of each sprint is used as a basis, or starting
        point, for creating the sprint backlog.

        Yes, the initial sprint backlog is often decomposed into >N tasks.

        Product backlog consists of functional and non-functional requirements, that
        is, what is needed in the product or system. The sprint backlog consists of
        the tasks that the team figures they will need to do to turn the product
        backlog into working product functionality.

        Ken Schwaber

        -----Original Message-----
        From: Tommy Kelly [mailto:tommyk@...]
        Sent: Tuesday, September 10, 2002 8:59 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Maintaining Product Backlog estimates


        The black book recommends that the Product Owner updates
        the Product Backlog estimates on a weekly basis.
        How is this done considering that:

        a. The PO may be a customer,
        who isn't on site on a weekly basis
        and
        b. Even if the PO *is* on site, the only
        information available will be that
        obtained by *listening* (I'm assuming that
        the PO is a chicken) at Daily Scrums.
        (And the three questions don't include
        "how long do you estimate is remaining
        for Sprint Backlog item X").

        While I'm here, I'm assuming that the Sprint
        Backlog of N items may be decomposed into
        >N tasks. Yes?

        If so, do team members claim ownership of Sprint
        Backlog items, or of the constituent tasks?

        thanks,
        Tommy



        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 http://docs.yahoo.com/info/terms/
      • Ken Schwaber
        Thanks, Mike. Right on. Ken ... From: Mike Cohn [mailto:mike@mountaingoatsoftware.com] Sent: Tuesday, September 10, 2002 10:07 AM To:
        Message 3 of 13 , Sep 15, 2002
          Thanks, Mike. Right on.
          Ken
          -----Original Message-----
          From: Mike Cohn [mailto:mike@...]
          Sent: Tuesday, September 10, 2002 10:07 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] Maintaining Product Backlog estimates

          First, on many of the projects I’ve done the Product Owner ends up not being a customer because on commercial products it just isn’t feasible. On projects delivering software for internal it’s much more viable and I have done that—on the other hand, even then, it usually ends up being the Scrum Master who updates backlogs.  As a ScrumMaster I will typically make sure backlog estimates are up to date and then I make sure the team (including the Product Owner) has the new information.

           

          I may has glossed over the exact wording in the book but it probably says that the Sprint Backlog (not the Product Backlog) is updated weekly. Sprint Backlog is the items selected for completion in the current sprint; Product Backlog is everything left out. I update the Sprint Backlog at least once a week; I update the Product Backlog only in the week before we start planning the next sprint.

           

          Updating the Sprint Backlog is more of a continuous activity. I don’t really sit down and say “now I’m going to update all of the sprint backlog.” Rather, as I get new information from team members I update the backlog. I get the information from talking to each of the developers outside the daily Scrum meeting. I may talk to some but not all developers on a given day so I’ll update backlog items based on what they’ve said. Typically I’ll ask how much is left on a task (I *never* ask how much has been expended on a task because it’s irrelevant) but I may also hear that a task no one has started yet is going to be harder/easier than planned or that we forgot to add tasks onto the list.  You also pick up stuff during the daily Scrum that can help you update the Sprint Backlog. You’ll certainly hear a programmer say things like “I finished the search screen yesterday so today I’m going to start on the search-results screen and with any luck I’ll finish that today.”  The daily scrum is all about commitments from one individual to the team so you hear what they finished (estimates on those go to 0 obviously!) and you hear what they’re doing today (which gives you some guidance about how long is left, sometimes enough to put in a guess for the remaining duration).

           

          Yes, a Sprint backlog of N tasks becomes at least N tasks. (It may be N.)

           

          More and more lately I’ve been using XP-style stories as my Product Backlog items and then when those Stories move into Sprints they are decomposed into tasks. The Product Backlog has things other than just Stories because Scrum isn’t as maniacally focused on the same goals as XP but the majority of my Product Backlog items are becoming User Stories. Other items like, “Document the design of the data storage classes” or “Speed up the customer query” are on there.

           

          --Mike

           

          -----Original Message-----
          From: Tommy Kelly [mailto:tommyk@...]
          Sent: Tuesday, September 10, 2002 6:59 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Maintaining Product Backlog estimates

           

          The black book recommends that the Product Owner updates
          the Product Backlog estimates on a weekly basis.
          How is this done considering that:

                a. The PO may be a customer,
                   who isn't on site on a weekly basis
          and
                b. Even if the PO *is* on site, the only
                   information available will be that
                   obtained by *listening* (I'm assuming that
                   the PO is a chicken) at Daily Scrums.
                   (And the three questions don't include
                    "how long do you estimate is remaining
                     for Sprint Backlog item X").

          While I'm here, I'm assuming that the Sprint
          Backlog of N items may be decomposed into
          >N tasks.  Yes?

          If so, do team members claim ownership of Sprint
          Backlog items, or of the constituent tasks?

          thanks,
          Tommy



          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.




          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.