Page Comparison

Approvals for R1 2021 Hot Fixes

Export Manager - health checks (Khalilah)

• https://

• folio-org.

• atlassian.

• net/browse/MODEXPS-12 

• (approved) 
•  https://

• folio-org.

• atlassian.

• net/browse/MODEXPW-9 (approved)

SRS Query API (MODSOURCE-265) (approved)

Data Import (Ann-Marie) See Ready for CPT section of https://

folio-org.

atlassian.

net/secure/Dashboard.jspa?selectPageId=11810 

SRS.

Questions to answer:

1. What is issue?
2. How many people are impacted?
3. What is effort to fix it?
4. What will it take to test the fix?

After the discussion at the Cap Planning meeting, I (MV) suggest for Anton to present at the key venues, such as Scrum of Scrums, PO meeting, Tech Council, Product Council.

1. Quality memo from Anton:
2. Allocating % sprint capacity for technical debt didn't work because very little progress has been made. I have dashboards to prove it:

1. https://

1. folio-org.

1. atlassian.

1. net/secure/Dashboard.jspa?selectPageId=11817
2. https://

1. folio-org.

1. atlassian.

1. net/secure/Dashboard.jspa?selectPageId=11818

1. That being said, UXPROD testing features should be estimated and assigned to a release and they should be treated equally as functional features. If they are not included into release they'll never get done. If they are rolling from release to release they'll never get done either. For example, instead of having https://

1. folio-org.

1. atlassian.

1. net/browse/UXPROD-2697: Karate  it should be Karate R3 with concrete list of testing stories assigned to both R3 release and this feature. @kg did it right for https://

1. folio-org.

1. atlassian.

1. net/browse/UXPROD-3082 and https://

1. folio-org.

1. atlassian.

1. net/browse/UXPROD-3094.
2. Story points for UXPROD testing features should represent % of total capacity for a dev team. This % should be defined by Capacity Planning for each team individually. According to a number of defects the team generates historically from release to release. 
3. For R3 prioritization purposes, testing features should focus on modules that produce the highest number of defects. Here is the dashboard to illustrate the point.
4. Testing work can take lower priority for modules that are stable and don't produce a high amount of bugs.
5. UI modules should focus on RTL/Jest migration first and E-2-E Integration tests second.
6. BE modules should focus on Karate tests.
7. Regarding UI E-2-E testing - each team should complete a spike in R2 (see the top widget) to be able to estimate work to create E-2-E tests in R3