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

Re: Time over Scope (was Re: [XP] Defining IT Project Success)

Expand Messages
  • John Roth
    That s the you can only change one thing fallacy. The point is that, in order to get a release out on time, you have to pad the schedule with relatively low
    Message 1 of 31 , Nov 2, 2007
    • 0 Attachment
      That's the "you can only change one thing" fallacy.

      The point is that, in order to get a release out on time,
      you have to pad the schedule with relatively low value
      "nice to have" features so you've got something to
      throw overboard when you have to lighten ship.

      It's _a_ strategy, and I doubt if one strategy is right
      for all situations.

      John Roth

      ----- Original Message -----
      From: "Steven Gordon" <sgordonphd@...>
      To: <extremeprogramming@yahoogroups.com>
      Sent: Friday, November 02, 2007 11:01 AM
      Subject: Time over Scope (was Re: [XP] Defining IT Project Success)


      > On 11/2/07, John Roth <JohnRoth1@...> wrote:
      > ...
      >>
      >> One interesting point is that XP defines time
      >> as more important than scope; maybe we should
      >> think about this?
      >
      > John,
      >
      > My understanding is that XP (and Scrum) fixes time and lets scope vary.
      >
      > I believe the motivation for doing this is not that time is more
      > important than scope, but for the exact opposite reason:
      > 1. scope is more important, so we have to allow, adapt to, and ever
      > leverage changes in scope.
      > 2. time is less important, so time can be fixed with much less impact.
      >
      > Steve
      >
      >>
      >> John Roth
      >>
      >
    • Ron Jeffries
      Hello, John. I m still not understanding your point but I can t think of another way to express my confusion. On Sunday, November 4, ... Ron Jeffries
      Message 31 of 31 , Nov 6, 2007
      • 0 Attachment
        Hello, John. I'm still not understanding your point but I can't
        think of another way to express my confusion. On Sunday, November 4,
        2007, at 5:06:41 PM, you wrote:

        > ----- Original Message -----
        > From: "Ron Jeffries" <ronjeffries@...>
        > To: <extremeprogramming@yahoogroups.com>
        > Sent: Sunday, November 04, 2007 2:23 PM
        > Subject: Re: Time over Scope (was Re: [XP] Defining IT Project Success)


        >> Hello, John. On Sunday, November 4, 2007, at 3:31:34 PM, you
        >> wrote:
        >>
        >>> "Nice to have" does not equal "won't have", nor does it mean that
        >>> *nobody* wants them.
        >>
        >> Maybe I am misunderstanding you. I took you to be saying you would
        >> schedule lower priority things //instead// of higher, so as to
        >> create slack. That seems wrong but maybe it's not what you meant.

        > There are several different deployment models; which one you
        > use depends on a lot of factors. If you're in a position to use
        > Continuous Deployment, then you don't usually need slack.
        > If you're in a situation where you have to have a release every
        > few months, then you need slack. What may be wisdom in one
        > situation may be folly in another.

        > I'm going from the viewpoint that you have to have some amount
        > of slack in a project with a hard ship date. I also think you don't
        > really want to have idle time scheduled; projects are likely to finish
        > before schedule just as well as after. If they're consistently biased
        > in one direction or another you've got too many pessimists or optimists.

        > "Must Have" is the same as "Can't (or won't) ship without it."

        > "Should Have" is "If this isn't there, we'll schedule a fixup release right
        > away."

        > "Nice to Have" means "If it misses this release, it goes into the next one."

        > The major point is that you don't schedule stuff in the first two categories
        > so they impinge on planned slack. Doing it this way means that you can
        > overload the schedule, in the same way that airlines overbook: they know
        > that they'll occasionally have to reschedule a passenger, but it's more
        > important to minimize empty seats, and they know some people won't
        > show up.



        Ron Jeffries
        www.XProgramming.com
        Do I contradict myself? Very well then I contradict myself.
        (I am large, I contain multitudes.) --Walt Whitman
      Your message has been successfully submitted and would be delivered to recipients shortly.