| All | Granular aggregate statuses | We have aggregated all statuses into the proposed user story workflow statuses, but to provide more granular reporting on program backlog, we may need specific aggregations to support more awesomerness |
10 |
| Low |
| Program Wide Backlog composition | Random issues not showing in EazyBI but in Jira Validation Query | Issues EQRSMD-12, EQRSMD-20, EQRSMD-32, EQRSPRTL-46 are not showing up in Eazy but show up in a Jira validation query. EQRSMD-12, EQRSMD-20, and EQRSMD-32 were migrated from a different project and changed from task to a story, but EQRSPRTR-46 has no anomalous history changes, but was resolved on the day of the report |
11 |
| Medium |
| PI over PI Program Backlog Composition | Suggestion for new chart | Given: As a system matures operational spend should reduce allowing more capacity for feature based user enhancements. Should we have a bar chart that shows same data as Current Program Backlog Composition PI over PI? |
12 |
|
|
| Current Program Backlog Composition | Possible enhancement | Can we enhance Exploration Enablers to create new measure combining label and feature name search? |
13 |
| low | Done | Date formats not portable between EazyBI and JQL | Makes it harder than needed for validation | We updated these to match in EazyBI and the put the correct formats into the Validation Queries page |
14 | QNASK-8375 | High | Done | Verify with RTEs its ok to remove defunct teams from project categories |
| I have received permission from RTEs in HQR and iQies to remove defunction teams from the project categories, and a Jira ticket has been submitted to do any addition/removal of teams from those categories |
15 |
| High |
| Issues tagged with more than one enabler type are counted twice |
| The resolution conversation is that since the RTE's are moving to the new enabler labelling schema, that we wouldn't bother finessing the measures to account for this scenario, BUT, the RTE's have been slow to apply the schema, so we are still seeing expected variances in the counts based on this condition. Brandy Barnette we should discuss |
16 | LACE-3553 | Med |
| Cycle Times | Cycle times report needs to use pre-calculated time boundaries | We need to look into managing PI's with custom time hierarchy. |
17 | LACE-3766 | High |
| Features Started and Closed in PI | Issue with PI boundary conditions | It is evident that work from prior the prior PI is being updated in the first week of the subsequent PI. Using the PI end date as a hard cut-off is leaving out some 'Done' work. If you look at the JQL below you can see may features that were set to Done on 7/6 and 7/7. These features were worked on in the prior PI (PI18) but are being counted in the Done features for PI 19. We need to find the best way to capture completed work. Should we use a combination of PI selectors (fix version or label)? JQL: Project = " End-Stage Renal Disease Quality Reporting System" AND issuetype = 10000 AND status changed to Done during (2022-07-06, 2022-09-27) ORDER BY resolved ASC |
18 |
| Med |
| Features in Status on PI start Dates | Missing story definiton status for iQies | need to add "story definition" status to capture iqies features |
19 |
| Med |
| Cumulative flow | statuses do not match program status |
|