PPM and Agile Mythbusting Part 2: Debunking Common Fallacies About Agile Projects

From the The Business Driven PMO Blog
Stories from the trenches and practical advice on how PMOs can more effectively support, prioritize and fund strategic business initiatives.

About this Blog


Recent Posts

What’s So Bad About Spreadsheets?

Top Five PPM Trends to Watch Out For in 2014

Insights and Trends: Current Project Portfolio Management Adoption Practices

Life after project completion: Is a project complete without benefits realization?

How Important is Adoption for a PMO?

In my last post, I busted a common misperception that agile projects don’t provide enough executive visibility. Today I’m going after a second widely-perceived myth: Agile Projects Lack Reliable Scheduled Finish Dates.

It’s a fact that agile methods are designed to adapt quickly to changing realities, whereas more traditional methods focus on planning the future in detail. Although agile teams shy away from providing guaranteed delivery dates (given the cone of uncertainty around a project), it’s untrue that an agile project can’t provide a scheduled finish date.

Agile teams use ‘just-in-time’ estimation for iterations and focus on delivering business value incrementally. However release and roadmap planning is used for longer range estimates. If an executive hears that an agile team is only prepared to give estimated delivery dates for the next couple of iterations, it should raise a warning flag about the team’s capability to build a credible release plan.

The use of ‘epics’ (large stories) and ‘themes’ (groups of stories) can be used to estimate work that still requires detailed scoping. To be able to estimate with some degree of reliability, an agile team will need to have some degree of normalization around the size of stories and understand their velocity (story points delivered in an iteration).

Once the differences with agile projects are understood, developing a PPM framework with standard metrics that apply to both agile and traditional projects is important. Scheduled finish date is just one of the five common metrics that enable executives to get visibility into project status, regardless of the delivery method:

Scheduled Finish Date. ‘Planned finish date’ is the estimate made at the inception of a project for the planned delivery date, whereas ‘scheduled finish date’ is the estimate of a project finish date at any given point in time based on current data. For a traditional project, this is based on the task plan and critical path for the project. For an agile project, it is based on the release plan. Given a ‘cone of uncertainty’ exists regardless of project methodology, the accuracy of scheduled finish dates should be comparable for both traditional and agile projects. Comparing scheduled finish date to planned finish date will give an indication of the team’s ability to estimate delivery dates accurately.

Percent Complete. Percent complete provides an indication of project progress. Percent complete for a traditional project is calculated by summing the hours for completed tasks and dividing by the total task hours for a project. In contrast, an agile project progress is measured by story points delivered. Percent complete is calculated by story points accepted divided by total story points for a project.

Scope Changes. Percent complete gives an indication of progress, but does not show if the scope is changing on a project. For traditional projects this is typically represented by the number of change requests. For an agile project, it is typically measured by the change in total story points over time.

Actual Cost vs. Budget. Both traditional and agile projects have capital and operational expenses that are tracked. Actual cost vs. budgeted cost should be reported, regardless of the project methodology.

However, it’s not appropriate to ask an agile team to track time at a task level to calculate resource costs. Instead, resources should be dedicated to an agile team and costs calculated accordingly.

Project Health. Project health is a summary metric that indicates if a project is ‘on track’, ‘needs attention’ or is ‘in trouble’, usually indicated by Green, Yellow, Red stoplight colors. This metric varies by organization and is often calculated using conditional logic based on the four metrics above, as well as other data such as outstanding issues. One of the simplest ways to calculate project health is to compare actual percent complete with the expected percent complete based on the start date and scheduled finish date (assuming the velocity of work delivery across the project timeframe is uniform). A project health status of ‘needs attention’ or ‘in trouble’ is often triggered when projects are not delivering business value, there are significant scope changes, costs exceed budget or there are major unresolved issues on the project.

Providing these metrics in a dashboard format using a PPM system enables executives to quickly identify projects that require focus or intervention, regardless of the project management methodology employed for its execution.

Do you agree? What’s worked for your organization and what’s fallen flat on its face? Let us know here. 

Posted on: August 01, 2011 02:08 PM | Permalink

Comments (0)

Please login or join to subscribe to this item

Please Login/Register to leave a comment.


"The brain is a wonderful organ. It starts the moment you get up and doesn't stop until you get into the office."

- Robert Frost