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.
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.

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.
|