PMO Leader | Speaker & Mentor | Content Leader – PMOGA Latin America
Hub| Catholic University of UruguayMontevideo, Montevideo, Uruguay
In an agile project, the schedule baseline is not established in the same way as in traditional projects. Instead of a fixed baseline, agile projects use an iterative and incremental approach to planning and tracking progress. However, there are key moments when expectations are set, and deliveries are planned.
Iteration Planning (Sprint Planning): At the beginning of each iteration or sprint, the agile team meets to plan the work for that period. They select items from the product backlog to complete during the sprint and estimate the effort required for each task.
Daily Stand-ups: These daily meetings allow the team to review progress and adjust the plan as needed. While a formal baseline is not set, progress is monitored, and continuous adjustments are made.
Sprint Review: At the end of each sprint, the team presents the completed work to stakeholders. This review allows for the evaluation of progress and adjustments to the product backlog based on feedback received.
Sprint Retrospective: After the sprint review, the team conducts a retrospective to analyze what went well and what can be improved. This helps to adjust processes and improve efficiency in future sprints.
In summary, in an agile project, planning and schedule tracking are done continuously and adaptively. There is no fixed baseline; instead, short iterations and frequent reviews are used to ensure the project stays on track and adjusts as necessary. Saving Changes...
There is no one standard for agile, although there may be for certain branded approaches. PMI's Disciplined Agile collects many different delivery models under the agile umbrella.
To know when to "baseline" a schedule, first understand that the function of a baseline is to give everyone a formal reference system for measuring other things. How much formality is required depends on your situation.
As projects grow in size, self-organizing teams within the larger team naturally form focused on their own pieces. Those various pieces still need to integrate together and there are often business constraints like contractual or regulatory dates and requirements that must be met. If lab time is expensive and difficult to schedule, everyone needs to be ready with their piece.
When you need to ensure that the many different sub-teams are all aligned to those major constraints, that is where you need to establish a formal baseline for synchronizing those critical items. If you can work directly with a relatively small number of people to execute a project where there is not a lot of oversight, a formal baseline per se might not even be needed. Saving Changes...
Depends on the approach. If the project or release are time-boxed, you can baseline the schedule quite early whereas the specific features or work items making up the project or release might change right up till the end.
This does require some confidence by the team that they can build something of value to stakeholders by the deadline.
Kiron Saving Changes...
Sunil ChainaniSr. Manger, PMO Process Improvement| XylemKenosha, Wi, United States
Thank you for your great responses. To provide more clarity....The project is a fixed bid project by the integrator and time/materials by 5 other IT suppliers. Approach is hybrid agile with 5 one month sprints with nothing being deployed until the end of all sprints for system/user testing of ~13 integrations and functionality. The team is uncovering requirements, evolving the architecture, designing and planning for one execution sprint at a time for demos at the end of each sprint. We are being asked when we will baseline the overall project, as the Business does not get value until the end of the project. :-)
We can create baselines at the end of each sprint and manage expectations that the final project baseline will only be known after planning the final sprint. Is there a better approach for managing expectations with management used to a predictive waterfall approach? Saving Changes...