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

Re: [scrumdevelopment] Re: Level of detail for sprint backlog

Expand Messages
  • George Dinwiddie
    ... Hi, Matt. It sounds as if your project was successful with the approach you took, and I don t want to take away from your success. You and your team
    Message 1 of 21 , Aug 24, 2008
    • 0 Attachment
      Matt McClure wrote:
      > However, on one of my projects, where we started using Scrum on a
      > product that had previously accumulated many years of technical debt,
      > treating technical stories as overhead only served to hide them. With
      > them safely hidden, developers estimated customer stories without
      > considering the debt, thereby guaranteeing they wouldn't have time to
      > address it. Furthermore, architectural improvements -- another class
      > of technical overhead -- couldn't get done because they were not
      > themselves "customer stories", they were not specific to any one
      > story, and they were big enough that estimating their cost as part of
      > a customer story would have given the PO sticker shock. In this case
      > the value of visibility outweighs the cost of educating the PO
      > regarding the technical stories.

      Hi, Matt. It sounds as if your project was successful with the approach
      you took, and I don't want to take away from your success. You and your
      team should be proud of that.

      I would like to agree with Ron and point out that, if you treat
      improving the code as a normal course of events whenever you touch code,
      then you can easily clean up a smelly code base over time while
      accomplishing new stories. Your velocity will be lower than you might
      like, but still likely to be higher than if you ignore that technical debt.

      And even large architectural changes can be decomposed into a series of
      smaller refactorings given a bit of practice and skill. At least I've
      never found a case yet where this wasn't possible--I have found cases
      where people didn't yet know how to make it possible. So, while I
      applaud you for finding a solution in your situation that helped your
      team accomplish what it needed to do, I'd urge you not to stop with that
      solution, but continue to learn how to refactor architectural changes
      into smaller steps. I think it will help you, and, if it doesn't, will
      at least better inform you about what you can and cannot do.

      cheers,
      George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    Your message has been successfully submitted and would be delivered to recipients shortly.