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

Re: Backlog of technical tasks?

Expand Messages
  • Kane Mar
    ... I d like to re-iterate what George has said. He has managed to eloquently say the words that I ve been struggling for especially when he says: I ve always
    Message 1 of 55 , May 1, 2008
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "MacKilby" <mckilby@...> wrote:
      >
      > --- In scrumdevelopment@yahoogroups.com, "Jim Schiel" <schiel@> wrote:
      >
      > > >
      > > > Bottom line -- technical debt is no different than anything else
      > on the
      > > > backlog. Don't treat it like a second class citizen -- it's always
      > going to
      > > > be there and everyone should get used to it being there.
      > > >
      >
      > Agreed... and now let me share more of the story that prompted the
      > question.
      >
      > When I implied a large technical debt, I was thinking of those
      > companies that had legacy code bases to deal with. One group I know
      > solved that problem of dealing with legacy debt by incorporating the
      > "payment plan" into the backlog. That is, because they had a large
      > technical debt with their legacy codebase, the team and PO agreed that
      > they would try to include a certain percentage of technical debt
      > stories in each sprint until debt was paid down below a certain
      > threshold and they made this team ground rule visible. So not only
      > did they make their commitment to the debt visible in the backlog, but
      > they also made the payment plan toward improved quality visible to
      > stakeholders by keeping the groundrules visible.
      >
      > So I agree that technical debt should be balanced with other factors
      > the PO must consider and that balancing should be made visible through
      > the project backlog and the methods to prioritize the backlog.

      I'd like to re-iterate what George has said. He has managed to eloquently say the words
      that I've been struggling for especially when he says: "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."

      I very much like the analogy of a sales tax (aka GST, VAT etc) rather than a mortgage
      repayment analogy. When I buy a coffee at Starbucks is cost me about $3.50 and then I
      have to add on a 9.5% sales tax.

      I pay this tax at the same time as I purchase the coffee. I don't wait until the end of the
      year and pay all my sales taxes separately. It's all part of my spending. And so, I feel it
      should be with technical debt ... something that the team always needs to do and should
      not be considered separate from their day to day activities.

      Best regards,
      Kane Mar
      b: http://KaneMar.com
      b: http://SeattleScrum.org
      w: http://www.Danube.com
    • 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.