Time to Delivery
Metrics for monitoring a project's Time to Delivery status, and a sample dashboard
Relationships
Main Description

Overview

Time to Delivery is the length of time it takes from initiating a solution until it is considered valuable to stakeholders. Time to Delivery metrics help a team monitor how well they are progressing at delivering value against the schedule. Metrics in this category enable a team to determine how much time is needed to complete the project (delivering the value that stakeholders need and expect), and can signal a potential for delays.

Time to Delivery status requires knowing:

  • How much work is left to do?
  • How fast is the team working?
  • When will we be done?
  • How much scope is changing?
  • How much rework is happening? *
  • How much do we expect scope, velocity, or staffing to change? *

* Likely not calculated, but should be considered when analyzing Time to Delivery metrics


Time to Delivery Metrics

The following metrics can help a team determine their Time to Delivery status:

Core Metrics

  • Release Burndown tracks the estimated functionality yet to be implemented for the current release, along with changes in scope. Analyzing a Release Burndown chart helps determine how much functionality the team is creating compared to how much they promised to create.
  • Iteration Velocity measures the pace of the team. It indicates how much work a team can complete in an iteration by tracking how much work it has successfully delivered in past iterations. Note that instantaneous velocity is visible in a Release Burndown chart by viewing the difference in points remaining in the last two iterations.

Together, Release Burndown and Iteration Velocity help a team predict their end date by calculating how many iterations are required to complete the backlog. Is the project on track? Or, is there a need to de-scope in order to complete the work on time?

Supplementary Metrics

  • Points are a measure of magnitude for the project. They can be user story points, use case points, or function points.  As points are added or removed from the project, the team should monitor impact to the schedule. Points can be tracked in Iteration Burndown and Release Burndown.
  • Blocking Work Items are work items that are blocking the team from making progress. Tracking this metric can help the team identify road blocks and focus on removing them so that they can move forward with as little impact to the schedule as possible.
  • Requirements Churn tracks the number of changes to system requirements. High levels of churn (especially at the end of the lifecycle) can seriously impact project schedule.

Reporting Time to Delivery Project Status in a Dashboard

The following examplary dashboard represents one way to calculate and report Time to Delivery status. Teams can substitute metrics that are already in place and used successfully in their organization for a custom Time to Delivery report.

Produce this dashboard by harvesting metrics data and populating a spreadsheet.  Generate the dashboard report using charting capabilities of the spreadsheet tool. Or, the team can use the spreadsheet as a data source and create a custom report in IBM® Rational® Insight®. Over time, IBM® Rational® Insight® will provide such dashboards as out of the box reports.

To assess a project's Time to Delivery status, the following inputs are required (provided by the Time to Delivery core metrics and team-specific variables):

Value
  Description
COMMITTED_END_DATE Date the team committed to finish the project
VELOCITY Points delivered in the last iteration
ITERATION_LENGTH Number of days in the iteration
ITERATION_END_DATE End date of the last iteration
TOTAL_POINTS Total number of points the team committed to deliver
ACCEPTABLE_DATE_TOLERANCE Defined in days. Used to establish an acceptable range of minimum to maximum days outside of the committed end date.

Use the inputs above to calculate the project end date:


END_DATE = ITERATION_END_DATE + (TOTAL_POINTS / VELOCITY) * ITERATION_LENGTH


Time to Delivery dashboard status is calculated as follows:


Status
Definition
                                     Actions to Take
RED

END_DATE > COMMITTED_END_DATE + ACCEPTABLE_DATE_TOLERANCE

The projected end date is beyond the committed end date plus the allowable variance in days.

The following actions can be taken to increase the likelihood of meeting release date commitments:

  • Reduce scope for the release. Review the backlog with stakeholders and defer lower priority functionality to a later release.
  • Increase velocity by adding additional staff. However, new team members have a learning curve so, in the short term, you may see velocity decrease as existing team members devote time to getting new staff up to speed.
GREEN

END_DATE <= COMMITTED_END_DATE + ACCEPTABLE_DATE_TOLERANCE

The projected end date is earlier than the committed end date plus the allowable variance in days.

Good job! The project appears to be on or ahead of schedule.  Confirm that stakeholder satisfaction is high and that they are happy with the scope.  Continue to monitor Time to Delivery status at the end of each iteration for any change.
YELLOW

Status is red, but we have a plan to address the issue

Analyze Time to Delivery metrics to determine the causes for the unexpected schedule variance. Collaborate with stakeholders to determine what actions to take and create a plan to address the issues. Follow the plan and monitor progress in each iteration until status is green.

Consult the Time to Delivery Value Traceability Tree to help identify strategies and solutions to improve Time to Delivery.

Note that this calculation provides dashboard status for a single release only.


Considerations

Beyond the basic Time to Delivery calculations, the team must consider the following questions to more accurately determine their completion date.


How much is scope changing? Is new work is being added? Analyze Release Burndown for past iterations to understand the amount of new work added. You may find that the team has an average velocity of 30, but only a backlog reduction of 18 points, because they added 12 points worth of scope. In this case, the team's net velocity is only 18.  If scope continues to grow beyond the team's capability to complete work, the schedule will be impacted.

How much rework is happening? How much re-estimation is happening?

Defects and resulting rework can negatively impact the schedule. With no rework, impact to the schedule is zero. As you approach 100% the impact grows to infinity and the work cannot be completed. Note that if no rework is happening, the project is either about to release (no cause for concern), or the team may not be testing or evolving the requirements.


Re-estimation must be taken into account when predicting an end date. This happens when:

  • The team learns more about a work item
  • There is instability due to high risk or some uncertainty
  • The team realizes they know less than previously thought about some aspect of the project
Will There be Staffing Changes? Use this information to assess likely changes in velocity.
Do you have work that is unaccounted for?

Examples include:

  • Required architectural rework
  • Defects that have not been accounted for in your backlog
  • Poor implementations (such as lack of usability) you feel need to be addressed

Accounting for these items in the backlog will help the team better calculate expected completion time. You may also need to account for one or two extra iterations to harden your application, based on specified quality requirements.


Pitfalls and Countermeasures for Time to Delivery Metrics

Delivering on time as criteria for success can be misleading. The team can meet the schedule to the day, but if the product is missing half of its expected functionality it might not be successful. It is important to analyze the suggested countermeasures for each core Time to Delivery metric to confirm they are driving the correct behavior.