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

RE: [XP] How to handle new tasks from refactoring decision

Expand Messages
  • Bill Caputo
    Hi Mark, I am going to throw out my thoughts, not because they are necessarily right, but because this is how I understand it, and I am just as curious if I am
    Message 1 of 2 , May 2, 2000
    • 0 Attachment
      Hi Mark,

      I am going to throw out my thoughts, not because they are necessarily right, but because this is how I understand it,
      and I am just as curious if I am missing something as trying to explain, so don't take this as any *right way* unless
      verified by others.

      > My question is: How do you handle new tasks that arise from a
      > refactoring decision?

      My understanding is that they become new Engineering Tasks, and you add them to the Story they support (see below).

      > Assumptions: The refactoring does not arise from a specific story. In
      > fact, there is no directly observable "business" value. However,
      > there is directly observable development value. Additionally, the
      > refactoring will take 5 ideal days. So...

      As stated in Martin's Refactoring book, and by many on this list, you refactor when you need to make the code a good
      place for the new feature you are implementing to live. If that is why you are refactoring, I would say that the User
      Story that is being worked on is the one that gets the Engineering Tasks needed to refactor the code, since they support
      its success.

      If you are simply refactoring because the code smells, but there is no immediate gain, then you shouldn't do it. In XP
      this would violate the YAGNI, and TSTTCPW principles. OTOH if you are adding a new feature that needs the existing code
      changed, then the guideline of "Second use pays for generality" would apply.

      In short, if you are doing the refactoring for the right reason, the refactoring becomes an Engineering Task, and the
      Current User Story gets the Task.

      Another Item would be the fact that if you have estimated 5 ideal days, the only way you should arrive at that
      conclusion is if the team member who has signed up for the task estimated it as such, so it begs the existence of the ET
      or you couldn't have estimated in the first place! :)

      Finally, 5 days is a little long for a task, in general, so maybe there are two or three refactorings in there that can
      be listed as separate tasks.

      > My first thought would be to add the tasks to the current iteration.
      > Now that would decrease your story velocity (completed stories per
      > iteration) but your task velocity (completed tasks per iteration)
      > would likely remain the same. How do others handle this?

      If you make the Engineering tasks this isn't a problem. Since the scope increased (ie you added more stuff). I am hazy
      here, but my understanding is that you measure velocity strictly in terms of units completed. So if the Story has 10
      ET's and you complete 8 velocity is 8, but you now added 4 ET's so now the Story has 14 and the velocity is still 8.
      Snow Plowing them won't hurt velocity, but scope has increased because there is more to the story than you thought.

      > It seems that if you are not careful you can constantly add
      > development rewarding refactoring tasks (Oh, isn't that a wonderfully
      > elegant refactor I just did. I wonder where else...) at the expense
      > of completing stories (the real business value). Comments?

      End result, if your refactor supports the implementation of a User Story, there is real biz value, if it doesn't, you
      shouldn't do it.

      Ok all, feel free to criticize at will, that's just how I understand it so far. :)

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