Re: [scrumdevelopment] Re: Baselining and Scrum
- I'm curious about this one - "it may be useful". keyword there is "may be".
IMHO, if your experience in your current organisation seems to be pointing to using baselines (because tracking commit logs, issues in issue tracking system, sprint backlogs, etc are not enough), then go ahead and used baselines. How specifically will depend on why your current set up does not work.
However, if you're just assuming it may be useful, then that's a different story. A lot of things can be helpful, but some (or most) of them are addressing problems you probably won't encounter.
Personally, if you're just assuming it may be useful, then I suggest you don't do it. Just take note that it can be used in the future if you encounter the problems it is trying to solve. And if that problem does arise (which I don't think will have a significant cost), then use that process.
Btw, this also applies for other processes and tools as well. If a process/tool is solving a problem that has a low impact and/or is unlikely to happen, then why employ a costly process/tool?
And remember the basics, "Individuals and interactions over processes and tools." Be careful the processes/tools you introduce and verify if they actually help the team or if it hinders them :-)
Franz Allan Valencia See | Java Software Engineer
Twitter: http://www.twitter.com/franz_seeOn Wed, Feb 24, 2010 at 1:40 AM, dsrkkk <dsrkkk@...> wrote:
--- In email@example.com, Ron Jeffries <ronjeffries@...> wrote:
>> Hello, sharmila. On Monday, February 22, 2010, at 10:35:10 PM,What is meant by baselining? Baselining allows changes. Baselining provides the snapshot of data at a particular time. It may be useful in multi-user environment and large scale scrum projects.
> you wrote:
> > Another thing about baselining was if the stories have a scope
> > change as per the baseline, in a time and material kind of
> > contract the customer has to agree to pay the additional cost or
> > bare the consequences of the change.
> Baselining assumes that change is bad. Agile assumes that change is
> Ron Jeffries
> The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
- 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 firstname.lastname@example.org, 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