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

RE: [scrumdevelopment] Sprint versus Product Backlog (was:Scrum vs A d Hoc methods)

Expand Messages
  • Tony Homer
    I accidentally moved the [scrumdevelopment] tag into the middle of the subject header, probably playing havoc with many of your filters. Sorry about that. Tony
    Message 1 of 1 , Jul 11, 2003
    View Source
    • 0 Attachment
      I accidentally moved the [scrumdevelopment] tag into the middle of the subject header, probably playing havoc with many of your filters.
       
      Sorry about that.
      Tony
      -----Original Message-----
      From: Tony Homer [mailto:tony_homer@...]
      Sent: Friday, July 11, 2003 12:09 PM
      To: 'scrumdevelopment@yahoogroups.com'
      Subject: Sprint versus Product Backlog (was: [scrumdevelopment] Scrum vs A d Hoc methods)

      I think I understand the difference between Sprint and Product Backlog.  The Product Backlog is the Product Owner's tool for keeping track of all the work to be done on the Product and the units are User Stories or Use Cases or some other high-level explanation of requirements, depending on what Scrum is wrapping.  The Sprint Backlog is the team's tool for keeping track of the work they've agreed to do in a Sprint.  So during the Sprint Planning Session, the selected Stories move from the Product Backlog to the Sprint Backlog and then over the course of the Sprint, explode into more detailed work tasks.  So the Sprint Backlog is the team's tool for coordinating effort during a Sprint.
       
      My team has a consolidated Sprint/Product Backlog.  Generally, the tasks that would correspond to a Product Backlog item are more detailed than User Stories (but not too much).  During the Sprint Planning Session we flag the items we will do during the Sprint.  This subset of the Product Backlog becomes our Sprint Backlog.  Then we expand on those tasks primarily with addiitonal appended comments, but sometimes a large task explodes into a bunch of smaller tasks.  Our combined backlog is currently a legacy Access buglog (from waterfall days) that we've enhanced to support Scrum by adding additional fields and expanding usage.  We'll be moving to bugzilla in the next 60 days or so, but plan to continue the unified backlog approach.
       
      I'm not sure if this is equivalent to the model Ken describes below or not.  Is there a percentage in trying to evolve our tools such that the Product Backlog and Sprint Backlog are truly distinct?  In other words, are we losing anything with a unified backlog approach?  What else should the team be doing with the Sprint Backlog?
      -----Original Message-----
      From: Ken Schwaber [mailto:ken.schwaber@...]
      Sent: Friday, July 11, 2003 9:30 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Scrum vs Ad Hoc methods

      I'll back Bryan on this one. When we implement Scrum without the proper
      engineering practices being started up, we risk having iterative hacking.
      It's true that we get to inspect every thirty days, but the people
      inspecting have to know what to inspect. I think we should emphasize the
      engineering evaluation as part of being a ScrumMaster. The output of every
      Sprint is an increment of potentially shippable product functionality. We
      should take on ensuring that it is truly shippable. Whenever it isn't, the
      corrective work gets rolled over to the next Sprint, along with some new
      product backlog to investigate and implement corrective engineering
      practices.

      A tip off is the Sprint Backlog. The two administrative responsibilities for
      a Scrum team are the Daily Scrum and the Sprint Backlog. The Sprint Backlog
      is their planning mechanism where the team lays out the Sprint tasks. If the
      team never lays out the tasks, then it doesn't need the Sprint Backlog. If
      the team never thinks through what it is going to do and just starts
      hacking, it certainly doesn't need it. So, to me, the presence of the Sprint
      Backlog comforts me that the team has at least put thought into their work.

      Ken

      -----Original Message-----
      From: Bryan Zarnett [mailto:bzarnett@...]
      Sent: Friday, July 11, 2003 8:42 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Scrum vs Ad Hoc methods



      On Friday, July 11, 2003, at 07:59AM, Robert Henley <rhenley@...>
      wrote:

      >It seems to me that our biggest foes (and thus greatest potential market)
      are not the users of >heavyweight methodologies, but the users of ad hoc
      methods. The heavyweight method users at least >appreciate that you need a
      method.

      I think our biggest foe is not "ad hoc" methodologies but individuals who
      believe that their approach is not "ad hoc" (even though it is), and believe
      that is the only way for development to proceed.

      In a company where I brought in XP (a long time ago in the DOT-COM era), we
      had sme nice success coming in under time and budget while keeping a 1 hour
      Quake game time, and leading by 5, and not starting till 9 or 9:30.  It was
      a nice group of people, of various levels of experience -- everyone had good
      ethics though and where fun to be with.  After our success another
      individual commented that it was a fluke and cited his years of experience
      where "bugs, delays, etc." where "just how it was"

      In many circumstances, the process is not the issue but the foundation of
      the developers -- often there is none. There basics and attitude are so poor
      that they can not, and do not understand how to do there work properly. If
      we say you need to do test-first development; how do we expect them to do
      this when they can't write basic code or understand the fundamentals of good
      design in a project.

      Given the current percentage of good programmers to poor programmers, our
      biggest issue is lack of skill which leads to poor practices being
      implemented. One Sr. Technical Guru I know on a project does not believe in
      documentation or coding conventions, so the projects have none. That is the
      practice - he also has never written any code other than some Cobol (not
      dishing the Cobol people).

      I think lack of proper education is our biggest foe.


      Sorry for the rant. I still need my morning coffee.





      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/




      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.