How-to Handle Enhancements

A work item of type "Bug" can be used to suggest an enhancement, something that is not a real defect, but an idea for improvement. This guide describes how to handle enhancements as bugs.

Together with other bug-related guides, it provides information to help ensure correct handling of all types of bugs. It relates to PCP R&D’s overall bug management process, described in How-to Manage Bugs, as visualized below.

There are two origins of enhancements as bugs:

• When the change control board (CCB) recognizes a reported bug as an enhancement.
• When it for some reason is not possible to create a new feature of a good enhancement idea.

Note: Remember that all bugs (including enhancement bugs) must be deferred or closed at the end of the project, see How-to Handle Deferred Bugs.

You find further information and a Q&A about enhancements as bugs under Details.

Intended for

Configuration managers, release owners, product owners, quality control managers, test engineers, and hardware engineers.

Activities

Create a bug of an enhancement idea

(This step is only valid for the case when it is a conscious choice to create a bug of an enhancement idea.)

When creating the bug, state clearly in the description that it is an enhancement idea and the reason to why it is not possible to create a new feature as preferred.

Recognize a bug as an enhancement

After the definition of ready (DoR) is checked, the CCB decides about the bug.

If the issue reported in the bug is recognized not as a defect, but as designed or as an improvement idea, the CCB can decide to consider the suggested enhancement to improve the product. The CCB records the discussion in the bug.

Bug to feature

The product owner closes the bug with reason “As Designed” in agreement with the CCB. This reason will make sure that the bug work item is not counted as a defect in KPIs.

Then the product owner creates a new feature and links it to the bug. The feature should contain a re-elaborated description of the enhancement idea, sufficient for a feature.

The recommended link between the original bug and the new feature is “Related”. A team can adopt a different convention if desired, but it’s best to avoid parent/child or predecessor/successor as they could impact visualization in “Boards and Delivery Plans” in Azure DevOps. The link is needed only for reference purpose, the link type is not used in KPIs.

Note: Important - work item hierarchy

Each feature must have an epic as its parent. Assign an epic as parent of the new feature if a good match exists in state “New” or create a new epic as parent.

Do not break DoR/DoD (definition of done) rules: if an epic is already “Active”, do not add more features. The reason is that if more and more features are added to an epic that is “Active”, it will be very difficult to complete the epic. When the feature is added to an epic, the estimation needs to be updated. It is not necessary to invest much time to make a first estimation of the feature, a high-level estimation is sufficient at this point and can be refined later when the DoR is checked.

For example, when a new feature is created:

• If an epic already exists that is a good match and is not started yet, add the feature to the epic and update the estimation of the epic.
• Otherwise, create an epic to contain the feature and possibly group features from enhancement ideas in bugs. Testing the epic in this case is less meaningful, there may not be test cases associated directly with the epic, since it may contain unrelated features, so testing is performed at feature level and the parent epic can be closed when all features are closed.

Feature to completion

After the feature has been created, it follows the lifecycle of any feature, with its decision making, planning, change management, validation, etc. For example, if someone wishes the feature to be added to an ongoing release, it has to go through the change request process, it will not be automatically added to the scope.

Details

About enhancement as bugs

Enhancements as bugs are precious, as they are a way to understand the expectations of users and to capture ideas to improve our products. They can relate to existing or new functionality, and a bug work item created post release can be an enhancement too.

However, such enhancement ideas need to be evaluated and planned and they can have an impact on for example existing functionalities, release schedules, resource allocations, quality, like any other changes.

Enhancements as bugs should not be used as a way to bypass change requests, CCB decisions, requirements processes or to manipulate bug KPIs. If these processes were bypassed, there would be a high risk of feature creep, resulting in delay and poor quality to try to do too much in an uncontrolled way.

For this reason, if an enhancement idea coming from a bug is thought valuable by the product owner and the CCB, it is managed as a new feature. The following flow chart illustrates the origin and outcome of an enhancement as bug, and the table below gives examples of what is considered enhancements and not.

Enhancement	NOT an Enhancement
Suggestion to improve the user interface.	User interface does not work as designed.
New functionality or robustness improvement related to an existing functionality.	Defect with low severity.
Cosmetic improvement.	Change request for an ongoing release.
The bug creator thought it was a real defect, either found internally or created as a L4 bug, then it was recognized as an enhancement.	Real defect, hidden as enhancement bug to influence KPIs.
The bug creator had an enhancement idea and wanted to capture it and submit it.	Defect that the CCB has decided to defer or not to fix at all.

Q&A

Question	Answer
What is the severity of an enhancement as a bug?	The perceived severity when opening the bug does not matter. An enhancement as a bug is as designed, it is not a defect.
What if a bug that is possibly an enhancement is very small and a feature seems too big to manage it?	When the CCB evaluates the bug work item, the CCB can decide to accept it as a defect, most likely a bug with low severity, and to process it with other bugs. In that case it contributes to bug KPIs and it is not considered an enhancement. This choice may be controversial, and the CCB should consider the size, effort, impact and risk with respect to the planned scope and commitments.
Does the severity of enhancements as bugs affect KPIs?	Bugs closed "As Designed" do not contribute to defect KPIs.
How to propose an enhancement as a bug as a change request for an ongoing release?	Follow the steps under Activities, then open a change request for the new feature to be added to the scope.
What if the enhancement as a bug is a very big functionality or requires major changes?	If the idea is very valuable and a feature is too small, the new requirement may be managed as a new epic instead and follow the epic processes.
Do we need to reach out to the CCB / product owner before creating the bug?	Yes, it is recommended and in that case the product owner can define a feature directly instead of a bug.
Who raises an enhancement as a bug?	Any team member who is directly or not directly connected to the product and wants to contribute is welcome to propose ideas. Typical roles: software engineer, hardware engineer, test engineer.
Can an enhancement as bug be deferred?	The bug must be closed before the end of the ongoing release. If it is recognized as an enhancement, it is closed with reason "As Designed". The linked feature is prioritized and planned like other Features, so it may or may not be included in the same release as decided by the CCB. If the bug is accepted as a real defect and not an enhancement, it must either be fixed or deferred or rejected before the end of the ongoing release.
What is a negative consequence of creating more enhancements as bugs instead of features?	It may take more time to analyze bugs and fix them, because of the "noise" created by enhancements as bugs. Instead, features can be processed directly as new ideas and will not steal time from bug analysis and bug fixing.

References

• How-to Manage Bugs
• How-to Handle Deferred Bugs