Haresh JoshiSenior Project Manager| GE T&D India ltdKalyan (West), Maharashtra, India
We use Scope, Schedule and cost baselines for traditional predictive projects.
Agile being adaptive and flexible for changes at any time, what is the significance of baselines? Saving Changes...
Baselines are just providing a basis for performance measurement. Even in a project following an adaptive lifecycle, there are certain constraints which we will want to measure performance against.
The classic view of waterfall vs agile shows the iron triangle turned on its head - whereas with the former, schedule & cost are viewed as being flexible, with the latter, scope is flexible. As such, you could consider schedule & cost as baselines.
With my current client, they baseline the following for ALL projects regardless of delivery approach: high-level capabilities, schedule & cost for a funding tranche. The latter two are somewhat academic as the very definition of a tranche dictates its duration and budget, but the capabilities committed to be delivered are where the uncertainty lies.Depending on the maturity of the team and their confidence in their delivery capabilities, they may commit to a shorter or longer tranche...
Kiron Saving Changes...
Haresh JoshiSenior Project Manager| GE T&D India ltdKalyan (West), Maharashtra, India
Thank you all for your insights.
I think at Sprint level, yes we are base lining the scope as we are not allowing changes within sprint. Any suggestions/feedback is getting added to Product backlog.
In my case, quality people insists on change request if baselines are affected and I argue being agile changes are allowed. So, why change request?
Based on the responses, I too think, within development there is a freedom, however we need to manage at high level. Saving Changes...
the use of change requests for projects following an adaptive lifecycle usually comes down to organization standards.
For example, with my current client (a large bank), teams cannot spend more than an approved budget. As such, if delivering a given release will take more sprints than was originally forecast, this implies more money required, and hence a PCR would be submitted. Another example is if there is a dramatic shift in product direction - for example, a major theme or capability is added without something equivalent being removed. In such cases, a PCR might be used to formalize this change. However, for the usual ebbs & flows of requirements, PCRs are not needed.
Kiron Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
Define your tolerances of scope, cost, time , quality appropriately for each sprint or the entire project at the outset and manage everything that exceed those tolerances using good Change Management practices. Saving Changes...
As high-uncertainty is existed in life cycle, traditional baseline management are useless for adopting agile frameworks because iteration and backlog preparation and refinement. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
As Keith and some others said, baselining can take many different forms. Baseline does not imply that you do a 2 year Gantt and then select the baseline function, it simply means you have an initial goal and if you deviate from this goal you deviate from baseline. Keep in mind that a baseline is to measure performance goals, not scope. So irrespective of whether you are using adaptive or predictive you still have performance indicators, typically burndown charts and velocity which you should baseline at the start to ensure that your performance i.e. timeline is in good shape.
BTW you could baseline any parameter if you really wanted, it would be determined if it actually adds value. Baselinining scope on a adaptive project on sprint level won't really add value because you fix the scope at that stage so NO change will take place to impact the baseline. Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
Jan 04, 2019 1:24 PM
Replying to Peter Ambrosy
...
In scrum projects you "baseline" your sprint scope through the selected and agreed product backlog items in order to keep the team focused.
That's an interesting way to look at it. From that perspective, a "sprint baseline" is actually more useful in scrum than in predictive projects because:
1) the "baseline" is for a shorter duration, making it inherently more accurate than a long-term baseline with greater uncertainty
2) the team regularly reviews their performance against the "baseline"
3) the team learns from previous iterations and makes better plans for the next "baseline."
Even so, I wouldn't use the term "baseline" with a scrum team. In project management, a "baseline" has come to imply a tool used to manage projects. I, the project manager, and/or someone higher in the organization is going to use a detailed project baseline as an excuse to rain down thunderbolts from Mt. Olympus to ensure we meet a deadline or budget constraint. By contrast, a mature scrum team should be self-managing and free of overlords. They might have a sprint "baseline," but there shouldn't be anyone outside the team using this to manage their work. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Interesting discussion.
As I see it, for Scrum, schedule and cost baselines are set as the number of sprints and the number of fulltime members on the team. If these are bound to change, and it happens, it requires a deep discussion and final decision by the PO - call it a change request. The scope baseline is the product backlog and a burndown chart represents the planned (baseline) and actual progress. Velocity can be compared to Earned Value's CPI. The scope is measured often by story points, sometimes by efforts or money. Changes to the scope baseline can happen either by re-prioritization by the PO or by changing estimates or adding stories by the team. Saving Changes...
I agree with you now, even if we can manage "easier" the changes on agile, there are some guidelines written in Project Vision. I mean, we are not restricted as traditional projects to follow a change control process, but the changes implemented cannot be out of the PVS.
I agree to your point that, baseline is useful in agile projects and that to externally or at control level. Moreover, scrum is use to manage the day-to-day work of Dev team. Though, as per scrum framework dev team members can decompose the work into WBS and make task / sub-tasks only for the current sprint not for the future sprints. But, then how a PM can estimate the cost, and schedule baseline for project without creating WBS (task / sub-tasks) for whole project work? Furthermore, how a scrum master can decided that in how many sprints he could able to complete the project? Request you to please reply Saving Changes...
I agree with you now, even if we can manage "easier" the changes on agile, there are some guidelines written in Project Vision. I mean, we are not restricted as traditional projects to follow a change control process, but the changes implemented cannot be out of the PVS.
Jesus request you please respond to my query. Saving Changes...
