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

2932RE: Re[2]: [scrumdevelopment] Re: What to do with "loose ends"

Expand Messages
  • Charlie Trainor
    Mar 9, 2004
    • 0 Attachment
      >> Yes, but is it not true that these low priority "loose ends" tend
      to stay in the "Product Backlog" forever?
      >> That was what I understood to be the original question.

      MF> There's another possibility. You could just drop them after a few
      MF> sprints by convention. I can understand that being contentious
      but it
      MF> has its advantages. If an idea is really worthwhile, it will come
      MF> again, and perhaps with enough passion and interest that next time
      MF> it to become part of a sprint. If it never comes up again, it
      MF> probably means that it was a fluke.

      Absolutely, drop the stuff that clearly won't make it into a sprint in
      the foreseeable future. In addition to the reasons Michael mentions,
      it gets to be a big administrative burden to carry around an
      ever-increasing backlog. And as the system grows and evolves, and
      people's understanding grows, a lot of the backlog items would need to
      be re-written anyway to make sense, even if they did become high
      enough priority to make it into a sprint.

      If you find yourself adding a lot of items to a backlog, and then
      dumping them later as low priority, you'd be better off trying to
      filter out more of those low priority items up front. There is a
      natural tendency to want to capture every little idea and
      nice-to-have - one of my current duties as product owner is to make
      sure people concentrate on the core stuff, reassuring them that we'll
      be in a much better position to understand and assess the importance
      of the other stuff later in the project. I know that if the product
      backlog gets too large, we will be just as likely to forget stuff
      because we lose sight of it in a massive backlog as we would be to
      forget it because it isn't there in the first place. This is a hard
      nut for some people to swallow (and a good indication if they are
      really getting into an agile mindset).

      Getting back to the original problem Dennis raised, the goal is to
      avoid having those little cleanup items in the first place. When
      customers or testers are working closely with developers, most of
      those little problems will get cleaned up
      before the end-of-sprint demo. If the software really doesn't look
      ready for prime time, a customer or tester will be more likely to say
      "no, it isn't ready yet! Better fix it before showing it in the demo."
      I've found it is obvious in a demo whether developers have been
      working on their own, or have been getting good feedback from someone
      with more of a business / end-user focus.

      - Charlie
    • Show all 26 messages in this topic