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

47020Re: [scrumdevelopment] Status Reporting, scheduling & estimation inScrum

Expand Messages
  • anwars78@yahoo.com
    May 30, 2010
    • 0 Attachment

      Is there a way to calculate estimate cost at completion?


      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!!
      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?



      --- 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

      > 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

      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?
    • Show all 24 messages in this topic