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

Re: [XP] How do you integrate actuals into future iterations and release plans?

Expand Messages
  • Jonathan Rasmusson
    ... do each ... the ... We don t ... what to ... than we ... of time, ... Therefore, ... want it. ... This, ... on the ... Ok. 1,2,3 points for all the
    Message 1 of 6 , Jun 30, 2004
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, Ron Jeffries
      <jeffries@d...> wrote:
      > On Monday, June 28, 2004, at 4:35:41 PM, Jonathan Rasmusson wrote:
      >
      >
      >
      > > How do you incorporate actuals into your plans and how would you
      > > explain it to customers?
      >
      > "We have rated these stories 1, 3, and 5. It takes us two days to
      do each
      > point. Therefore, since you have given us a list that totals 100,
      the
      > project will take us about 200 person (or pair) days to complete.
      We don't
      > really believe this figure, nor should you, for these reasons:
      >
      > 1. You have the right to change your mind about what to do and
      what to
      > defer, and we expect that you'll do that.
      >
      > 2. We'll probably learn that some of these stories are easier
      than we
      > thought, and some are harder. That will change the total amount
      of time,
      > but there's no way to be sure how much or in which direction.
      Therefore,
      > we'll give you this same information regularly, and whenever you
      want it.
      >
      > 3. The size of the team may change or our abilities may change.
      This,
      > too, will effect how fast we go. Again, we'll keep you up to date
      on the
      > changes, and will gladly re-estimate whenever you wish."
      >

      Ok. 1,2,3 points for all the reasons described above. I like that.

      How do you convert this into a date?

      i.e. how do you communicate to the customer when you expect to be
      done? (based on how much/little you know today).

      I understand the XP concept of adaptive planning and feedback based
      on velocity. Wondering how you explain this to the customer, in
      light of them still asking for a date?

      Many thx,

      Jonathan
    • John Brewer
      We ve scoped this project at around 140 points, based on our previous experience. Our previous experience also tells us we can do about 14 points of work per
      Message 2 of 6 , Jun 30, 2004
      • 0 Attachment
        "We've scoped this project at around 140 points, based on our previous
        experience. Our previous experience also tells us we can do about 14
        points of work per week. So that puts it at about 10 weeks from when
        we start."

        --
        John Brewer

        Extreme Programming FAQ: http://www.jera.com/techinfo/xpfaq.html
      • Ron Jeffries
        ... There is no easy answer: there is only the truth. Right now, this appears to be a 200 point project. Based on our performance on other projects (or a
        Message 3 of 6 , Jul 1, 2004
        • 0 Attachment
          On Wednesday, June 30, 2004, at 7:09:40 PM, Jonathan Rasmusson wrote:

          > How do you convert this into a date?

          > i.e. how do you communicate to the customer when you expect to be
          > done? (based on how much/little you know today).

          > I understand the XP concept of adaptive planning and feedback based
          > on velocity. Wondering how you explain this to the customer, in
          > light of them still asking for a date?

          There is no easy answer: there is only the truth.

          "Right now, this appears to be a 200 point project. Based on our
          performance on other projects (or a random guess), with N programmers on
          it, and your intimate involvement in the project, a project of this size
          will take between 4 and 6 months.

          "However. We will be shipping software to you every two weeks, and we'll be
          ticking off these feature stories to //your// satisfaction. The good news
          is that if you're not satisfied, you can stop. The better news is that if
          you become satisfied before all the features are done, you can stop. The
          bad news is that you need to work with us to make it clear just what your
          satisfaction means. The best news is that whenever there are enough
          features working to make the program useful, you can ask us to prepare it
          for deployment, and we'll do that.

          "As we go forward, we'll all see how fast we're progressing, and our
          estimate of the time needed will improve. In every case, you'll see what is
          going on, you'll see concrete evidence of useful software running the tests
          that you specify, and you'll know everything as soon as we know it."

          Ron Jeffries
          www.XProgramming.com
          If names and real items do not correspond with each other, there will be fighting.
          -- Jing Fa
        Your message has been successfully submitted and would be delivered to recipients shortly.