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

Large Refactorings and estimates (was: Re: [XP] Units of time for estimates)

Expand Messages
  • wecaputo@thoughtworks.com
    ... This definitely happens. What I have observed is that overall velocity seems to improve as the factoring of the system improves. Individual stories types
    Message 1 of 1 , Jul 3, 2001
    • 0 Attachment
      Stefan:
      >Considering the source of the quote, however, I think
      >that it was because of sound refactoring that they got
      >done that fast.

      This definitely happens. What I have observed is that overall velocity
      seems to improve as the factoring of the system improves. Individual
      stories types improve as large refactorings get accomplished.

      For example:

      On my last project (I am now on vacation woohoo!). A story that required
      the system to support a new message type was typically estimated with an
      additional 1 to 2 (ideal weeks) points above the business logic. Our
      iterations were one week, and our overall velocity was 5. Thus we could get
      1 or 2 of these kinds of stories done per week. This was considered by all
      to be a considerable amount of time to do a message based story, but the
      reason was widely considered due to a legacy architecture that made OAOO
      very difficult to achieve. Thus adding a new message meant starting over.
      Over the course of several months, we had targeted this design decision,
      and at the time of the above estimates, had achieved some decent reuse,
      however much duplication still existed.

      As we progressed, there were several large refactorings that we kept in
      mind, and guided the design toward over several weeks.

      Initially, implementing a new message had approximately seven 1 - 2 day
      engineering tasks associated with it. As we went, some of these task became
      so trivial, or went away all together that the number of meaningful tasks
      was reduced to 3. Refactorings that were occurring when we left (the
      project shipped release 1, and TW has rolled off, while the client's
      development team we worked with is now moving toward release 2), would
      reduce the number of tasks to 2 (one in the data mapping layer, and the
      other in the messaging model).

      Thus estimates for these types of stories (ones that required new messages)
      *should* drop to fractional weeks (we used 1/5 increments, and then pushed
      them together to make 1's).

      I say should, because other factors may impact velocity in the particular
      case I am describing, but all things being equal, implementing messages has
      gotten easier, more boiler-plate, less duplication, and thus faster causing
      the message based story estimates to drop.

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