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.