Unique field layout based on feature type

As we continue to expand our use of Aha, one issue that has come up is that within a given product, there are different types of work/requirements that require different types of information. We're adding more and more custom fields, and it's starting to get to the point where we have way to custom fields for each feature, and most are unused for any single feature.

One possible solution we've thought of is having a custom field layout tied to a Feature Type, so that when a feature is of a certain type, those custom fields are shown in the UI.

Best case solution would also have the type for a given feature be changeable, with all data retained. So, for example, Type A has custom fields 1, 2, and 3 -- a feature starts as Type A with data in all 3 of those fields, but then evolves into Type B, which has custom fields 4, 5, and 6. at that point it would be great to only show fields 4, 5, and 6 in the Feature UI, but still be able to create reports on types 1, 2, and 3, and also if the type was switched back the Type A, fields 1, 2, and 3 would show up in the UI again with the data intact.

  • Zach Rose
  • Dec 6 2016
  • Likely to implement
Release time frame
  • Attach files
  • Andrew Mackles commented
    December 09, 2016 14:18

    No disrespect ;-) but I'd like to remove the Aha score and Tags field from our feature windows. Is there a way to do this?  We may eventually use Scores but right now it's just confusing folks. Thanks. 

  • Jerrold Emery commented
    June 20, 2017 16:24

    Please find below 2 use cases to support this enhancement:

    USE CASE 1:

    My product has 2 feature types: Functional and Non-functional features.

    My Functional Features need to have fields on them specific to them, for example, my functional feature needs to show a custom field called “Owner”. This field is used to show the Product Owner driving that feature.

    My non-functional feature needs a field called “Architect”. That is the Software Architect responsible for the non-functional feature.

    Yes, I could use a generic field that serves both, but this is just one example. My non-functional features will have very different fields than my functional features.

    Additionally, the two feature types would have a different workflow. For Example:

    Non-functional features will go from “not started”, to “Started” to “code Review” to “complete”

    Functional features will go from “not started” to “in design” to “in development” to “complete”


    USE CASE 2:

    Another example is whether or not the item has User Acceptance Testing and Who that person is. Non-functional requirements will not need UAT or and Assigned Person, I wouldn’t want those fields on those types of requirements if only for the fact that they are just noise.

    While we use Jira to track execution, it serves as a good example.. in Jira, I can create several different types of issues, and those issues have different fields. We have Defect issues and they have certain fields, we have User Story issues that have their own fields, Epics have their own, etc.

    In Aha!, we also have different type of features that are unique in nature, contribute to the same project and product, but have their unique fields because they are in fact, unique.