We have a story where we want to have uniformity across our product suite by using a same jar file across three products. Consider it as an add-on to the original product, and as of today we have different versions for different products, due to Java 8 & Java 11 compatibility concerns.

The customer won't know anything once the feature is done. So they just run the software (3 products said earlier) as usual with the latest version of the add on.

  • Is something a feature only if it is customer facing ?
  • Does a Non Customer Facing Internal update count as a feature too ?
  • 2
    With the exception of a few terms (user story and spike come to mind), most of these terms are arbitrary with different meanings in different places. What do you see as the practical difference between your options?
    – Daniel
    Jul 22, 2019 at 7:47

2 Answers 2



The distinction is largely irrelevant from an agile perspective, but may have other drivers that require you to evaluate and adapt your process. If you must do so, involve the entire agile team.

Analysis and Recommendations

  • Is something a feature only if it's customer facing?
  • Does a non-customer facing internal update count as a feature too?

A "feature" is simply some functionality or behavior of a product or system. From a marketing perspective, features are often differentiators that are only called out when they reach a meaningful threshold of significance to the user or differentiation from competitors. From a project management perspective, though, a feature is simply a shippable increment of functionality.

So, it doesn't matter if an increment is customer-facing or not. All sorts of development work takes place "under the hood," and most customers don't care about internal implementation details. However, that doesn't mean implementation details don't add value, affect system behavior, or improve the product!

With all that in mind, it sounds like your project team is struggling to differentiate between functional and non-functional requirements. In an agile sense, both are features, but the priority and business value of the features may vary based on how the Product Owner views the return-on-investment of project resources (especially time, money, and labor) for each feature.

Your best bet is to work with the Product Owner to understand if you need to make this distinction for the project. If not, forget about it! If you do need to distinguish between these concepts for contractual, political, or other business reasons, then involve the whole agile team to discuss the best way to incorporate that into your process.


You are working on a customer facing feature. It is just that you are replacing a component in the product so that the feature will behave in the same way as before.

If you rolled out the new jar file and then suddenly took it away, what in the product would stop working? That then defines the features that you are working on.

For example, say you were replacing the login component with a like-for-like version that is functionally the same. The feature you would be working on in this situation could be represented by a user story like:

As a user I want to login to the product so that I can securely access my data

Another way to think about is what would happen if you roll out the new jar file and it goes wrong? I'm guessing it would impact on your customers, so it is a customer facing feature.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.