How To Share Enhancement Requests

For the fastest response, we recommend you log a support ticket with your enhancement request. Please give us as much of the following information as possible:

  • An overview of the enhancement
  • What kind of users would use the enhancement
  • What business value it provides
  • Why not having this enhancement impairs your use of the system
  • Have you have seen other, similar tools provide the feature (if any)
  • Screenshots and other visual aids for understanding

What Happens Next?

As requests come in from our customers (to support), we check our enhancement backlog in our corporate SpiraPlan. If an enhancement already exists the support technician adds an internal comment with the new information (and ticket details). If it is a new idea, we log the new enhancement directly from our support tool (KronoDesk) into our corporate SpiraPlan. This automatically links the support ticket and enhancement together.

The product team reviews and discusses all new enhancements on a regular basis (weekly). First they makes sure the original enhancement is complete and clear enough, and that it is tagged with the correct Components (e.g. Requirements vs. Planning Board) and whether the feature could be implemented as a SpiraApp.:

Next, they determine the business priority:

  1. Critical
  2. High
  3. Medium
  4. Low

Then they assess the implementation scope and risk:

  • Deep & Wide
  • Tricky or Wide
  • Small Scale
  • Hyper Local

When Are They Implemented?

We get hundreds of enhancements requests each year, and we have a library of existing enhancements that span the past 15 years.

One of our key design/development tenets is that we want to ensure the system is highly usable and has a good overall product design that makes sense. Our product teams work hard to ensure our products have a coherent, simple design and a consistent user experience. Specifically, we want to avoid the dangers of featuritis. (Featuritis is a term used to describe software which over-emphasizes new features to the detriment of other design goals, such as simplicity, compactness, stability, or bug reduction).

For this reason, we don't review all of the enhancements before each release or sprint. This would consume a lot of time and result in a mishmash of enhancements added blindly across each of our products. Instead, based on our own internal agile methodology, we do the following steps:

  1. When planning each release on our roadmap, we identify the 1-2 major planned features.
  2. We search the enhancement database to get a shortlist of enhancements that target the same parts of the system.
  3. We review this enhancement shortlist, including using the priority and severity/difficulty factors, to determine which enhancements make sense to deliver alongside the major feature
  4. In many cases, we do not implement the enhancement literally, but instead use it to inform the design of the wider feature

This process is very important for us to follow. It helps manage function creep within each sprint and release. This is because in each release and sprint we are also balancing the delivery of other important changes, such as security fixes, patches, bug fixes, and previously planned system-wide enhancements that will increase our tool's functionality for the entire customer base.

This means that we will not usually be able to give you a definite timeline for a specific enhancement request.

What About Plugins and Add-Ons?

Our process for adding enhancements to plugins, extensions, and add-ons is approximately the same. For addons we also prioritize enhancements based on the number of customers using the add-on. For example, enhancements related to Atlassian Jira (one of our more popular add-ons) is much more likely to be implemented than one for Bugzilla.

Do We Handle Bugs and Security Issues the Same?

No. Unlike enhancements or change requests, true reproducible bugs or security vulnerabilities are handled differently. Once the team has verified the bug/issue (as part of the product team's regular reviews), we assign it a priority and severity risk, in the same way we do for enhancements (see above).

While it is very rare for an enhancement to be marked as critical, bug and security issues can be. Generally:

  • Critical bugs are patched in either the next release or in an emergency hotfix depending on the severity
  • Bugs/Issues that are considered High will be prioritized to be fixed based on the impact to customers and the severity
  • Medium or Low priority bugs/issues will be handled on a slower time scale, based on their severity/risk.