Baselining and Scrum
- On top of that, the project is measured against the plan. It's assumed that the plan is handed down from the Almighty on High, i.e. the Project Manager, and must therefore be correct. Any deviation from the plan *must* be the fault of the team, and not the plan.
How about if we turn it around? I'm going to invent a new metric that measures the worthlessness of the plan. The more the project deviates from the plan, the more shit we'll heap on the PM.
Now, I just need a catchy name.
--- In email@example.com, Alan Dayley <alandd@...> wrote:
> In my simplistic opinion, a project has earned zero value until the end
> customer starts using it. Therefore, it does not matter to earned value how
> much "requirements gathering, planning, work breakdown, estimates, etc." is
> performed or how long doing all that takes. If the customer doesn't have
> some sort of usable product in his hands, earned value is zero.
> This is not the definition of "planned value" or "earned value" followed in
> the article you cite.
> There is value in a measure that can tell when a project is not progressing
> as expected. And the whole concept of EVM attempts to provide that measure.
> And it probably works if you could know everything up front. I don't see
> how it is anything but an artifact of "big design up front" and a world
> built on the fantasy that change can be controlled.
> On Mon, Apr 19, 2010 at 5:09 PM, john_hermann <john_hermann@...>wrote:
> > Hi folks,
> > I was referring to baselining as used in traditional PM, in particular
> > "planned value" in Earned Value Management (EVM) from days of olde. :-)
> > See http://en.wikipedia.org/wiki/Earned_value_management
> > <snip>
> > Earned value management (EVM) is a project management technique for
> > measuring project progress in an objective manner. EVM has the ability to
> > combine measurements of scope, schedule, and cost in a single integrated
> > system. When properly applied, EVM provides an early warning of performance
> > problems. Additionally, EVM promises to improve the definition of project
> > scope, prevent scope creep, communicate objective progress to stakeholders,
> > and keep the project team focused on achieving progress.
> > </snip>
> > It is pretty heavy, and works well on projects that have a lot of info
> > upfront, e.g., requirements gathering, planning, work breakdown, estimates,
> > etc. So not very agile-friendly.
> > However, an agile version has been proposed. See "Monitoring Scrum Projects
> > with AgileEVM and Earned Business Value (EBV) Metrics", Dan Rawsthorne
> > http://www.danube.com/system/files/WP_AgileEVM_and_Earned_Business_Value_Metrics.pdf
> > -johnny