As a team I want to reuse calculated, custom fields in my grids and reports so I reduce errors from re-entry duplication across reports and contexts.


Why have this feature:
VersionOne and its Analytics functions generate a large amount of valuable information. However, the complex metadata model often makes it difficult for teams to easily access that information. Other than using API functions, one of the only ways to access the information is through Analytics reports. To do so, customers create calculated fields in custom reports' data selectors to access or roll up data. Yet, each custom report is separate, forcing customers to replicate their calculated fields, and so leading to potential errors and sustainment work costs for updates. If calculated fields were also defined as custom fields, they would incur minimal additional data storage impact, and would be reusable across all projects. Performance impact would likely be negligible as most views only pull data in small page sets.


Acceptance criteria:
- Able to add a custom field through admin functions which is a calculation of other fields in the metadata model
- Able to filter on calculated, custom fields in the Lifecycle UI grids
- Able to report using calculated, custom fields in Analytics

Comments

  • Agreed. We have an additional use case for having custom calculated fields through the Admin functions: Our scrum masters benefit from having a single field to hold multiple attributes of the Story and parent feature. Currently we employ governance on the story title (requiring it to contain the feature ID, story #/#, Title, Team, and Split from story # if applicable) I we can get these fields exported through the customize option, but exports from the UI don't produce filterable data. And not everyone is comfortable in Analytics. However, our approach is prone to human error and requires maintenance. Having a single (concatenated) field would alleviate this issue and give our team a more reliable field to search/filter/organize by.