Enhancement Request Trend
This metric tracks the number of enhancement requests that are received, approved, and closed over time, as well as the number of outstanding enhancement requests.
Main Description

Purpose

Although defects typically indicate a problem with code, in that the software is not working the way it is supposed to according to the specified requirements, enhancement requests indicate that the software is not working the way the stakeholders want it to.  Distinguishing between the two is essential to understanding what corrective action might be required.

The Enhancement Request Trend metric is used to monitor the trend of stakeholder enhancement requests throughout the project lifecycle. When an enhancement request is submitted, it might or might not be approved based on potential impact to the project schedule. Therefore, the team must investigate the criticality of implementing each request as well as the impact on the project schedule if the request is approved.

This metric helps the team adjust the project plan and details, such as the iteration plan, as enhancement requests are submitted.

Definition

  • Total number of submitted enhancement requests
  • Total number of approved enhancement requests
  • Total number of resolved enhancement requests

A good way to monitor Enhancement Request Trend over time is to use a trend line. The number of enhancements is plotted on the Y axis, and the iterations are on the X axis. It can be useful to categorize the requests by criticality (low, medium, high).

Analysis

Using Enhancement Request Trend to monitor project execution

Enhancement requests are expected during the lifecycle. They indicate that the team has communicated with the stakeholders and that feedback has been received for improvement.

Enhancement Request Trend is used as a project execution metric to help a team monitor and steer its project performance. As enhancement requests are tracked, trends are identified to help the team understand whether they are delivering what the stakeholders need and expect. If the number of enhancement requests is too high, without indications from trends that the number is decreasing, the team can take appropriate corrective action.

Expected trend - Ideally, the number of enhancement requests is low throughout the lifecycle or decreasing as the project progresses. This indicates that stakeholders are receiving expected value from iteration to iteration as the team delivers working software.

High number of enhancement requests throughout the lifecycle - A high number of enhancement requests can indicate that there is a high risk of requirements churn, or that there are issues with the understanding of project requirements among stakeholders, or between stakeholders and the team. Ensure that the team is releasing working software in each iteration, requesting feedback, and taking action on that feedback. Collaborate with stakeholders to clarify and refine requirements in order to ensure a shared understanding. This trend can also indicate that management and/or stakeholders required detailed plans at project initiation instead of performing high-level planning followed by detailed iteration planning as the project progresses.

Dramatic increase at the end of the lifecycle - This trend can occur when stakeholders are not providing regular feedback to the team, and wait until the end of the lifecycle to review the solution. It can also occur when the team waits until the end of the lifecycle to address high risk items, not allowing enough time to clarify or resolve open issues. When this occurs, collaborate with stakeholders to prioritize remaining features and requests. If the number of enhancement requests is higher than can be addressed in the current release, postpone all non-critical requests to the next release.

The following graph shows an example of Enhancement Request Trend monitoring by iteration.

Enhancement Request Trend

The chart below is an example of Enhancement Request Trends chart from IBM® Rational® Insight®. In this chart, the high number of enhancement requests is at the bottom represented by the red column, medium in the middle with the yellow column, and low at the top with blue column.

 Enhancement Request Trend Report

Using Enhancement Request Trend to monitor capability improvement

Enhancement Request Trend is also used as a capability improvement metric. It helps a team and middle management (project manager, product owner) monitor improvements made during the project lifecycle in adopting the Release Planning practice.

If teams are successfully adopting this practice by creating a strategic release plan as well as tactical iteration plans within each release, and updating plans as often as necessary to reflect changing business priorities and needs, that will be reflected in their Enhancement Request Trends. Operational executives can also use this metric to monitor systematic improvement in increasing value across the organization by adopting this practice.

Expected trend - Projects will have a low number of enhancement requests, that decrease as the project progresses.

High number of enhancement requests - If projects routinely have a high number of enhancement requests, ensure that management and stakeholders are not requiring teams to produce detailed project plans and specifications up front. Emphasize best practices of Release Planning to balance high-level and just-in-time low-level planning.

Frequency and reporting

Data is collected throughout the lifecycle as requests are submitted, approved, and resolved. The resulting Enhancement Request Trend chart is shown by a team lead or project manager for review by the team and stakeholders at the end of each iteration to help identify trends and to take action based on findings.

Enhancement Request Trends for multiple projects can be rolled up quarterly in order to monitor improvement across the organization.

Collection and reporting tools

IBM® Rational® ClearQuest® collects enhancement requests.

IBM® Rational® Insight® reports on this metric.

Assumptions and prerequisites

  • Enhancement requests are submitted by using a consistent and well-defined process, using a tool that is easily accessible to stakeholders
  • The product owner maintains a product backlog that is prioritized and updated as necessary to reflect changing stakeholder needs and priorities
  • Release planning creates a coarse-grained, high-level plan, with low-level plans defined for each iteration
  • Working software is delivered in time-boxed iterations and frequent stakeholder feedback is received

Pitfalls, advice, and countermeasures

  • It can be difficult to distinguish between defects and enhancement requests. Nonetheless, it is important to draw the distinction in order to determine what is taking up more of the team's time, so that you can take the appropriate corrective actions. If there are too many defects, the team might need to implement more automated testing, adopt test-driven development, or devote more time to peer reviews. If there are too many enhancement requests, the team might need to do a better job of eliciting requirements or requesting stakeholder feedback. Often, the development team becomes frustrated when requests are filed as defects that they believe are actually enhancement requests. They feel that it reflects poorly on their work, as opposed to simply being a new requirement. However, the customer is not as concerned with the distinction. To them, both types of requests represent work that must be done to satisfy their needs.
  • Consider project size and effort when determining if there are a high number of enhancement requests. Base your targets on previous successful and troubled projects.
  • If the project consistently has a low number of enhancement requests logged, use the Customer Satisfaction metric as a countermeasure. Stakeholders might not be submitting enhancement requests, but may be voicing concerns in feedback surveys.