Project Scheduling Best Practices in an Agile Environment

This is the second article in a series on project scheduling best practices. The first article, GAO Scheduling Best Practices, can be found here.

With the growing adoption of Agile project management methodologies, many organizations now employ some combination of traditional project management and Agile project management tools. While Agile techniques provide many useful progress indicators, the aspects of a traditional integrated master schedule (IMS) can be important for successful project and program management. An IMS may be the best way to communicate cost, schedule and scope with others who are not well versed in Agile terminology.

Whereas traditional project management techniques plan the schedule to the maximum extent possible, an Agile approach relies on a “roadmap” which is used to visually communicate high-level planned major capabilities. Lower level capabilities and tasks remain flexible in an Agile approach, with each “release” being a usable deliverable to the client which has been developed during one or more set periods of time known as “sprints.”

The GAO presentation, GAO Scheduling Best Practices Applied to an Agile Setting, discusses how scheduling techniques can be addressed in an Agile environment. Understanding the differences in scheduling methods can allow an organization to execute the practices that work best in light of stakeholder knowledge and the current organizational culture.

Most traditional scheduling best practices can be maintained at the release level for Agile methodologies. Following are ways to develop schedules when using Agile or combination project management styles:

Capturing and Sequencing Activities:

The nature of Agile allows for project details and activities to be developed for near-term plans as prototypes are released and assessed, but longer term activities are more general. In an Agile environment, the overall schedule is a reflection of the high-level roadmap with the “must have” customer features incorporated, based on the prioritization of deliverables communicated by the customer.

Activities for Agile projects should again be sequenced at the release level. Product features are ranked according to customer needs, resulting in the “sequence” of activities. Features are developed through one or more sprints in which teams execute tasks that can be completed within the set time period.

Assigning Resources and Establishing Durations:

Resource assignment applies to Agile sprints in the form of stable development teams. Team size should remain at between five to nine people. Multiple teams may be working in parallel and will pull work from a prioritized backlog. Each team should be led by a Scrum Master or an Agile coach.

Agile metrics are used to measure progress and estimate the remaining effort. Schedule duration can be modified by adding more Agile teams, or by the customer reprioritizing or eliminating features.

Verifying the Schedule and Critical Path:

Verification of an integrated master schedule also applies to the release level of an Agile project. Integration and verification of activities can be determined by using sprint boards which list tasks as “done,” “to-do” and “in-progress.” Burn down charts are used to show a simple representation of remaining work compared to time.

If the high-level roadmap or schedule reflects only the “must-have” features, then the critical path is readily identified and simple to track.

Conducting a Schedule Risk Analysis (SRA):

The nature of Agile is that risks are always being addressed. A traditional SRA can be conducted at the release level, but at the sprint and task level, risks are reviewed via several feedback loops, including scrum check-ins and sprint planning meetings. Customer feedback can be used to resolve and mitigate risks.

The Carnegie Mellon University research document, Parallel Worlds: Agile and Waterfall Differences and Similarities, provides insight into how risk practices are incorporated into Agile project management.

“… Agile is geared towards detecting (flaws in planning) —it is designed to fail early, correct course, learn, and improve. As a simple example, in an Agile program, working software is tested and integrated daily and demonstrated to the user as often as every two to four weeks, which allows for frequent assessments as to whether the program is on track.”

Updating the Schedule:

Release progress can be updated on an integrated master schedule or roadmap. Sprints also use several other tools to track progress including daily standup meetings, burndown/burn-up charts (vertical/horizontal integration) and the number of tasks completed of varying complexity.

Maintaining a Baseline Schedule:

In an Agile project management setting, time is fixed and level of effort is monitored.

At the end of each sprint, data is analyzed to determine if task estimates were under or over estimated. Improvements in the ability to estimate level of effort allows for more accurate planning of subsequent sprints.

A modified version of an integrated master schedule can be combined with Agile methodologies to communicate with stakeholders who may not be familiar with Agile. A schedule can assist in developing cost estimates and visually representing scope through “must have” features in a critical path.

For additional guidance in implementing Agile methodologies, visit our other articles, including Six Best Practices for Agile Strategic Planning.

For readers who would like a guide to key Agile terms, the Project Management Institute publication, Simple Model for Agile Development, provides a straightforward glossary. The Carnegie Mellon University research document, Parallel Worlds: Agile and Waterfall Differences and Similarities, provides a detailed description of difference in terms and concepts between the Agile world and traditional world of project management.

facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmailby feather