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

Re: Backlog of technical tasks?

Expand Messages
  • Tobias Mayer
    This is a very interesting thread, with lots of different ideas. Two ... in the course of adding new features. As you touch legacy code, you leave it a
    Message 1 of 55 , May 1, 2008
    • 0 Attachment
      This is a very interesting thread, with lots of different ideas.  Two recent comments have helped me to clarify my thoughts on this:

      >
      I've always found it possible to refactor and pay down technical debt in  the course of adding new features. As you touch legacy code, you leave  it a little cleaner and easier to use than it was before. -- George Dinwiddie

      > On a healthy team, we handled as much debt as we could with each story as the story touched it.  -- Rob Park

      Technical debt should be handled as part of a story, wherever possible.

      The reason I do not like technical debt/clean up work to be on the Product Backlog is because the items are almost exclusively "how" items.   As soon as you put "how" items on the Product Backlog, then in my opinion you are not leveraging the power of Scrum but are slipping back into micro-management mode.

      A team should always be calling out technical debt items, and keeping them as a task list.  These are tasks that will often become tasks for a particular story, but other times they will cross over multiple stories and just have to be attacked independently.   The latter case is rarer, and allowing slack time for such work is sometimes necessary. 

      For me this issue really does come down to "what" versus "how".   Focusing only on what the customer wants is one of the hardest things to get PO's to understand when they are moving from creating PRDs to creating Scrum Product Backlogs.  If we continue to advise POs that everything should be on the backlog, the separation between "what" and "how" becomes messy, and things begin to spiral out of control.  I have seen this.

      Technical tasks do NOT belong on the Product Backlog.

      Tobias



      --- In scrumdevelopment@yahoogroups.com, "Rob Park" <robert.d.park@...> wrote:
      >
      > I believe the crux of the issue is that it can be hard to justify technical stories in terms of business value. If you can't make that justification, you can't prioritize it as part of the backlog.
      >
      > E.g. Why does the customer want/need me to refactor xyz() into class J?
      >
      > We all know the technical debt needs to be worked down, so some are saying just put it on the side and handle it as overhead via slack.
      >
      > On a healthy team, we handled as much debt as we could with each story as the story touched it. On a not yet healthy team, we are putting them on the sprint directly, because in fact it's easier to justify the customer value when you're having issues.
      >
      > .rob.
      >
    • Michael James
      ... Yes, and there s really no contradiction between these approaches once we see the Sprint Planning Meeting as a good faith negotiation. Normal technical
      Message 55 of 55 , May 4, 2008
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, "Jeppe N. Madsen" <jeppe@...> wrote:

        > I've been skeptical about putting technical tasks on the backlog for
        > many of the same reasons listed in this thread. I think we should
        > make "the world a better place" one step at a time, by refactoring the
        > code as it's touched due to new requirements.

        Yes, and there's really no contradiction between these
        approaches once we see the Sprint Planning Meeting
        as a good faith negotiation.

        Normal technical debt should be paid off through
        the definition of "done" for product feature stories.
        Things like this might include refactoring away
        duplicate code, complex conditional logic, long
        modules, nested "catch" blocks, poorly named
        methods and classes, normal database schema
        changes, normal upgrades to third-party
        libraries....

        > If there really are technical debt that hinders
        > progress, this is an impediment.

        Yes, when progress on multiple fronts is impeded
        by severe fundamental underlying debt issues
        (often at the infrastructure level, like platform
        changes, major database changes, major library
        changes) it may be useful for the team to make
        it visible in the product backlog as a step toward
        breaking the repayment work into manageable
        pieces. Anyone can add items to the Product
        Backlog.

        Of course we still expect some feature delivery
        every Sprint.

        --mj
      Your message has been successfully submitted and would be delivered to recipients shortly.