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

50217Refactoring type work in Scrum

Expand Messages
  • Chuck B
    Feb 2 1:22 PM
    • 0 Attachment
      Bennyou/Ron Jeffries(and whoever else wants to comment),

      From the thread: "Break from sprinting - a strategy sprint"
      > However the old stuff which has been isolated from is starting to get
      clunky, and we want to pre-empt inadequate performance by replacing these. The legacy parts have not been regression tested nor would the
      > effort to regression test the size of this be business feasible and
      this is scaring developers. They are moving away from the hyper-productivity that they are used to and trying to make fixes in area which sees
      > much less visible business value be delivered. Business
      does not understand the slow down of development of features.
      This kind of thing sounds like technical debt or something like it (IMO, there is not one really accepted definition of technical debt).


      One thing I believe  you've advocated in the past is "attaching" refactoring (or other similar activities, I'll just call it refactoring for now, feel free to refine that term as necessary) to new work that comes into the Product Backlog, thus including that refactoring into the estimate.

      Do you only estimate with the attached work, or do you give the PO two estimates (one with the attached work, another without)?

      I'm curious what you advise in this kind of situation, especially when the Dev Team has a strong desire to do the refactoring work.

      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/

    • Show all 25 messages in this topic