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

47030RE: [scrumdevelopment] Status Reporting, scheduling & estimationinScrum

Expand Messages
  • Roy Morien
    May 30 11:22 PM
      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!
      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?


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


      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.


      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

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