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

Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum

Expand Messages
  • Sidney Yu
    Hello, all: I am in the process of learning about Agile and Scrum and hope to use it at work.  I have also read Mike Cohn s User Story Applied, Agile
    Message 1 of 24 , May 30 5:50 PM
    • 0 Attachment
      Hello, all:


      I am in the process of learning about Agile and Scrum and hope to use it at work.  I have also read Mike Cohn's User Story Applied, Agile Estimating and Planning(95%) and Succeeding with Agile (70%).  However, I couldn't get the idea of how to estimate an entire project in order to answer the question "when are you going to be done with the project?"  Maybe I have problem with my comprehension skills, I suspect.... . I hope you can help me here.

      Mike Cohn describes the product backlog as an iceberg, with detailed small stories at the top and big scary monster stories at the bottom.  If a project contains 4 phases, the very first phase is the really must-have basic stuff and the forth phase is the really advanced features (e.g. an expert system to intelligently assign call tickets to agents), how can I somewhat estimate the big user stories in the 3rd or 4th phases?  How can I know that a 40 story point story is not in fact a 100 point story?  It that happens, the estimate for the big stories will be really off by a lot.

      Now if divide the total story points for all 4 phases by the velocity, the # of sprints required will also be off by quite a bit.  So I would give a very inaccurate answer to the "when will it be done' question.  Is this a valid concern?

      I tried to answer this question on my own.... such as: maybe I will tell the product owner that I can give a fairly estimate on the first 2 phases but not on all 4 phases, OR maybe I can say the estimate of being done in 8 months is really rough and I will update you throughout the project, especially when we are doing the features for the 3rd and 4th phases.  But I can't convince myself that's what I should say or do.  Or perhaps a Agile-aware product owner would not even ask me to tell him the estimate on all 4 phases.

      I think I am kind of asking the same question as  below 'how can one give an estimate for the entire product backlog for the entire project at the start.". Is it that in agile, one answers that question in an iterative way?

      thanks.

      Sidney

      --- On Sun, 5/30/10, Ron Jeffries <ronjeffries@...> wrote:

      From: Ron Jeffries <ronjeffries@...>
      Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum
      To: scrumdevelopment@yahoogroups.com
      Received: Sunday, May 30, 2010, 6:56 AM

      Hello, b_aashish.  On Sunday, May 30, 2010, at 3:34:10 AM, you
      wrote:

      > Reporting status in Waterfall projects is easy - you have the
      > milestones (e.g. Req Doc completed/sign-off, Design docs
      > completed, coding finished etc.. You have an overall plan and
      > schedule against which you report that the projecy is 25% comeplete etc.

      Yes, except that the information is absolutely false. Completing a
      requirements document in no way indicates anything about whether the
      project will be done. It would be quite easy to write a requirements
      document that was completely incapable of being implemented. Most of
      them are at least PARTLY incapable of being implemented at all. Most
      of them are incapable of being implemented fully.

      So reporting Waterfall projects is easy ... unless you care about
      the truth.

      > How does one that in Scrum projects? Specially if it is a
      > greenfield project. Does one do a high-level estimate/schedule of
      > the entire Product backlog at the start? What kind of estimation
      > would help here? How does one tell the customer how many sprints
      > would be required to finish the complete the complete project? Any
      > recommendations for status reporting? How can one apply EV here?

      You are asking a different question than you answered above, even
      not counting that the answer above isn't true.

      With a Scrum project you have backlog items to do. You have a known
      number of them (though you are allowed to change them, add them, and
      delete them, because you're interested in the best result, not the
      predicted result).

      So you draw a Sprint burndown (or better yet burn UP) chart. From
      the very first weeks of the project, this chart shows how fast you
      are growing features. The slope of this curve intersects the line
      showing how many features you want, at the delivery date.

      > Any insight please?

      It seems to me that some additional training and reading in Agile
      and Scrum would be helpful, as the above is pretty basic stuff. I'll
      point you here to some things I've written, and I hope that others
      will do so as well.

      Kate Oneal: The Empire Starts Out

        After Dan Devlin, President of Oak River Software, dropped in on
        her at the coffee shop, Kate agreed to consider helping with the
        proposed new Empire project. Empire was life or death for Oak
        River. Without Empire, they’d go under, and Dan couldn’t afford to
        fund it.

        http://xprogramming.com/kate-oneal/aokoempire/
        (intro at http://xprogramming.com/kate-oneal/aokoprologue/)

      Beyond Agile — The Agile Barrier

        Agile projects very often seem to stall out after gaining perhaps
        twenty-five percent of the possible benefit. Why is this? What can
        be done?

        NOTE: This article is part of a series about going beyond the
        basics of Agile, but it points directly to the topic here, status
        and scheduling.

        http://xprogramming.com/xpmag/beyond-agile-the-agile-barrier/


      Agile and Scrum are not like what you're used to. Even some of the
      questions aren't the same, much less the answers. Dig in, it's worth
      it!

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      The fact that we know more today, and are more capable today,
      is good news about today, not bad news about yesterday.



      ------------------------------------

      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

      <*> To visit your group on the web, go to:
          http://groups.yahoo.com/group/scrumdevelopment/

      <*> Your email settings:
          Individual Email | Traditional

      <*> To change settings online go to:
          http://groups.yahoo.com/group/scrumdevelopment/join
          (Yahoo! ID required)

      <*> To change settings via email:
          scrumdevelopment-digest@yahoogroups.com
          scrumdevelopment-fullfeatured@yahoogroups.com

      <*> To unsubscribe from this group, send an email to:
          scrumdevelopment-unsubscribe@yahoogroups.com

      <*> Your use of Yahoo! Groups is subject to:
          http://docs.yahoo.com/info/terms/


    • George Dinwiddie
      Hi, Sidney, Do you know the abbreviation for estimate? It s guess. Before you start, you really have no data to work with. If you guestimate the features
      Message 2 of 24 , May 30 5:59 PM
      • 0 Attachment
        Hi, Sidney,

        Do you know the abbreviation for "estimate?" It's "guess."

        Before you start, you really have no data to work with. If you
        guestimate the features using T-shirt sizes, then when you've done the
        first feature to your satisfaction, you'll have one data point for that
        size. Extrapolate from there until you have more data.

        Did you see my posting on burn-up charts?
        http://blog.gdinwiddie.com/2010/04/22/projecting-into-the-future/

        - George

        Sidney Yu wrote:
        >
        >
        > Hello, all:
        >
        >
        > I am in the process of learning about Agile and Scrum and hope to use it
        > at work. I have also read Mike Cohn's User Story Applied, Agile
        > Estimating and Planning(95%) and Succeeding with Agile (70%). However,
        > I couldn't get the idea of how to estimate an entire project in order to
        > answer the question "when are you going to be done with the project?"
        > Maybe I have problem with my comprehension skills, I suspect.... . I
        > hope you can help me here.
        >
        > Mike Cohn describes the product backlog as an iceberg, with detailed
        > small stories at the top and big scary monster stories at the bottom.
        > If a project contains 4 phases, the very first phase is the really
        > must-have basic stuff and the forth phase is the really advanced
        > features (e.g. an expert system to intelligently assign call tickets to
        > agents), how can I somewhat estimate the big user stories in the 3rd or
        > 4th phases? How can I know that a 40 story point story is not in fact a
        > 100 point story? It that happens, the estimate for the big stories will
        > be really off by a lot.
        >
        > Now if divide the total story points for all 4 phases by the velocity,
        > the # of sprints required will also be off by quite a bit. So I would
        > give a very inaccurate answer to the "when will it be done' question.
        > Is this a valid concern?
        >
        > I tried to answer this question on my own.... such as: maybe I will tell
        > the product owner that I can give a fairly estimate on the first 2
        > phases but not on all 4 phases, OR maybe I can say the estimate of being
        > done in 8 months is really rough and I will update you throughout the
        > project, especially when we are doing the features for the 3rd and 4th
        > phases. But I can't convince myself that's what I should say or do. Or
        > perhaps a Agile-aware product owner would not even ask me to tell him
        > the estimate on all 4 phases.
        >
        > I think I am kind of asking the same question as below 'how can one
        > give an estimate for the entire product backlog for the entire project
        > at the start.". Is it that in agile, one answers that question in an
        > iterative way?
        >
        > thanks.
        >
        > Sidney
        >
        > --- On *Sun, 5/30/10, Ron Jeffries /<ronjeffries@...>/* wrote:
        >
        >
        > From: Ron Jeffries <ronjeffries@...>
        > Subject: Re: [scrumdevelopment] Status Reporting, scheduling &
        > estimation in Scrum
        > To: scrumdevelopment@yahoogroups.com
        > Received: Sunday, May 30, 2010, 6:56 AM
        >
        > Hello, b_aashish. On Sunday, May 30, 2010, at 3:34:10 AM, you
        > wrote:
        >
        > > Reporting status in Waterfall projects is easy - you have the
        > > milestones (e.g. Req Doc completed/sign-off, Design docs
        > > completed, coding finished etc.. You have an overall plan and
        > > schedule against which you report that the projecy is 25%
        > comeplete etc.
        >
        > Yes, except that the information is absolutely false. Completing a
        > requirements document in no way indicates anything about whether the
        > project will be done. It would be quite easy to write a requirements
        > document that was completely incapable of being implemented. Most of
        > them are at least PARTLY incapable of being implemented at all. Most
        > of them are incapable of being implemented fully.
        >
        > So reporting Waterfall projects is easy ... unless you care about
        > the truth.
        >
        > > How does one that in Scrum projects? Specially if it is a
        > > greenfield project. Does one do a high-level estimate/schedule of
        > > the entire Product backlog at the start? What kind of estimation
        > > would help here? How does one tell the customer how many sprints
        > > would be required to finish the complete the complete project? Any
        > > recommendations for status reporting? How can one apply EV here?
        >
        > You are asking a different question than you answered above, even
        > not counting that the answer above isn't true.
        >
        > With a Scrum project you have backlog items to do. You have a known
        > number of them (though you are allowed to change them, add them, and
        > delete them, because you're interested in the best result, not the
        > predicted result).
        >
        > So you draw a Sprint burndown (or better yet burn UP) chart. From
        > the very first weeks of the project, this chart shows how fast you
        > are growing features. The slope of this curve intersects the line
        > showing how many features you want, at the delivery date.
        >
        > > Any insight please?
        >
        > It seems to me that some additional training and reading in Agile
        > and Scrum would be helpful, as the above is pretty basic stuff. I'll
        > point you here to some things I've written, and I hope that others
        > will do so as well.
        >
        > Kate Oneal: The Empire Starts Out
        >
        > After Dan Devlin, President of Oak River Software, dropped in on
        > her at the coffee shop, Kate agreed to consider helping with the
        > proposed new Empire project. Empire was life or death for Oak
        > River. Without Empire, they’d go under, and Dan couldn’t afford to
        > fund it.
        >
        > http://xprogramming.com/kate-oneal/aokoempire/
        > (intro at http://xprogramming.com/kate-oneal/aokoprologue/)
        >
        > Beyond Agile — The Agile Barrier
        >
        > Agile projects very often seem to stall out after gaining perhaps
        > twenty-five percent of the possible benefit. Why is this? What can
        > be done?
        >
        > NOTE: This article is part of a series about going beyond the
        > basics of Agile, but it points directly to the topic here, status
        > and scheduling.
        >
        > http://xprogramming.com/xpmag/beyond-agile-the-agile-barrier/
        >
        >
        > Agile and Scrum are not like what you're used to. Even some of the
        > questions aren't the same, much less the answers. Dig in, it's worth
        > it!
        >
        > Ron Jeffries
        > www.XProgramming.com
        > www.xprogramming.com/blog
        > The fact that we know more today, and are more capable today,
        > is good news about today, not bad news about yesterday.
        >
        >
        >
        > ------------------------------------
        >
        > To Post a message, send it to: scrumdevelopment@...
        > </mc/compose?to=scrumdevelopment@...>
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        > </mc/compose?to=scrumdevelopment-unsubscribe@...>!
        > Groups Links
        >
        >
        > scrumdevelopment-fullfeatured@yahoogroups.com
        > </mc/compose?to=scrumdevelopment-fullfeatured@yahoogroups.com>
        >
        >
        >
        >
        >
        >

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Roy Morien
        I m a little perplexed that you, having read Mike Cohn s book, still don t have the idea of how to estimate an entire project. Also, the fact that you are
        Message 3 of 24 , May 30 6:41 PM
        • 0 Attachment
          I'm a little perplexed that you, having read Mike Cohn's book, still don't have the idea of how to estimate an entire project. Also, the fact that you are still talking about 'am entire project' reeks of traditional, full up-front estimating, which has been proven to not work on almost every project, software and engineering, for the last 50 years (and a few years before that, if you ignore software).
           
          On the face of it, knowing when the project will be finished is just not an option, not as a fixed, unmoveable and correct estimate, that is. No matter how you estimate it, that WILL necessarilly change due to circumstances in the future.
           
          I suggest that you become comfortable with the idea of adaptive planning and estimating first. Get rid of the thinking about estimating 'the whole project' up front, or at all.
           
          Then get comfortable with the ideas of User Stories, Project Backlog (aka Product Backlog) and Story Points.
           
          Finally, come to terms with the concept of team VELOCITY.
           
          Then apply all this to estimating the possible project completion date as of now, all things being equal (which they aren't), and the necessary activity of estimating again tomorrow, based on whatever nw knowledge you might have about requirements.
           
          As a workeable alternative, apply the above to a project with a fixed deadline. This approach allows you to estimate how much you will possibly be able to achieve by that deadline. This approach raises the idea of prioritising the Project Backlog items to a prominent practice.
           
          And be happy with the idea that nothing is fixed and unchangeable. Something's gotta give ... deadline, completion date, deliverable product ... whatever.
           
          And finally, when someone asks you to tell them exactly when the project will be finished, give them an estimate that you make clear to them is based on the best knowledge currenty available, but will definitely change as more is learned and understood about the requirements and other aspects of the project. AND don't make promises you can't keep!!
           
          Regards,
          Roy Morien 
           

          To: scrumdevelopment@yahoogroups.com
          From: yu_sidney@...
          Date: Sun, 30 May 2010 17:50:50 -0700
          Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum

           
          Hello, all:


          I am in the process of learning about Agile and Scrum and hope to use it at work.  I have also read Mike Cohn's User Story Applied, Agile Estimating and Planning(95% ) and Succeeding with Agile (70%).  However, I couldn't get the idea of how to estimate an entire project in order to answer the question "when are you going to be done with the project?"  Maybe I have problem with my comprehension skills, I suspect.... . I hope you can help me here.

          Mike Cohn describes the product backlog as an iceberg, with detailed small stories at the top and big scary monster stories at the bottom.  If a project contains 4 phases, the very first phase is the really must-have basic stuff and the forth phase is the really advanced features (e.g. an expert system to intelligently assign call tickets to agents), how can I somewhat estimate the big user stories in the 3rd or 4th phases?  How can I know that a 40 story point story is not in fact a 100 point story?  It that happens, the estimate for the big stories will be really off by a lot.

          Now if divide the total story points for all 4 phases by the velocity, the # of sprints required will also be off by quite a bit.  So I would give a very inaccurate answer to the "when will it be done' question.  Is this a valid concern?

          I tried to answer this question on my own.... such as: maybe I will tell the product owner that I can give a fairly estimate on the first 2 phases but not on all 4 phases, OR maybe I can say the estimate of being done in 8 months is really rough and I will update you throughout the project, especially when we are doing the features for the 3rd and 4th phases.  But I can't convince myself that's what I should say or do.  Or perhaps a Agile-aware product owner would not even ask me to tell him the estimate on all 4 phases.

          I think I am kind of asking the same question as  below 'how can one give an estimate for the entire product backlog for the entire project at the start.". Is it that in agile, one answers that question in an iterative way?

          thanks.

          Sidney

          --- On Sun, 5/30/10, Ron Jeffries <ronjeffries@ acm.org> wrote:

          From: Ron Jeffries <ronjeffries@ acm.org>
          Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum
          To: scrumdevelopment@ yahoogroups. com
          Received: Sunday, May 30, 2010, 6:56 AM

          Hello, b_aashish.  On Sunday, May 30, 2010, at 3:34:10 AM, you
          wrote:

          > Reporting status in Waterfall projects is easy - you have the
          > milestones (e.g. Req Doc completed/sign- off, Design docs
          > completed, coding finished etc.. You have an overall plan and
          > schedule against which you report that the projecy is 25% comeplete etc.

          Yes, except that the information is absolutely false. Completing a
          requirements document in no way indicates anything about whether the
          project will be done. It would be quite easy to write a requirements
          document that was completely incapable of being implemented. Most of
          them are at least PARTLY incapable of being implemented at all. Most
          of them are incapable of being implemented fully.

          So reporting Waterfall projects is easy ... unless you care about
          the truth.

          > How does one that in Scrum projects? Specially if it is a
          > greenfield project. Does one do a high-level estimate/schedule of
          > the entire Product backlog at the start? What kind of estimation
          > would help here? How does one tell the customer how many sprints
          > would be required to finish the complete the complete project? Any
          > recommendations for status reporting? How can one apply EV here?

          You are asking a different question than you answered above, even
          not counting that the answer above isn't true.

          With a Scrum project you have backlog items to do. You have a known
          number of them (though you are allowed to change them, add them, and
          delete them, because you're interested in the best result, not the
          predicted result).

          So you draw a Sprint burndown (or better yet burn UP) chart. From
          the very first weeks of the project, this chart shows how fast you
          are growing features. The slope of this curve intersects the line
          showing how many features you want, at the delivery date.

          > Any insight please?

          It seems to me that some additional training and reading in Agile
          and Scrum would be helpful, as the above is pretty basic stuff. I'll
          point you here to some things I've written, and I hope that others
          will do so as well.

          Kate Oneal: The Empire Starts Out

            After Dan Devlin, President of Oak River Software, dropped in on
            her at the coffee shop, Kate agreed to consider helping with the
            proposed new Empire project. Empire was life or death for Oak
            River. Without Empire, they’d go under, and Dan couldn’t afford to
            fund it.

            http://xprogramming .com/kate- oneal/aokoempire /
            (intro at http://xprogramming .com/kate- oneal/aokoprolog ue/)

          Beyond Agile — The Agile Barrier

            Agile projects very often seem to stall out after gaining perhaps
            twenty-five percent of the possible benefit. Why is this? What can
            be done?

            NOTE: This article is part of a series about going beyond the
            basics of Agile, but it points directly to the topic here, status
            and scheduling.

            http://xprogramming .com/xpmag/ beyond-agile- the-agile- barrier/


          Agile and Scrum are not like what you're used to. Even some of the
          questions aren't the same, much less the answers. Dig in, it's worth
          it!

          Ron Jeffries
          www.XProgramming. com
          www.xprogramming. com/blog
          The fact that we know more today, and are more capable today,
          is good news about today, not bad news about yesterday.



          ------------ --------- --------- ------

          To Post a message, send it to:   scrumdevelopment@ eGroups.com
          To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo! Groups Links

          <*> To visit your group on the web, go to:
              http://groups. yahoo.com/ group/scrumdevel opment/

          <*> Your email settings:
              Individual Email | Traditional

          <*> To change settings online go to:
              http://groups. yahoo.com/ group/scrumdevel opment/join
              (Yahoo! ID required)

          <*> To change settings via email:
              scrumdevelopment- digest@yahoogrou ps.com
              scrumdevelopment- fullfeatured@ yahoogroups. com

          <*> To unsubscribe from this group, send an email to:
              scrumdevelopment- unsubscribe@ yahoogroups. com

          <*> Your use of Yahoo! Groups is subject to:
              http://docs. yahoo.com/ info/terms/





          Find it on Domain.com.au Need a new place to live?
        • anwars78@yahoo.com
          Hi, Is there a way to calculate estimate cost at completion? Regards Anwar Sadat. Agile Project Management. Indonesia. +6281321666510 ... From: Roy Morien
          Message 4 of 24 , May 30 6:48 PM
          • 0 Attachment
            Hi,

            Is there a way to calculate estimate cost at completion?

            Regards

            Anwar Sadat. Agile Project Management. Indonesia. +6281321666510


            From: Roy Morien <roymorien@...>
            Sender: scrumdevelopment@yahoogroups.com
            Date: Mon, 31 May 2010 01:41:52 +0000
            To: <scrumdevelopment@yahoogroups.com>
            ReplyTo: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum

             

            I'm a little perplexed that you, having read Mike Cohn's book, still don't have the idea of how to estimate an entire project. Also, the fact that you are still talking about 'am entire project' reeks of traditional, full up-front estimating, which has been proven to not work on almost every project, software and engineering, for the last 50 years (and a few years before that, if you ignore software).
             
            On the face of it, knowing when the project will be finished is just not an option, not as a fixed, unmoveable and correct estimate, that is. No matter how you estimate it, that WILL necessarilly change due to circumstances in the future.
             
            I suggest that you become comfortable with the idea of adaptive planning and estimating first. Get rid of the thinking about estimating 'the whole project' up front, or at all.
             
            Then get comfortable with the ideas of User Stories, Project Backlog (aka Product Backlog) and Story Points.
             
            Finally, come to terms with the concept of team VELOCITY.
             
            Then apply all this to estimating the possible project completion date as of now, all things being equal (which they aren't), and the necessary activity of estimating again tomorrow, based on whatever nw knowledge you might have about requirements.
             
            As a workeable alternative, apply the above to a project with a fixed deadline. This approach allows you to estimate how much you will possibly be able to achieve by that deadline. This approach raises the idea of prioritising the Project Backlog items to a prominent practice.
             
            And be happy with the idea that nothing is fixed and unchangeable. Something's gotta give ... deadline, completion date, deliverable product ... whatever.
             
            And finally, when someone asks you to tell them exactly when the project will be finished, give them an estimate that you make clear to them is based on the best knowledge currenty available, but will definitely change as more is learned and understood about the requirements and other aspects of the project. AND don't make promises you can't keep!!
             
            Regards,
            Roy Morien 
             


            To: scrumdevelopment@ yahoogroups. com
            From: yu_sidney@yahoo. ca
            Date: Sun, 30 May 2010 17:50:50 -0700
            Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum

             
            Hello, all:


            I am in the process of learning about Agile and Scrum and hope to use it at work.  I have also read Mike Cohn's User Story Applied, Agile Estimating and Planning(95% ) and Succeeding with Agile (70%).  However, I couldn't get the idea of how to estimate an entire project in order to answer the question "when are you going to be done with the project?"  Maybe I have problem with my comprehension skills, I suspect.... . I hope you can help me here.

            Mike Cohn describes the product backlog as an iceberg, with detailed small stories at the top and big scary monster stories at the bottom.  If a project contains 4 phases, the very first phase is the really must-have basic stuff and the forth phase is the really advanced features (e.g. an expert system to intelligently assign call tickets to agents), how can I somewhat estimate the big user stories in the 3rd or 4th phases?  How can I know that a 40 story point story is not in fact a 100 point story?  It that happens, the estimate for the big stories will be really off by a lot.

            Now if divide the total story points for all 4 phases by the velocity, the # of sprints required will also be off by quite a bit.  So I would give a very inaccurate answer to the "when will it be done' question.  Is this a valid concern?

            I tried to answer this question on my own.... such as: maybe I will tell the product owner that I can give a fairly estimate on the first 2 phases but not on all 4 phases, OR maybe I can say the estimate of being done in 8 months is really rough and I will update you throughout the project, especially when we are doing the features for the 3rd and 4th phases.  But I can't convince myself that's what I should say or do.  Or perhaps a Agile-aware product owner would not even ask me to tell him the estimate on all 4 phases.

            I think I am kind of asking the same question as  below 'how can one give an estimate for the entire product backlog for the entire project at the start.". Is it that in agile, one answers that question in an iterative way?

            thanks.

            Sidney

            --- On Sun, 5/30/10, Ron Jeffries <ronjeffries@ acm.org> wrote:

            From: Ron Jeffries <ronjeffries@ acm.org>
            Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum
            To: scrumdevelopment@ yahoogroups. com
            Received: Sunday, May 30, 2010, 6:56 AM

            Hello, b_aashish.  On Sunday, May 30, 2010, at 3:34:10 AM, you
            wrote:

            > Reporting status in Waterfall projects is easy - you have the
            > milestones (e.g. Req Doc completed/sign- off, Design docs
            > completed, coding finished etc.. You have an overall plan and
            > schedule against which you report that the projecy is 25% comeplete etc.

            Yes, except that the information is absolutely false. Completing a
            requirements document in no way indicates anything about whether the
            project will be done. It would be quite easy to write a requirements
            document that was completely incapable of being implemented. Most of
            them are at least PARTLY incapable of being implemented at all. Most
            of them are incapable of being implemented fully.

            So reporting Waterfall projects is easy ... unless you care about
            the truth.

            > How does one that in Scrum projects? Specially if it is a
            > greenfield project. Does one do a high-level estimate/schedule of
            > the entire Product backlog at the start? What kind of estimation
            > would help here? How does one tell the customer how many sprints
            > would be required to finish the complete the complete project? Any
            > recommendations for status reporting? How can one apply EV here?

            You are asking a different question than you answered above, even
            not counting that the answer above isn't true.

            With a Scrum project you have backlog items to do. You have a known
            number of them (though you are allowed to change them, add them, and
            delete them, because you're interested in the best result, not the
            predicted result).

            So you draw a Sprint burndown (or better yet burn UP) chart. From
            the very first weeks of the project, this chart shows how fast you
            are growing features. The slope of this curve intersects the line
            showing how many features you want, at the delivery date.

            > Any insight please?

            It seems to me that some additional training and reading in Agile
            and Scrum would be helpful, as the above is pretty basic stuff. I'll
            point you here to some things I've written, and I hope that others
            will do so as well.

            Kate Oneal: The Empire Starts Out

              After Dan Devlin, President of Oak River Software, dropped in on
              her at the coffee shop, Kate agreed to consider helping with the
              proposed new Empire project. Empire was life or death for Oak
              River. Without Empire, they’d go under, and Dan couldn’t afford to
              fund it.

              http://xprogramming .com/kate- oneal/aokoempire /
              (intro at http://xprogramming .com/kate- oneal/aokoprolog ue/)

            Beyond Agile — The Agile Barrier

              Agile projects very often seem to stall out after gaining perhaps
              twenty-five percent of the possible benefit. Why is this? What can
              be done?

              NOTE: This article is part of a series about going beyond the
              basics of Agile, but it points directly to the topic here, status
              and scheduling.

              http://xprogramming .com/xpmag/ beyond-agile- the-agile- barrier/


            Agile and Scrum are not like what you're used to. Even some of the
            questions aren't the same, much less the answers. Dig in, it's worth
            it!

            Ron Jeffries
            www.XProgramming. com
            www.xprogramming. com/blog
            The fact that we know more today, and are more capable today,
            is good news about today, not bad news about yesterday.



            ------------ --------- --------- ------

            To Post a message, send it to:   scrumdevelopment@ eGroups.com
            To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo! Groups Links

            <*> To visit your group on the web, go to:
                http://groups. yahoo.com/ group/scrumdevel opment/

            <*> Your email settings:
                Individual Email | Traditional

            <*> To change settings online go to:
                http://groups. yahoo.com/ group/scrumdevel opment/join
                (Yahoo! ID required)

            <*> To change settings via email:
                scrumdevelopment- digest@yahoogrou ps.com
                scrumdevelopment- fullfeatured@ yahoogroups. com

            <*> To unsubscribe from this group, send an email to:
                scrumdevelopment- unsubscribe@ yahoogroups. com

            <*> Your use of Yahoo! Groups is subject to:
                http://docs. yahoo.com/ info/terms/





            Find it on Domain.com.au Need a new place to live?
          • Ron Jeffries
            ... Actually, I don t agree with this. (I do agree with much of what went before.) It is perfectly possible to pick a date to be done and a dollar budget to be
            Message 5 of 24 , May 30 6:54 PM
            • 0 Attachment
              Hello, Roy. On Sunday, May 30, 2010, at 9:41:52 PM, you wrote:

              > And finally, when someone asks you to tell them exactly when the
              > project will be finished, give them an estimate that you make
              > clear to them is based on the best knowledge currenty available,
              > but will definitely change as more is learned and understood about
              > the requirements and other aspects of the project. AND don't make promises you can't keep!!

              Actually, I don't agree with this. (I do agree with much of what
              went before.)

              It is perfectly possible to pick a date to be done and a dollar
              budget to be met and to do it using Scrum. You do it by managing
              scope.

              This is precisely the job of the Product Owner: Deliver the best
              possible product by the date.

              Ron Jeffries
              www.XProgramming.com
              www.xprogramming.com/blog
              Learning is a human process, and knowledge is not what is found in the library.
            • Ron Jeffries
              Hello, Anwars78. On Sunday, May 30, 2010, at 9:48:27 PM, you ... ??? Please try to phrase this in some other way. Ron Jeffries www.XProgramming.com
              Message 6 of 24 , May 30 6:54 PM
              • 0 Attachment
                Hello, Anwars78. On Sunday, May 30, 2010, at 9:48:27 PM, you
                wrote:

                > Is there a way to calculate estimate cost at completion?

                ??? Please try to phrase this in some other way.

                Ron Jeffries
                www.XProgramming.com
                www.xprogramming.com/blog
                A long range weather forecast should be obtained before leaving,
                as weather conditions are extremely unpredictable. --Natal Daily News
              • Roy Morien
                Estimating cost is quite easy, unlike estimating project compeltion date. Hmmm, maybe that s a contradiction, but I ll try to ignore that :) Project cost on a
                Message 7 of 24 , May 30 6:54 PM
                • 0 Attachment
                  Estimating cost is quite easy, unlike estimating project compeltion date. Hmmm, maybe that's a contradiction, but I'll try to ignore that :)
                   
                  Project cost on a software development cost is mostly people cost, unless you have new hardware purchases, for example, or must buy new development software (Visual Studio 2010, for example).
                   
                  So, people cost is calculated as :.
                   
                  Number of people on the project X their weekly salary X the number of weeks estimated in the project.
                   
                  AH, now there is the contradiction. If the completion date changes, then the people cost will change.
                   
                  I guess another complication here is, What do you include in people cost? If you buy Visual Studio 2010, and your team must train on that, is that training cost included in the project cost? Up to you, I guess, to decide that.
                   
                  Regards,
                  Roy Morien

                  To: scrumdevelopment@yahoogroups.com
                  From: anwars78@...
                  Date: Mon, 31 May 2010 01:48:27 +0000
                  Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum

                   
                  Hi,

                  Is there a way to calculate estimate cost at completion?

                  Regards

                  Anwar Sadat. Agile Project Management. Indonesia. +6281321666510


                  From: Roy Morien <roymorien@hotmail. com>
                  Sender: scrumdevelopment@ yahoogroups. com
                  Date: Mon, 31 May 2010 01:41:52 +0000
                  To: <scrumdevelopment@ yahoogroups. com>
                  ReplyTo: scrumdevelopment@ yahoogroups. com
                  Subject: RE: [scrumdevelopment] Status Reporting, scheduling estimation in Scrum

                   
                  I'm a little perplexed that you, having read Mike Cohn's book, still don't have the idea of how to estimate an entire project. Also, the fact that you are still talking about 'am entire project' reeks of traditional, full up-front estimating, which has been proven to not work on almost every project, software and engineering, for the last 50 years (and a few years before that, if you ignore software).
                   
                  On the face of it, knowing when the project will be finished is just not an option, not as a fixed, unmoveable and correct estimate, that is. No matter how you estimate it, that WILL necessarilly change due to circumstances in the future.
                   
                  I suggest that you become comfortable with the idea of adaptive planning and estimating first. Get rid of the thinking about estimating 'the whole project' up front, or at all.
                   
                  Then get comfortable with the ideas of User Stories, Project Backlog (aka Product Backlog) and Story Points.
                   
                  Finally, come to terms with the concept of team VELOCITY.
                   
                  Then apply all this to estimating the possible project completion date as of now, all things being equal (which they aren't), and the necessary activity of estimating again tomorrow, based on whatever nw knowledge you might have about requirements.
                   
                  As a workeable alternative, apply the above to a project with a fixed deadline. This approach allows you to estimate how much you will possibly be able to achieve by that deadline. This approach raises the idea of prioritising the Project Backlog items to a prominent practice.
                   
                  And be happy with the idea that nothing is fixed and unchangeable. Something's gotta give ... deadline, completion date, deliverable product ... whatever.
                   
                  And finally, when someone asks you to tell them exactly when the project will be finished, give them an estimate that you make clear to them is based on the best knowledge currenty available, but will definitely change as more is learned and understood about the requirements and other aspects of the project. AND don't make promises you can't keep!!
                   
                  Regards,
                  Roy Morien 
                   

                  To: scrumdevelopment@ yahoogroups. com
                  From: yu_sidney@yahoo. ca
                  Date: Sun, 30 May 2010 17:50:50 -0700
                  Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum

                   
                  Hello, all:


                  I am in the process of learning about Agile and Scrum and hope to use it at work.  I have also read Mike Cohn's User Story Applied, Agile Estimating and Planning(95% ) and Succeeding with Agile (70%).  However, I couldn't get the idea of how to estimate an entire project in order to answer the question "when are you going to be done with the project?"  Maybe I have problem with my comprehension skills, I suspect.... . I hope you can help me here.

                  Mike Cohn describes the product backlog as an iceberg, with detailed small stories at the top and big scary monster stories at the bottom.  If a project contains 4 phases, the very first phase is the really must-have basic stuff and the forth phase is the really advanced features (e.g. an expert system to intelligently assign call tickets to agents), how can I somewhat estimate the big user stories in the 3rd or 4th phases?  How can I know that a 40 story point story is not in fact a 100 point story?  It that happens, the estimate for the big stories will be really off by a lot.

                  Now if divide the total story points for all 4 phases by the velocity, the # of sprints required will also be off by quite a bit.  So I would give a very inaccurate answer to the "when will it be done' question.  Is this a valid concern?

                  I tried to answer this question on my own.... such as: maybe I will tell the product owner that I can give a fairly estimate on the first 2 phases but not on all 4 phases, OR maybe I can say the estimate of being done in 8 months is really rough and I will update you throughout the project, especially when we are doing the features for the 3rd and 4th phases.  But I can't convince myself that's what I should say or do.  Or perhaps a Agile-aware product owner would not even ask me to tell him the estimate on all 4 phases.

                  I think I am kind of asking the same question as  below 'how can one give an estimate for the entire product backlog for the entire project at the start.". Is it that in agile, one answers that question in an iterative way?

                  thanks.

                  Sidney

                  --- On Sun, 5/30/10, Ron Jeffries <ronjeffries@ acm.org> wrote:

                  From: Ron Jeffries <ronjeffries@ acm.org>
                  Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum
                  To: scrumdevelopment@ yahoogroups. com
                  Received: Sunday, May 30, 2010, 6:56 AM

                  Hello, b_aashish.  On Sunday, May 30, 2010, at 3:34:10 AM, you
                  wrote:

                  > Reporting status in Waterfall projects is easy - you have the
                  > milestones (e.g. Req Doc completed/sign- off, Design docs
                  > completed, coding finished etc.. You have an overall plan and
                  > schedule against which you report that the projecy is 25% comeplete etc.

                  Yes, except that the information is absolutely false. Completing a
                  requirements document in no way indicates anything about whether the
                  project will be done. It would be quite easy to write a requirements
                  document that was completely incapable of being implemented. Most of
                  them are at least PARTLY incapable of being implemented at all. Most
                  of them are incapable of being implemented fully.

                  So reporting Waterfall projects is easy ... unless you care about
                  the truth.

                  > How does one that in Scrum projects? Specially if it is a
                  > greenfield project. Does one do a high-level estimate/schedule of
                  > the entire Product backlog at the start? What kind of estimation
                  > would help here? How does one tell the customer how many sprints
                  > would be required to finish the complete the complete project? Any
                  > recommendations for status reporting? How can one apply EV here?

                  You are asking a different question than you answered above, even
                  not counting that the answer above isn't true.

                  With a Scrum project you have backlog items to do. You have a known
                  number of them (though you are allowed to change them, add them, and
                  delete them, because you're interested in the best result, not the
                  predicted result).

                  So you draw a Sprint burndown (or better yet burn UP) chart. From
                  the very first weeks of the project, this chart shows how fast you
                  are growing features. The slope of this curve intersects the line
                  showing how many features you want, at the delivery date.

                  > Any insight please?

                  It seems to me that some additional training and reading in Agile
                  and Scrum would be helpful, as the above is pretty basic stuff. I'll
                  point you here to some things I've written, and I hope that others
                  will do so as well.

                  Kate Oneal: The Empire Starts Out

                    After Dan Devlin, President of Oak River Software, dropped in on
                    her at the coffee shop, Kate agreed to consider helping with the
                    proposed new Empire project. Empire was life or death for Oak
                    River. Without Empire, they’d go under, and Dan couldn’t afford to
                    fund it.

                    http://xprogramming .com/kate- oneal/aokoempire /
                    (intro at http://xprogramming .com/kate- oneal/aokoprolog ue/)

                  Beyond Agile — The Agile Barrier

                    Agile projects very often seem to stall out after gaining perhaps
                    twenty-five percent of the possible benefit. Why is this? What can
                    be done?

                    NOTE: This article is part of a series about going beyond the
                    basics of Agile, but it points directly to the topic here, status
                    and scheduling.

                    http://xprogramming .com/xpmag/ beyond-agile- the-agile- barrier/


                  Agile and Scrum are not like what you're used to. Even some of the
                  questions aren't the same, much less the answers. Dig in, it's worth
                  it!

                  Ron Jeffries
                  www.XProgramming. com
                  www.xprogramming. com/blog
                  The fact that we know more today, and are more capable today,
                  is good news about today, not bad news about yesterday.



                  ------------ --------- --------- ------

                  To Post a message, send it to:   scrumdevelopment@ eGroups.com
                  To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo! Groups Links

                  <*> To visit your group on the web, go to:
                      http://groups. yahoo.com/ group/scrumdevel opment/

                  <*> Your email settings:
                      Individual Email | Traditional

                  <*> To change settings online go to:
                      http://groups. yahoo.com/ group/scrumdevel opment/join
                      (Yahoo! ID required)

                  <*> To change settings via email:
                      scrumdevelopment- digest@yahoogrou ps.com
                      scrumdevelopment- fullfeatured@ yahoogroups. com

                  <*> To unsubscribe from this group, send an email to:
                      scrumdevelopment- unsubscribe@ yahoogroups. com

                  <*> Your use of Yahoo! Groups is subject to:
                      http://docs. yahoo.com/ info/terms/





                  Find it on Domain.com.au Need a new place to live?





                  Meet local singles online. Browse profiles for FREE!
                • Roy Morien
                  Agreed, Ron, which was my alternative approach as stated, As a workeable alternative, apply the above to a project with a fixed deadline. This approach
                  Message 8 of 24 , May 30 6:58 PM
                  • 0 Attachment
                    Agreed, Ron, which was my 'alternative' approach as stated, "As a workeable alternative, apply the above to a project with a fixed deadline. This approach allows you to estimate how much you will possibly be able to achieve by that deadline."
                     
                    I would add here the caveat that fixed deadlines must be reasonable. Having a deadline that assumes much, but allows for little, is nonsense.
                     
                    Regards,
                    Roy Morien
                     
                    > To: scrumdevelopment@yahoogroups.com
                    > From: ronjeffries@...
                    > Date: Sun, 30 May 2010 21:54:05 -0400
                    > Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum
                    >
                    > Hello, Roy. On Sunday, May 30, 2010, at 9:41:52 PM, you wrote:
                    >
                    > > And finally, when someone asks you to tell them exactly when the
                    > > project will be finished, give them an estimate that you make
                    > > clear to them is based on the best knowledge currenty available,
                    > > but will definitely change as more is learned and understood about
                    > > the requirements and other aspects of the project. AND don't make promises you can't keep!!
                    >
                    > Actually, I don't agree with this. (I do agree with much of what
                    > went before.)
                    >
                    > It is perfectly possible to pick a date to be done and a dollar
                    > budget to be met and to do it using Scrum. You do it by managing
                    > scope.
                    >
                    > This is precisely the job of the Product Owner: Deliver the best
                    > possible product by the date.
                    >
                    > Ron Jeffries
                    > www.XProgramming.com
                    > www.xprogramming.com/blog
                    > Learning is a human process, and knowledge is not what is found in the library.
                    >
                    >
                    >
                    > ------------------------------------
                    >
                    > To Post a message, send it to: scrumdevelopment@...
                    > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                    >
                    > <*> To visit your group on the web, go to:
                    > http://groups.yahoo.com/group/scrumdevelopment/
                    >
                    > <*> Your email settings:
                    > Individual Email | Traditional
                    >
                    > <*> To change settings online go to:
                    > http://groups.yahoo.com/group/scrumdevelopment/join
                    > (Yahoo! ID required)
                    >
                    > <*> To change settings via email:
                    > scrumdevelopment-digest@yahoogroups.com
                    > scrumdevelopment-fullfeatured@yahoogroups.com
                    >
                    > <*> To unsubscribe from this group, send an email to:
                    > scrumdevelopment-unsubscribe@yahoogroups.com
                    >
                    > <*> Your use of Yahoo! Groups is subject to:
                    > http://docs.yahoo.com/info/terms/
                    >



                    Looking for a hot date? View photos of singles in your area!
                  • Michael Spayd
                    Hi Sidney, A few points for your consideration: - Story estimates, especially beyond the current sprint, are owned by the Product Owner - This is not to say
                    Message 9 of 24 , May 30 7:12 PM
                    • 0 Attachment
                      Hi Sidney,

                      A few points for your consideration:
                      • Story estimates, especially beyond the current sprint, are 'owned' by the Product Owner
                      • This is not to say that a Prod Owner is capable (at least typically) of making reasonable estimates, but rather that they are not the Team's estimates but for the sake of the Prod Owner in his business value calculations.
                      • The Prod Owner, in his/her responsibility to direct the product, often has a need to know how the business case will play out. Frequently, the only reasonable way to do this is to make estimates, at least through the next release (sometimes further).
                      • The Prod Owner can make the judgement that he/she can make the estimates--for the purposes of determining whether to proceed with the project--with minimal team input. If he is wrong, he is wrong, not the team.
                      • At other times, the Prod Owner needs more confidence in the estimates, so he/she uses the team's time to engage in more detailed release planning. They are still not commitments by the team, but one can frequently have a greater level of confidence in them since they were more carefully thought through.
                      • At the end of the day, the Prod Owner makes a decision every single sprint whether to go on with the project, not the team. It is his (and perhaps the project Sponsor's) decision. To put this on the team or the Project Manager/Scrum Master, is an abnegation of the Prod Owner's responsibility. To help him do this, Release Plan estimates should be updated after every sprint, so they will become more and more accurate.
                      • If you, as the Project Manager (I'm assuming here) take on that responsibility, you have not yet made the switch to the Agile mindset and are in danger of a disaster later on, in my experience.
                      Hope some of these points are helpful for your thinking.

                      Best,
                      Michael

                      -- 
                      Collective Edge Coaching, llc
                      "Helping teams to perform, and organizations to transform."
                      www.collective-edge.com
                      Michael K. Spayd, Principal & Chief Sage, ORSCC
                      (720) 300.5286  - (USA)
                      michael@...


                      On Sun, May 30, 2010 at 9:41 PM, Roy Morien <roymorien@...> wrote:
                       

                      I'm a little perplexed that you, having read Mike Cohn's book, still don't have the idea of how to estimate an entire project. Also, the fact that you are still talking about 'am entire project' reeks of traditional, full up-front estimating, which has been proven to not work on almost every project, software and engineering, for the last 50 years (and a few years before that, if you ignore software).
                       
                      On the face of it, knowing when the project will be finished is just not an option, not as a fixed, unmoveable and correct estimate, that is. No matter how you estimate it, that WILL necessarilly change due to circumstances in the future.
                       
                      I suggest that you become comfortable with the idea of adaptive planning and estimating first. Get rid of the thinking about estimating 'the whole project' up front, or at all.
                       
                      Then get comfortable with the ideas of User Stories, Project Backlog (aka Product Backlog) and Story Points.
                       
                      Finally, come to terms with the concept of team VELOCITY.
                       
                      Then apply all this to estimating the possible project completion date as of now, all things being equal (which they aren't), and the necessary activity of estimating again tomorrow, based on whatever nw knowledge you might have about requirements.
                       
                      As a workeable alternative, apply the above to a project with a fixed deadline. This approach allows you to estimate how much you will possibly be able to achieve by that deadline. This approach raises the idea of prioritising the Project Backlog items to a prominent practice.
                       
                      And be happy with the idea that nothing is fixed and unchangeable. Something's gotta give ... deadline, completion date, deliverable product ... whatever.
                       
                      And finally, when someone asks you to tell them exactly when the project will be finished, give them an estimate that you make clear to them is based on the best knowledge currenty available, but will definitely change as more is learned and understood about the requirements and other aspects of the project. AND don't make promises you can't keep!!
                       
                      Regards,
                      Roy Morien 
                       


                      To: scrumdevelopment@yahoogroups.com
                      From: yu_sidney@...
                      Date: Sun, 30 May 2010 17:50:50 -0700

                      Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum

                       
                      Hello, all:


                      I am in the process of learning about Agile and Scrum and hope to use it at work.  I have also read Mike Cohn's User Story Applied, Agile Estimating and Planning(95%) and Succeeding with Agile (70%).  However, I couldn't get the idea of how to estimate an entire project in order to answer the question "when are you going to be done with the project?"  Maybe I have problem with my comprehension skills, I suspect.... . I hope you can help me here.

                      Mike Cohn describes the product backlog as an iceberg, with detailed small stories at the top and big scary monster stories at the bottom.  If a project contains 4 phases, the very first phase is the really must-have basic stuff and the forth phase is the really advanced features (e.g. an expert system to intelligently assign call tickets to agents), how can I somewhat estimate the big user stories in the 3rd or 4th phases?  How can I know that a 40 story point story is not in fact a 100 point story?  It that happens, the estimate for the big stories will be really off by a lot.

                      Now if divide the total story points for all 4 phases by the velocity, the # of sprints required will also be off by quite a bit.  So I would give a very inaccurate answer to the "when will it be done' question.  Is this a valid concern?

                      I tried to answer this question on my own.... such as: maybe I will tell the product owner that I can give a fairly estimate on the first 2 phases but not on all 4 phases, OR maybe I can say the estimate of being done in 8 months is really rough and I will update you throughout the project, especially when we are doing the features for the 3rd and 4th phases.  But I can't convince myself that's what I should say or do.  Or perhaps a Agile-aware product owner would not even ask me to tell him the estimate on all 4 phases.

                      I think I am kind of asking the same question as  below 'how can one give an estimate for the entire product backlog for the entire project at the start.". Is it that in agile, one answers that question in an iterative way?

                      thanks.

                      Sidney

                      --- On Sun, 5/30/10, Ron Jeffries <ronjeffries@...> wrote:

                      From: Ron Jeffries <ronjeffries@...>
                      Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation in Scrum
                      To: scrumdevelopment@yahoogroups.com
                      Received: Sunday, May 30, 2010, 6:56 AM

                      Hello, b_aashish.  On Sunday, May 30, 2010, at 3:34:10 AM, you
                      wrote:

                      > Reporting status in Waterfall projects is easy - you have the
                      > milestones (e.g. Req Doc completed/sign-off, Design docs
                      > completed, coding finished etc.. You have an overall plan and
                      > schedule against which you report that the projecy is 25% comeplete etc.

                      Yes, except that the information is absolutely false. Completing a
                      requirements document in no way indicates anything about whether the
                      project will be done. It would be quite easy to write a requirements
                      document that was completely incapable of being implemented. Most of
                      them are at least PARTLY incapable of being implemented at all. Most
                      of them are incapable of being implemented fully.

                      So reporting Waterfall projects is easy ... unless you care about
                      the truth.

                      > How does one that in Scrum projects? Specially if it is a
                      > greenfield project. Does one do a high-level estimate/schedule of
                      > the entire Product backlog at the start? What kind of estimation
                      > would help here? How does one tell the customer how many sprints
                      > would be required to finish the complete the complete project? Any
                      > recommendations for status reporting? How can one apply EV here?

                      You are asking a different question than you answered above, even
                      not counting that the answer above isn't true.

                      With a Scrum project you have backlog items to do. You have a known
                      number of them (though you are allowed to change them, add them, and
                      delete them, because you're interested in the best result, not the
                      predicted result).

                      So you draw a Sprint burndown (or better yet burn UP) chart. From
                      the very first weeks of the project, this chart shows how fast you
                      are growing features. The slope of this curve intersects the line
                      showing how many features you want, at the delivery date.

                      > Any insight please?

                      It seems to me that some additional training and reading in Agile
                      and Scrum would be helpful, as the above is pretty basic stuff. I'll
                      point you here to some things I've written, and I hope that others
                      will do so as well.

                      Kate Oneal: The Empire Starts Out

                        After Dan Devlin, President of Oak River Software, dropped in on
                        her at the coffee shop, Kate agreed to consider helping with the
                        proposed new Empire project. Empire was life or death for Oak
                        River. Without Empire, they’d go under, and Dan couldn’t afford to
                        fund it.

                        http://xprogramming.com/kate-oneal/aokoempire/
                        (intro at http://xprogramming.com/kate-oneal/aokoprologue/)

                      Beyond Agile — The Agile Barrier

                        Agile projects very often seem to stall out after gaining perhaps
                        twenty-five percent of the possible benefit. Why is this? What can
                        be done?

                        NOTE: This article is part of a series about going beyond the
                        basics of Agile, but it points directly to the topic here, status
                        and scheduling.

                        http://xprogramming.com/xpmag/beyond-agile-the-agile-barrier/


                      Agile and Scrum are not like what you're used to. Even some of the
                      questions aren't the same, much less the answers. Dig in, it's worth
                      it!

                      Ron Jeffries
                      www.XProgramming.com
                      www.xprogramming.com/blog
                      The fact that we know more today, and are more capable today,
                      is good news about today, not bad news about yesterday.



                      ------------------------------------

                      To Post a message, send it to:   scrumdevelopment@...
                      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                      <*> To visit your group on the web, go to:
                          http://groups.yahoo.com/group/scrumdevelopment/

                      <*> Your email settings:
                          Individual Email | Traditional

                      <*> To change settings online go to:
                          http://groups.yahoo.com/group/scrumdevelopment/join
                          (Yahoo! ID required)

                      <*> To change settings via email:
                          scrumdevelopment-digest@yahoogroups.com
                          scrumdevelopment-fullfeatured@yahoogroups.com

                      <*> To unsubscribe from this group, send an email to:
                          scrumdevelopment-unsubscribe@yahoogroups.com

                      <*> Your use of Yahoo! Groups is subject to:
                          http://docs.yahoo.com/info/terms/





                      Find it on Domain.com.au Need a new place to live?





                    • anwars78@yahoo.com
                      ok, Currently, I still manage project which already late for 1 years. I just involving in the middle of project, and planning to adapt scrum. As part of
                      Message 10 of 24 , May 30 7:14 PM
                      • 0 Attachment
                        ok,

                        Currently, I still manage project which already late for 1 years. I just involving in the middle of project, and planning to adapt scrum.

                        As part of management report, I shall also provide estimate cost at completion, that sure for worst case scenario. Traditionally I will use earn value estimation for estimate cost at completion, so I get curious, if I can this technique also in scrum.

                        I am listening and look forward for advice and suggestion.

                        Regards




                        Anwar Sadat. Agile Project Management. Indonesia. +6281321666510


                        -----Original Message-----
                        From: Ron Jeffries <ronjeffries@...>
                        Sender: scrumdevelopment@yahoogroups.com
                        Date: Sun, 30 May 2010 21:54:29
                        To: <scrumdevelopment@yahoogroups.com>
                        Reply-To: scrumdevelopment@yahoogroups.com
                        Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum

                        Hello, Anwars78. On Sunday, May 30, 2010, at 9:48:27 PM, you
                        wrote:

                        > Is there a way to calculate estimate cost at completion?

                        ??? Please try to phrase this in some other way.

                        Ron Jeffries
                        www.XProgramming.com
                        www.xprogramming.com/blog
                        A long range weather forecast should be obtained before leaving,
                        as weather conditions are extremely unpredictable. --Natal Daily News



                        ------------------------------------

                        To Post a message, send it to: scrumdevelopment@...
                        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                      • Roy Morien
                        What has made it late ? And what does late mean? Is it because the project has gone badly, or slowly, or is it because someone promised a delivery date that
                        Message 11 of 24 , May 30 8:46 PM
                        • 0 Attachment
                          What has made it 'late'?
                           
                          And what does 'late' mean? Is it because the project has gone badly, or slowly, or is it because someone promised a delivery date that couldn't be met, however well the project proceeded? This is one big problem with 'late' projects. It may just be because of nonsensical 'estimating' at the start. It could also be because the developers, and the users, didn't understand the real requirements, and/or were unable to specify them all up front (which is usually impossible anyway)? Have requirements evolved, but the deadline didn't?
                           
                          When did you first start to notice that the project was 'late'? What was one about that?
                           
                          How have you managed requirements? Do you have a change control regime that allows you to refuse new requirements as they arise, or did you allow 'scope creep' without making changes to the deadline that this demanded.
                           
                          Who is being 'blamed' for the project being 'late'?
                           
                          All sort of interesting questions arise when you talk about a project being 'late'. It is not unreasonable to think that the project is actually rolling along wonderfully well, but the estimates and assumptions at the start were totlly wrong and unrealistic.
                           
                          And maybe 'plan the work and work the plan' just doesn't work!
                           
                          Regards,
                          Roy Morien
                           

                          To: scrumdevelopment@yahoogroups.com
                          From: anwars78@...
                          Date: Mon, 31 May 2010 02:14:00 +0000
                          Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum

                           
                          ok,

                          Currently, I still manage project which already late for 1 years. I just involving in the middle of project, and planning to adapt scrum.

                          As part of management report, I shall also provide estimate cost at completion, that sure for worst case scenario. Traditionally I will use earn value estimation for estimate cost at completion, so I get curious, if I can this technique also in scrum.

                          I am listening and look forward for advice and suggestion.

                          Regards




                          Anwar Sadat. Agile Project Management. Indonesia. +6281321666510


                          -----Original Message-----
                          From: Ron Jeffries <ronjeffries@...>
                          Sender: scrumdevelopment@yahoogroups.com
                          Date: Sun, 30 May 2010 21:54:29
                          To: <scrumdevelopment@yahoogroups.com>
                          Reply-To: scrumdevelopment@yahoogroups.com
                          Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum

                          Hello, Anwars78. On Sunday, May 30, 2010, at 9:48:27 PM, you
                          wrote:

                          > Is there a way to calculate estimate cost at completion?

                          ??? Please try to phrase this in some other way.

                          Ron Jeffries
                          www.XProgramming.com
                          www.xprogramming.com/blog
                          A long range weather forecast should be obtained before leaving,
                          as weather conditions are extremely unpredictable. --Natal Daily News



                          ------------------------------------

                          To Post a message, send it to: scrumdevelopment@...
                          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links






                          Meet local singles online. Browse profiles for FREE!
                        • anwars78@yahoo.com
                          Thanks ron, The project got late because there are unclear requirement before (typically problem) and have installed additional platform by client order
                          Message 12 of 24 , May 30 10:40 PM
                          • 0 Attachment
                            Thanks ron,

                            The project got late because there are unclear requirement before (typically problem) and have installed additional platform by client order which unfortunately contain major bug.

                            When I am involving, previously project manager had out from project, and team have not any schedule and plan at all, they just flow as fire fighter.

                            I am still building product backlog with PO, and starting develop project plan, meanwhile my boss asking about estimate cost at completion. Now I am still calculate cost based on resource cost and time plan, and trying to suggest my boss that estimate cost will be burning cost already (sunk cost) + new budget propose .

                            Perhaps there are any better idea?

                            Regards


                            Anwar Sadat. Agile Project Management. Indonesia. +6281321666510


                            From: Roy Morien <roymorien@...>
                            Sender: scrumdevelopment@yahoogroups.com
                            Date: Mon, 31 May 2010 03:46:36 +0000
                            To: <scrumdevelopment@yahoogroups.com>
                            ReplyTo: scrumdevelopment@yahoogroups.com
                            Subject: RE: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum

                             

                            What has made it 'late'?
                             
                            And what does 'late' mean? Is it because the project has gone badly, or slowly, or is it because someone promised a delivery date that couldn't be met, however well the project proceeded? This is one big problem with 'late' projects. It may just be because of nonsensical 'estimating' at the start. It could also be because the developers, and the users, didn't understand the real requirements, and/or were unable to specify them all up front (which is usually impossible anyway)? Have requirements evolved, but the deadline didn't?
                             
                            When did you first start to notice that the project was 'late'? What was one about that?
                             
                            How have you managed requirements? Do you have a change control regime that allows you to refuse new requirements as they arise, or did you allow 'scope creep' without making changes to the deadline that this demanded.
                             
                            Who is being 'blamed' for the project being 'late'?
                             
                            All sort of interesting questions arise when you talk about a project being 'late'. It is not unreasonable to think that the project is actually rolling along wonderfully well, but the estimates and assumptions at the start were totlly wrong and unrealistic.
                             
                            And maybe 'plan the work and work the plan' just doesn't work!
                             
                            Regards,
                            Roy Morien
                             


                            To: scrumdevelopment@ yahoogroups. com
                            From: anwars78@yahoo. com
                            Date: Mon, 31 May 2010 02:14:00 +0000
                            Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum

                             
                            ok,

                            Currently, I still manage project which already late for 1 years. I just involving in the middle of project, and planning to adapt scrum.

                            As part of management report, I shall also provide estimate cost at completion, that sure for worst case scenario. Traditionally I will use earn value estimation for estimate cost at completion, so I get curious, if I can this technique also in scrum.

                            I am listening and look forward for advice and suggestion.

                            Regards




                            Anwar Sadat. Agile Project Management. Indonesia. +6281321666510


                            -----Original Message-----
                            From: Ron Jeffries <ronjeffries@ acm.org>
                            Sender: scrumdevelopment@ yahoogroups. com
                            Date: Sun, 30 May 2010 21:54:29
                            To: <scrumdevelopment@ yahoogroups. com>
                            Reply-To: scrumdevelopment@ yahoogroups. com
                            Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum

                            Hello, Anwars78. On Sunday, May 30, 2010, at 9:48:27 PM, you
                            wrote:

                            > Is there a way to calculate estimate cost at completion?

                            ??? Please try to phrase this in some other way.

                            Ron Jeffries
                            www.XProgramming. com
                            www.xprogramming. com/blog
                            A long range weather forecast should be obtained before leaving,
                            as weather conditions are extremely unpredictable. --Natal Daily News



                            ------------ --------- --------- ------

                            To Post a message, send it to: scrumdevelopment@ eGroups.com
                            To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo! Groups Links






                            Meet local singles online. Browse profiles for FREE!
                          • Roy Morien
                            I m Roy, but no matter. Ron may be a bit put out, though. :) Your comment about the project being late because of unclear requirements sparks some interesting
                            Message 13 of 24 , May 30 11:22 PM
                            • 0 Attachment
                              I'm Roy, but no matter. Ron may be a bit put out, though. :)
                               
                              Your comment about the project being late because of unclear requirements sparks some interesting rethoughts. Of course requirements are unclear; they always are unclear, for many reasons. The problem is that people pretend that the requirements are clear enough to give promises about completion dates and costs, which they call 'estimates', but managers and clients hold you to it as if they are totally correct.
                               
                              I am troubled by your statement "I am still building product backlog with PO, and starting develop project plan". This still sounds like you are trying to get it all planned up-front, which was the problem in the first place. Rather than trying to get all the requirements documented in the Product Backlog, why not just include those requirements that people can give you very quickly, and then prioritise them, and actually start delivering. The fact is, the old 80/20 rule really does apply. You can get 80% requirements in 20% of the time. In fact, I would suggest that in one day you can gather enough requirements to keep you busy developing for months. Then you apply adaptive planning and reqirements determination, modifying the Product Backlog as necessary.  
                               
                              "I am still building product backlog with PO, and starting develop project plan". So how much time are you spending "building the product backlog"? How are you recording the requirements; are you using User Stories?
                               
                              What is the length of your sprints? I would suggest that you gather enough requirements, as User Stories, to give you enough work for maybe 4 sprints. If you then start delivering, your client and your boss may stop asking or completion dates and total estimated project costs, and will be delighted that you are delivering useful software so soon. During those 4 initial sprints, you can be adding to the requirements, and refining the estimates ... but you will be delivering software, which is the main purpose of it all.
                               
                              Another email recently talked about how completing the requirements document could be seen as progress, that could be measured, and would show that the project is proceeding. This is rubbish! Ask youself the simple question "Why are we doing this project?". The answer certainly will not include "So that we can have a lovely requirements document".
                               
                              One fact is indisputable. Whatever you decide today, will be just a little bit incorrect tomorrow. A lot of time can be wasted "building the product backlog" with as much information as you can possibly get, but then you find that it changes, and a lot of your time has been wasted. Read up on Just-in-Time requirements determination. It's good thinking!
                               
                              You see, your boss' demand for estimates now about costs and deadlines at sometime in the future are based on the assumption that you can indeed know these things now, and you will not receive any new knowledge that will modify that in the future. This is just wrong thinking!
                               
                              Regards,
                              Roy Morien

                               

                              To: scrumdevelopment@yahoogroups.com
                              From: anwars78@...
                              Date: Mon, 31 May 2010 05:40:30 +0000
                              Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimationinScrum

                               
                              Thanks ron,

                              The project got late because there are unclear requirement before (typically problem) and have installed additional platform by client order which unfortunately contain major bug.

                              When I am involving, previously project manager had out from project, and team have not any schedule and plan at all, they just flow as fire fighter.

                              I am still building product backlog with PO, and starting develop project plan, meanwhile my boss asking about estimate cost at completion. Now I am still calculate cost based on resource cost and time plan, and trying to suggest my boss that estimate cost will be burning cost already (sunk cost) + new budget propose .

                              Perhaps there are any better idea?

                              Regards


                              Anwar Sadat. Agile Project Management. Indonesia. +6281321666510


                              From: Roy Morien <roymorien@hotmail. com>
                              Sender: scrumdevelopment@ yahoogroups. com
                              Date: Mon, 31 May 2010 03:46:36 +0000
                              To: <scrumdevelopment@ yahoogroups. com>
                              ReplyTo: scrumdevelopment@ yahoogroups. com
                              Subject: RE: [scrumdevelopment] Status Reporting, scheduling estimation inScrum

                               
                              What has made it 'late'?
                               
                              And what does 'late' mean? Is it because the project has gone badly, or slowly, or is it because someone promised a delivery date that couldn't be met, however well the project proceeded? This is one big problem with 'late' projects. It may just be because of nonsensical 'estimating' at the start. It could also be because the developers, and the users, didn't understand the real requirements, and/or were unable to specify them all up front (which is usually impossible anyway)? Have requirements evolved, but the deadline didn't?
                               
                              When did you first start to notice that the project was 'late'? What was one about that?
                               
                              How have you managed requirements? Do you have a change control regime that allows you to refuse new requirements as they arise, or did you allow 'scope creep' without making changes to the deadline that this demanded.
                               
                              Who is being 'blamed' for the project being 'late'?
                               
                              All sort of interesting questions arise when you talk about a project being 'late'. It is not unreasonable to think that the project is actually rolling along wonderfully well, but the estimates and assumptions at the start were totlly wrong and unrealistic.
                               
                              And maybe 'plan the work and work the plan' just doesn't work!
                               
                              Regards,
                              Roy Morien
                               

                              To: scrumdevelopment@ yahoogroups. com
                              From: anwars78@yahoo. com
                              Date: Mon, 31 May 2010 02:14:00 +0000
                              Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum

                               
                              ok,

                              Currently, I still manage project which already late for 1 years. I just involving in the middle of project, and planning to adapt scrum.

                              As part of management report, I shall also provide estimate cost at completion, that sure for worst case scenario. Traditionally I will use earn value estimation for estimate cost at completion, so I get curious, if I can this technique also in scrum.

                              I am listening and look forward for advice and suggestion.

                              Regards




                              Anwar Sadat. Agile Project Management. Indonesia. +6281321666510


                              -----Original Message-----
                              From: Ron Jeffries <ronjeffries@ acm.org>
                              Sender: scrumdevelopment@ yahoogroups. com
                              Date: Sun, 30 May 2010 21:54:29
                              To: <scrumdevelopment@ yahoogroups. com>
                              Reply-To: scrumdevelopment@ yahoogroups. com
                              Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum

                              Hello, Anwars78. On Sunday, May 30, 2010, at 9:48:27 PM, you
                              wrote:

                              > Is there a way to calculate estimate cost at completion?

                              ??? Please try to phrase this in some other way.

                              Ron Jeffries
                              www.XProgramming. com
                              www.xprogramming. com/blog
                              A long range weather forecast should be obtained before leaving,
                              as weather conditions are extremely unpredictable. --Natal Daily News



                              ------------ --------- --------- ------

                              To Post a message, send it to: scrumdevelopment@ eGroups.com
                              To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo! Groups Links






                              Meet local singles online. Browse profiles for FREE!





                              Meet local singles online. Browse profiles for FREE!
                            • woynam
                              My first suggestion is to stop saying that your project is late. I m guessing that the project is probably where it should be, and the initial estimate was too
                              Message 14 of 24 , Jun 1, 2010
                              • 0 Attachment
                                My first suggestion is to stop saying that your project is late. I'm guessing that the project is probably where it should be, and the initial estimate was too optimistic.

                                See, by saying that the project is late you're buying into the myth that one can accurately predict the future. If the project is "behind schedule", it must be the fault of the team, as the plan says we're supposed to be done, and the plan can't be wrong, now can it?

                                So, start by firing the person who said the project could be done in the original time frame. That will boost the moral of the team. :-)

                                How many features do you have done? What's the combined size (measured in story points) for the completed features? How big is the remaining backlog? Assuming you have to complete all features in the backlog, you can easily use velocity to calculate the time needed to complete the backlog, and the final cost. Of course, if you want to save time and money, you'll skip some of the low priority features.

                                Mark

                                --- In scrumdevelopment@yahoogroups.com, anwars78@... wrote:
                                >
                                > ok,
                                >
                                > Currently, I still manage project which already late for 1 years. I just involving in the middle of project, and planning to adapt scrum.
                                >
                                > As part of management report, I shall also provide estimate cost at completion, that sure for worst case scenario. Traditionally I will use earn value estimation for estimate cost at completion, so I get curious, if I can this technique also in scrum.
                                >
                                > I am listening and look forward for advice and suggestion.
                                >
                                > Regards
                                >
                                >
                                >
                                >
                                > Anwar Sadat. Agile Project Management. Indonesia. +6281321666510
                                >
                                >
                                > -----Original Message-----
                                > From: Ron Jeffries <ronjeffries@...>
                                > Sender: scrumdevelopment@yahoogroups.com
                                > Date: Sun, 30 May 2010 21:54:29
                                > To: <scrumdevelopment@yahoogroups.com>
                                > Reply-To: scrumdevelopment@yahoogroups.com
                                > Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum
                                >
                                > Hello, Anwars78. On Sunday, May 30, 2010, at 9:48:27 PM, you
                                > wrote:
                                >
                                > > Is there a way to calculate estimate cost at completion?
                                >
                                > ??? Please try to phrase this in some other way.
                                >
                                > Ron Jeffries
                                > www.XProgramming.com
                                > www.xprogramming.com/blog
                                > A long range weather forecast should be obtained before leaving,
                                > as weather conditions are extremely unpredictable. --Natal Daily News
                                >
                                >
                                >
                                > ------------------------------------
                                >
                                > To Post a message, send it to: scrumdevelopment@...
                                > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                >
                              • sep
                                Late is perfectly reasonable and descriptive - it means no longer expected to be complete at the planned release date . You just need to remember that it
                                Message 15 of 24 , Jun 1, 2010
                                • 0 Attachment
                                  "Late" is perfectly reasonable and descriptive - it means "no longer expected to be complete at the planned release date". You just need to remember that it isn't pejorative.

                                  You also need to be continuously (at least each sprint) considering the statistics Mark mentions below and considering whether it's more important to include all the planned features or to deliver on the planned date, and adjust one knob (date) or the other (scope).

                                  regards,

                                  scott

                                  --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                                  >
                                  >
                                  > My first suggestion is to stop saying that your project is late. I'm guessing that the project is probably where it should be, and the initial estimate was too optimistic.
                                  >
                                  > See, by saying that the project is late you're buying into the myth that one can accurately predict the future. If the project is "behind schedule", it must be the fault of the team, as the plan says we're supposed to be done, and the plan can't be wrong, now can it?
                                  >
                                  > So, start by firing the person who said the project could be done in the original time frame. That will boost the moral of the team. :-)
                                  >
                                  > How many features do you have done? What's the combined size (measured in story points) for the completed features? How big is the remaining backlog? Assuming you have to complete all features in the backlog, you can easily use velocity to calculate the time needed to complete the backlog, and the final cost. Of course, if you want to save time and money, you'll skip some of the low priority features.
                                  >
                                  > Mark
                                  >
                                  > --- In scrumdevelopment@yahoogroups.com, anwars78@ wrote:
                                  > >
                                  > > ok,
                                  > >
                                  > > Currently, I still manage project which already late for 1 years. I just involving in the middle of project, and planning to adapt scrum.
                                  > >
                                  > > As part of management report, I shall also provide estimate cost at completion, that sure for worst case scenario. Traditionally I will use earn value estimation for estimate cost at completion, so I get curious, if I can this technique also in scrum.
                                  > >
                                  > > I am listening and look forward for advice and suggestion.
                                  > >
                                  > > Regards
                                  > >
                                  > >
                                  > >
                                  > >
                                  > > Anwar Sadat. Agile Project Management. Indonesia. +6281321666510
                                  > >
                                  > >
                                  > > -----Original Message-----
                                  > > From: Ron Jeffries <ronjeffries@>
                                  > > Sender: scrumdevelopment@yahoogroups.com
                                  > > Date: Sun, 30 May 2010 21:54:29
                                  > > To: <scrumdevelopment@yahoogroups.com>
                                  > > Reply-To: scrumdevelopment@yahoogroups.com
                                  > > Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum
                                  > >
                                  > > Hello, Anwars78. On Sunday, May 30, 2010, at 9:48:27 PM, you
                                  > > wrote:
                                  > >
                                  > > > Is there a way to calculate estimate cost at completion?
                                  > >
                                  > > ??? Please try to phrase this in some other way.
                                  > >
                                  > > Ron Jeffries
                                  > > www.XProgramming.com
                                  > > www.xprogramming.com/blog
                                  > > A long range weather forecast should be obtained before leaving,
                                  > > as weather conditions are extremely unpredictable. --Natal Daily News
                                  > >
                                  > >
                                  > >
                                  > > ------------------------------------
                                  > >
                                  > > To Post a message, send it to: scrumdevelopment@
                                  > > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@! Groups Links
                                  > >
                                  >
                                • Dan Rawsthorne
                                  I like to say later than expected rather than later than planned -- expectation rather than plan... discuss... Dan Rawsthorne, PhD, CST Senior
                                  Message 16 of 24 , Jun 1, 2010
                                  • 0 Attachment
                                    I like to say "later than expected" rather than "later than planned" --
                                    expectation rather than plan... discuss...

                                    Dan Rawsthorne, PhD, CST
                                    Senior Trainer/Coach, CollabNet
                                    drawsthorne@..., 425-269-8628



                                    sep wrote:
                                    >
                                    > "Late" is perfectly reasonable and descriptive - it means "no longer
                                    > expected to be complete at the planned release date". You just need to
                                    > remember that it isn't pejorative.
                                    >
                                    > You also need to be continuously (at least each sprint) considering
                                    > the statistics Mark mentions below and considering whether it's more
                                    > important to include all the planned features or to deliver on the
                                    > planned date, and adjust one knob (date) or the other (scope).
                                    >
                                    > regards,
                                    >
                                    > scott
                                    >
                                    > --- In scrumdevelopment@yahoogroups.com
                                    > <mailto:scrumdevelopment%40yahoogroups.com>, "woynam" <woyna@...> wrote:
                                    > >
                                    > >
                                    > > My first suggestion is to stop saying that your project is late. I'm
                                    > guessing that the project is probably where it should be, and the
                                    > initial estimate was too optimistic.
                                    > >
                                    > > See, by saying that the project is late you're buying into the myth
                                    > that one can accurately predict the future. If the project is "behind
                                    > schedule", it must be the fault of the team, as the plan says we're
                                    > supposed to be done, and the plan can't be wrong, now can it?
                                    > >
                                    > > So, start by firing the person who said the project could be done in
                                    > the original time frame. That will boost the moral of the team. :-)
                                    > >
                                    > > How many features do you have done? What's the combined size
                                    > (measured in story points) for the completed features? How big is the
                                    > remaining backlog? Assuming you have to complete all features in the
                                    > backlog, you can easily use velocity to calculate the time needed to
                                    > complete the backlog, and the final cost. Of course, if you want to
                                    > save time and money, you'll skip some of the low priority features.
                                    > >
                                    > > Mark
                                    > >
                                    > > --- In scrumdevelopment@yahoogroups.com
                                    > <mailto:scrumdevelopment%40yahoogroups.com>, anwars78@ wrote:
                                    > > >
                                    > > > ok,
                                    > > >
                                    > > > Currently, I still manage project which already late for 1 years.
                                    > I just involving in the middle of project, and planning to adapt scrum.
                                    > > >
                                    > > > As part of management report, I shall also provide estimate cost
                                    > at completion, that sure for worst case scenario. Traditionally I will
                                    > use earn value estimation for estimate cost at completion, so I get
                                    > curious, if I can this technique also in scrum.
                                    > > >
                                    > > > I am listening and look forward for advice and suggestion.
                                    > > >
                                    > > > Regards
                                    > > >
                                    > > >
                                    > > >
                                    > > >
                                    > > > Anwar Sadat. Agile Project Management. Indonesia. +6281321666510
                                    > > >
                                    > > >
                                    > > > -----Original Message-----
                                    > > > From: Ron Jeffries <ronjeffries@>
                                    > > > Sender: scrumdevelopment@yahoogroups.com
                                    > <mailto:scrumdevelopment%40yahoogroups.com>
                                    > > > Date: Sun, 30 May 2010 21:54:29
                                    > > > To: <scrumdevelopment@yahoogroups.com
                                    > <mailto:scrumdevelopment%40yahoogroups.com>>
                                    > > > Reply-To: scrumdevelopment@yahoogroups.com
                                    > <mailto:scrumdevelopment%40yahoogroups.com>
                                    > > > Subject: Re: [scrumdevelopment] Status Reporting, scheduling &
                                    > estimation inScrum
                                    > > >
                                    > > > Hello, Anwars78. On Sunday, May 30, 2010, at 9:48:27 PM, you
                                    > > > wrote:
                                    > > >
                                    > > > > Is there a way to calculate estimate cost at completion?
                                    > > >
                                    > > > ??? Please try to phrase this in some other way.
                                    > > >
                                    > > > Ron Jeffries
                                    > > > www.XProgramming.com
                                    > > > www.xprogramming.com/blog
                                    > > > A long range weather forecast should be obtained before leaving,
                                    > > > as weather conditions are extremely unpredictable. --Natal Daily News
                                    > > >
                                    > > >
                                    > > >
                                    > > > ------------------------------------
                                    > > >
                                    > > > To Post a message, send it to: scrumdevelopment@
                                    > > > To Unsubscribe, send a blank message to:
                                    > scrumdevelopment-unsubscribe@! Groups Links
                                    > > >
                                    > >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    > =======
                                    > Email scanned by PC Tools - No viruses or spyware found.
                                    > (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15120)
                                    > http://www.pctools.com
                                    > <http://www.pctools.com/?cclick=EmailFooterClean_51>
                                    > =======
                                  • woynam
                                    Late != Later than planned. If it s later than planned, then say so. I ve seen too many cases where late really meant you guys screwed up , and it was not
                                    Message 17 of 24 , Jun 1, 2010
                                    • 0 Attachment
                                      Late != Later than planned. If it's later than planned, then say so. I've seen too many cases where "late" really meant "you guys screwed up", and it was not directed towards the planners.

                                      Mark

                                      --- In scrumdevelopment@yahoogroups.com, "sep" <sepreece@...> wrote:
                                      >
                                      > "Late" is perfectly reasonable and descriptive - it means "no longer expected to be complete at the planned release date". You just need to remember that it isn't pejorative.
                                      >
                                      > You also need to be continuously (at least each sprint) considering the statistics Mark mentions below and considering whether it's more important to include all the planned features or to deliver on the planned date, and adjust one knob (date) or the other (scope).
                                      >
                                      > regards,
                                      >
                                      > scott
                                      >
                                      > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                                      > >
                                      > >
                                      > > My first suggestion is to stop saying that your project is late. I'm guessing that the project is probably where it should be, and the initial estimate was too optimistic.
                                      > >
                                      > > See, by saying that the project is late you're buying into the myth that one can accurately predict the future. If the project is "behind schedule", it must be the fault of the team, as the plan says we're supposed to be done, and the plan can't be wrong, now can it?
                                      > >
                                      > > So, start by firing the person who said the project could be done in the original time frame. That will boost the moral of the team. :-)
                                      > >
                                      > > How many features do you have done? What's the combined size (measured in story points) for the completed features? How big is the remaining backlog? Assuming you have to complete all features in the backlog, you can easily use velocity to calculate the time needed to complete the backlog, and the final cost. Of course, if you want to save time and money, you'll skip some of the low priority features.
                                      > >
                                      > > Mark
                                      > >
                                      > > --- In scrumdevelopment@yahoogroups.com, anwars78@ wrote:
                                      > > >
                                      > > > ok,
                                      > > >
                                      > > > Currently, I still manage project which already late for 1 years. I just involving in the middle of project, and planning to adapt scrum.
                                      > > >
                                      > > > As part of management report, I shall also provide estimate cost at completion, that sure for worst case scenario. Traditionally I will use earn value estimation for estimate cost at completion, so I get curious, if I can this technique also in scrum.
                                      > > >
                                      > > > I am listening and look forward for advice and suggestion.
                                      > > >
                                      > > > Regards
                                      > > >
                                      > > >
                                      > > >
                                      > > >
                                      > > > Anwar Sadat. Agile Project Management. Indonesia. +6281321666510
                                      > > >
                                      > > >
                                      > > > -----Original Message-----
                                      > > > From: Ron Jeffries <ronjeffries@>
                                      > > > Sender: scrumdevelopment@yahoogroups.com
                                      > > > Date: Sun, 30 May 2010 21:54:29
                                      > > > To: <scrumdevelopment@yahoogroups.com>
                                      > > > Reply-To: scrumdevelopment@yahoogroups.com
                                      > > > Subject: Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum
                                      > > >
                                      > > > Hello, Anwars78. On Sunday, May 30, 2010, at 9:48:27 PM, you
                                      > > > wrote:
                                      > > >
                                      > > > > Is there a way to calculate estimate cost at completion?
                                      > > >
                                      > > > ??? Please try to phrase this in some other way.
                                      > > >
                                      > > > Ron Jeffries
                                      > > > www.XProgramming.com
                                      > > > www.xprogramming.com/blog
                                      > > > A long range weather forecast should be obtained before leaving,
                                      > > > as weather conditions are extremely unpredictable. --Natal Daily News
                                      > > >
                                      > > >
                                      > > >
                                      > > > ------------------------------------
                                      > > >
                                      > > > To Post a message, send it to: scrumdevelopment@
                                      > > > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@! Groups Links
                                      > > >
                                      > >
                                      >
                                    • George Dinwiddie
                                      Hi, Mark, ... I like to say, the schedule is ahead of reality. I think it puts things in the proper perspective. - George -- ... * George Dinwiddie *
                                      Message 18 of 24 , Jun 1, 2010
                                      • 0 Attachment
                                        Hi, Mark,

                                        woynam wrote:
                                        > My first suggestion is to stop saying that your project is late. I'm
                                        > guessing that the project is probably where it should be, and the
                                        > initial estimate was too optimistic.
                                        >
                                        > See, by saying that the project is late you're buying into the myth
                                        > that one can accurately predict the future. If the project is "behind
                                        > schedule", it must be the fault of the team, as the plan says we're
                                        > supposed to be done, and the plan can't be wrong, now can it?

                                        I like to say, "the schedule is ahead of reality." I think it puts
                                        things in the proper perspective.

                                        - George

                                        --
                                        ----------------------------------------------------------------------
                                        * George Dinwiddie * http://blog.gdinwiddie.com
                                        Software Development http://www.idiacomputing.com
                                        Consultant and Coach http://www.agilemaryland.org
                                        ----------------------------------------------------------------------
                                      • woynam
                                        Nice! :-)
                                        Message 19 of 24 , Jun 2, 2010
                                        • 0 Attachment
                                          Nice! :-)


                                          --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
                                          >
                                          > Hi, Mark,
                                          >
                                          > woynam wrote:
                                          > > My first suggestion is to stop saying that your project is late. I'm
                                          > > guessing that the project is probably where it should be, and the
                                          > > initial estimate was too optimistic.
                                          > >
                                          > > See, by saying that the project is late you're buying into the myth
                                          > > that one can accurately predict the future. If the project is "behind
                                          > > schedule", it must be the fault of the team, as the plan says we're
                                          > > supposed to be done, and the plan can't be wrong, now can it?
                                          >
                                          > I like to say, "the schedule is ahead of reality." I think it puts
                                          > things in the proper perspective.
                                          >
                                          > - George
                                          >
                                          > --
                                          > ----------------------------------------------------------------------
                                          > * 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.