| # | Jira Key | Severity | Done | Chart | Issue Summary | Notes |
|---|
| 1 | LACE-3168 | High | Done | Features started and closed by PI | Closed Issues count w/in PI are wrong | Closed Issues measure calculates cumulative results, rather than closures w/in the PI date boundaries |
| 2 | LACE-3766 | High | Done | All Reports using PI date measures | Minor differences in issue counts | EazyBi Standard measures results differ from Jira Queries |
| 3 |
| Medium | Done | Features in Status by PI | Time Member Lags by one period | When Using the PI Start Date Measures For Open Issues measure(and presumably all other counts), the implementation numbers are correct but show the value from the previous PI for each PI on the chart |
| 4 |
| Medium | Done | All Reports using PI date measures | Eliminate Custom Start date and PI Measures | Identify a solution for getting PI Start/End date from Jira and eliminate program specific custom measures. EQRS creates a releases for each PI.(fix version Start date measure) Need to find out what other programs are doing |
| 5 |
| High | Done | All | Programs have inactive teams | Inactive teams forces us to select individual team projects, requiring maintenance (removal or addition of projects) to the data import to maintain accurate issue counts for charts aggregating data from all program teams. Project Categories could be used or Project Labels (if they exist)
We are using project categories now, which works when ONLY the projects for the active teams are included in the import AND Categorized. Refer to line 14. |
| 6 |
| Low |
| Cumulative Flow | Time Period changes with PI selection | Should show a 12 month window. Because time is in Rows, its taking the value from the time dimension current member selection. We cannot use the 12 month time dimension member because PI selection is a common page element. We need a custom measure (in measures dimension) to fix 12 months |
| 7 |
| Medium | Done | Features Started and Closed by PI | Removed Issue Histories Closed Line | The red line shows cumulative issues count, which is not particularly valuable and creates confusion. This will require a customized measure |
| 8 |
| Low |
| Program backlog health | Aggregate statuses | The statuses are individually selected and there are more statuses that include items in the New to ready status domains |
| 9 |
| Medium |
| 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 |
ISG Playbook
APIs