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

RE: [scrumdevelopment] Scheduling Defect Fixes

Expand Messages
  • Roy Morien
    Back in 1976, a guy called Peter Chen wrote a paper on Entity Modelling. He was an academic. His paper has been claimed to be the most cited academic paper in
    Message 1 of 347 , Feb 1, 2011
    • 0 Attachment
      Back in 1976, a guy called Peter Chen wrote a paper on Entity Modelling. He was an academic. His paper has been claimed to be the most cited academic paper in IT/CS publication, and is the seminal work on ER Modelling.
       
      Over the years, many people (usually American academics on the tenure track) have written books that include discussion on ER Modelling. Many of them have added a bit here and there, changed a bit here and there, presumably in attempts to make it better ... building on the shoulders of giants, I guess.
       
      Nobody, to my knowledge, has gone into print condemning these authors for changing the ER Modelling theory and practice that Chen initially developed. Adding to, modifying, interpreting existing theory and practice is something that most publishers of books, papers, conference proceedings etc. have found to be useful and agreeable practice.
       
      I do have to say that many of the modifications suggested to Chen's initial ER modelling are stupid, add complexity but not usefulness. This does not detract from the notion that modifications to exisitng thoery and practice are allowable activities.
       
      I would strongly suggest that this is something that should be approved of in the agile community too. Refuting some suggestion on the grounds that it is not written in the canons of the method is not a useful practice. Daring to be a little different ought not be seen as heretical.
       
      Regards,
      Roy Morien
    • Vikrama Dhiman
      ... Although, this is not Twitter. I really want to do a+1. Echoes my thoughts completely. Won t have been able to put it better myself. Thanks Vikrama Dhiman
      Message 347 of 347 , Feb 2, 2011
      • 0 Attachment
        >>It (and the length of this thread) is a great illustration of why I recommend that teams not get too wrapped up in estimation. They start looking for numerical precision, and that starts consuming the energy that could be put toward accomplish goals.

        Although, this is not Twitter. I really want to do a +1.

        Echoes my thoughts completely. Won't have been able to put it better myself.
         
        Thanks

        Vikrama Dhiman
        ================================================================
        Personal Blog : http://www.vikramadhiman.com/
        My Blog about all things Agile : http://agilediary.wordpress.com/



        From: George Dinwiddie <lists@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Wed, February 2, 2011 11:09:28 PM
        Subject: Re: [scrumdevelopment] Re: Scheduling Defect Fixes

         

        On 2/2/11 5:48 AM, Ron Jeffries wrote:
        > Hello, kbs_kulbhushan. On Wednesday, February 2, 2011, at
        > 12:23:59 AM, you wrote:
        >
        >> Does this make sense?
        >
        > Not really, but it was a delightful demonstration of how many
        > numbers can dance on the head of a pin.

        It (and the length of this thread) is a great illustration of why I
        recommend that teams not get too wrapped up in estimation. They start
        looking for numerical precision, and that starts consuming the energy
        that could be put toward accomplish goals.

        I suggest that the primary reason for estimating stories & tracking
        velocity is to help the team decide how much work they can do in the
        next iteration. I've found that developing clear acceptance examples
        (a.k.a. tests) helps them do that much better than more time spent
        honing estimates.

        I suggest that the secondary reason for estimating stories & tracking
        velocity is to help the PO predict how much functionality can be done by
        a certain date, or how long it will take to build a certain amount of
        functionality. When doing so, one has to remember that these are just
        estimates, no matter how much work you put into them. You need to allow
        some leeway for the things you don't know and can't predict. You need
        to track actual progress, and give that more weight than any predicted
        progress. And you need to measure actual progress in ways that don't
        mislead you. The more calculations you put in, the more likely you're
        going to fool yourself.

        - George

        P.S. Remember that the abbreviation for "estimation" is "guess."

        --
        ----------------------------------------------------------
        * 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.