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

Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

Expand Messages
  • Steven Gordon
    It should be the same, except that you do an internal release on specified dates to get a more realistic test of where the software really is (as opposed to
    Message 1 of 37 , Aug 31, 2007
    View Source
    • 0 Attachment
      It should be the same, except that you do an internal release on specified dates to get a more realistic test of where the software really is (as opposed to doing a big bang release when the functionality is finally deemed sufficient and getting surprised by all sorts of things that do not really work like install scripts or even integration on some of the platforms). 

      The selection of the stories you do each iteration would still functionality-driven, so development should be identical.

      On 8/30/07, Simon Godfrey <Simon.Godfrey@...> wrote:

      I'd be very cautious of driving by dates rather than by functionality. The project I'm currently working on tried this initially and it failed miserably. We're now driving by functionality and things are moving forward at a much quicker rate. I think though, that largely this comes down to getting buy-in from those who're delivering the code and whether they feel they're having unrealistic targets imposed on them.
       
      As for estimation, could a pert-chart not be a good way to tie up the many streams of work and their dependencies?
       
      Si


      ----- Original Message ----
      From: Steven Gordon < sgordonphd@...>
      To: agile-testing@yahoogroups.com
      Sent: Thursday, 30 August, 2007 3:16:24 PM
      Subject: Re: [agile-testing] Agile Estimating for Release Dates - Friends don't let ..

      Sometime it is more agile to drive the software development with release dates than drive the release dates with software development.

      In other words, pick a date and use a method like George suggests to help the customer figure out what could be done by that date.  This drives more realistic priority decisions and puts greater controls on overrunning release dates.  The organization will learn to have something releasable by any given date. 

      Even if for business reasons, the external release date must currently be driven by when a critical mass of functionality will be done, doing internal releases every 2-3 months will create the above discipline, establish a heartbeat, and give everybody valuable practice doing releases (in all likelihood, leading to a better release process).

      Steve

      On 8/30/07, George Dinwiddie < lists@...> wrote:

      Lori,

      The best thing I've found is to take the stack of estimated story cards,
      divide them into piles where the sum of estimates is no larger than the
      velocity, and then count the piles. That gives you the number of
      iterations.

      You can do the same estimations in software, but that won't make them any
      more accurate.

      This is still an estimate, of course, not a commitment. If the velocity
      changes, you'll need to revisit it. If new stories get added, you'll need
      to revisit it.

      One phenomena I've noticed is that when using software, people put more
      faith in the estimate and are less willing to adjust it to real-world
      conditions. Your mileage may vary.

      If you've got some long lead time activities depending on the answer, you
      may want to add some padding. That padding can be used to accomplish some
      "nice to have" stories if all the "must have" stories get completed. If
      velocity drops, or important stories are discovered, then perhaps that
      padding will provide space.

      - George

      On Wed, August 29, 2007 17:33, lori_oakley wrote:
      > My company is moving the rest of development towards Agile. I have a
      > very basic question that no one has given me a good answer to: How do
      > you estimate the release date using Agile? I know that "Friends don't
      > let other friends use Microsoft Project". I've plowed through hundreds
      > of pages on Agile estimating but I've never gotten a definitive answer
      > on a piece of software that can be used for estimating. Please don't
      > give up, read on.
      >
      > A release date is actually a very complicated question for our company.
      > We develop the software, while hardware engineering does prototypes
      > then manufacturing must create their processes, develop new lines, get
      > suppliers, etc. Sales has to be ramped up. ISO compliant procedures
      > must be documented. All of these depend on when we produce the software.
      >
      > Microsoft Project Plan is awful for trying to use for estimating. It
      > does a good job of keeping a list of everything that needs to get done
      > if you don't let the dates drive you nutty. It's not good enough due to
      > the large number of people who must depend on our end date to say,
      > we'll get done, when we get done. Is there anything out there that
      > you've used or seen in action? There's plenty of vaporware out there
      > and blogs full of puffed up people stating Microsoft bad, my way best.
      > I'd really appreciate some real life solutions where there are hundreds
      > of other people that depend on your dates.
      >
      > Thanks,
      >
      > Lori Oakley
      > Senior SQA
      > BI, Inc.
      >
      >
      >
      >
      > Yahoo! Groups Links
      >
      >
      >
      >

      --
      ----------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------




    • Phlip
      ... talking about how great their agile projects are. Besides the project velocity, % unit tests passing, reasonable work hours, integration rate, collective
      Message 37 of 37 , Sep 13, 2007
      View Source
      • 0 Attachment
        > I have never EVER seen a single person mention real metrics when
        talking about how great their agile projects are.

        Besides the project velocity, % unit tests passing, reasonable work hours,
        integration rate, collective code comprehension, and high code quality?
        Agile projects generally force those details into your face.

        "Agile" is essentially a system to detect when your project is agile.

        --
        Phlip
      Your message has been successfully submitted and would be delivered to recipients shortly.