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

Re: Backlog of technical tasks?

Expand Messages
  • Kane Mar
    ... I have no issue with making things visible. I think that transparency/visibility is good and healthy for teams and I would encourage that. We are in
    Message 1 of 55 , May 1, 2008
      --- In scrumdevelopment@yahoogroups.com, "Stephen Bobick" <sbobick2@...> wrote:
      >
      > If the organization ignores the Team repeatedly - a Team who predicts
      > failure if they aren't listened to regarding technical debt and an
      > unmaintable code base, and the organization drives the Team over a cliff,
      > well, why not point that out?

      I have no issue with making things visible. I think that transparency/visibility is good and
      healthy for teams and I would encourage that. We are in violent agreement on this point.

      I do however have an issue with finding fault. The quote from Mike D "When it crashes
      down you will have the documentation to help management find a new PO," read (to me)
      as if as thought he was advocating using the Backlog to attribute fault should a project
      not work out. This is something that I don't agree with because, when projects go bad, I
      believe it's everyone's responsibility.

      Having said all that, I could well have interpreted Mike's words incorrectly, or considered
      them out of context, which is why I asked the questions that I did.

      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
        --- 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.