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

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

Expand Messages
  • Ron Jeffries
    May 30, 2010
      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.
    • Show all 24 messages in this topic