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

50223Re: [scrumdevelopment] Refactoring type work in Scrum

Expand Messages
  • Charles Bradley - Scrum Coach CSM PSM I
    Feb 2, 2011
    • 0 Attachment

      Thanks for the thorough answer.

      Let's change the scenario a bit. 

      Now the dev team has decided that it is time to move from one framework that it uses, to another one(I'm going to leave out the reason, but let's assume it's a pretty good technical decision, unless you feel your answer depends on the reason).  They estimate that this will increase the size of new backlog items that exercise code that uses the old framework for a while, as they transition over to the new framework.  Some ramp up time, if you will, on the new framework.  They are not doing a wholesale change.  They are only using the new framework for new backlog items that would normally involve code that exercises the old framework.  I don't know if one would call this incremental refactoring or not.  I'm not sure what to call it.

      In the context of Scrum, and based on your previous answer, does the team then just estimate the size of these backlog items taking into account some extra ramp up time for each?

      The main theme of many of these scenarios is technical work on the system under development that cannot be successfully sold to the PO as adding enough business value to bring the technical work to the top of the backlog.  Have you ever seen examples of this technical work that cannot be attached to new backlog items, but still should probably be completed for the health of the system under development, or possibly to help increase overall velocity/quality in the future, or possibly some other wise reason?

      (I'm not talking re-writes of major portions of a system here.)(Also, in case you're wondering, I'm not about to advocate the use of the term "Technical Story" or anything like that)
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/

      From: Ron Jeffries <ronjeffries@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Wed, February 2, 2011 3:20:05 PM
      Subject: Re: [scrumdevelopment] Refactoring type work in Scrum


      Hello, charles_bradley_scrum_coach. On Wednesday, February 2,
      2011, at 4:27:20 PM, you wrote:

      > 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. I believe you've made the
      > point also that the "attached work" should be closely related
      > (maybe in the same part of the system) to the new work in order to
      > justify attaching the work.

      Yes. One cleans up the campground one camps in, not some other one.

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

      I only work in a professional fashion. There is only one correct
      estimate, the one that improves the situation sufficiently to be at
      least a step forward in quality and testing.

      > I think you've also advocated trying to "sell" the business value
      > of the attached work to the PO. What do you advise when the PO
      > doesn't want to do the attached work, but the Dev Team really
      > feels the attached work is justified to help improve future
      > productivity?

      No. I believe it is impossible to sell because they think we will go
      faster if we work in a crappy fashion. As I choose not to work in a
      crappy fashion, and I know no way to sell quality to someone who
      would prefer to buy crap, I give a bit that says how long it's going
      to take me to do the job cleanly.

      Note that I am not going to gold plate anything. I'm going to get
      the job done in a workmanlike fashion and leave the campground
      better than it was.

      There is no need to refactor code I'm not working in ... now, or at
      any time.

      > 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
      > but the PO can't be sold.

      Makes me think the team needs to have more confidence in their
      ability to refactor incrementally. Their lack of confidence may be
      well-founded, through lack of experience doing incremental

      The desire to rewrite the SOB is not a desire to refactor. :)

      Ron Jeffries
      That's my opinion and I agree with it. -- Julio Santos

    • Show all 25 messages in this topic