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

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

Expand Messages
  • Chris Wheeler
    ... I d say that more important than either is delivery. Hence the tension between time and scope, perhaps, since they both work towards the final
    Message 1 of 31 , Nov 2, 2007
    • 0 Attachment
      On 11/2/07, Steven Gordon <sgordonphd@...> wrote:
      >
      > 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.



      I'd say that more important than either is delivery. Hence the 'tension'
      between time and scope, perhaps, since they both work towards the final
      deliverable on a delivery date.

      Chris.


      [Non-text portions of this message have been removed]
    • 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.