/
2021-06-07 Capacity Planning Meeting

2021-06-07 Capacity Planning Meeting

Owned by Holly Mistlebauer

Date

7-June-2021

Attendees

MembersAttended
Khalilah GambrellX
Mike GorrellX
Harry KaplanianX
Holly Mistlebauer
Jakub SkoczenX
Mark Veksler

Guests: Ann-Marie Breaux (Deactivated), Oleksii Petrenko, Marc Johnson Anton Emelianov (Deactivated)


Discussion items

Time

Item

Presenter(s)

Notes

30 minutes maximum

Approvals for R1 2021 Hot Fixes

Export Manager - health checks (Khalilah)

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.

Khalilah Gambrell

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?

Addressing Quality Debt – URGENT!!!

Anton Emelianov (Deactivated)

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://folio-org.atlassian.net/secure/Dashboard.jspa?selectPageId=11817
  2. https://folio-org.atlassian.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://folio-org.atlassian.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://folio-org.atlassian.net/browse/UXPROD-3082 and https://folio-org.atlassian.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

Discuss what is going to happen next with optimistic lockingJakub Skoczen

At the May 24 meeting we decided there would be an update on the progress of optimistic locking work. This "feature" is one of the highest pointed "features".

Charlotte: Inventory work (started in R2 2021): UXPROD-3089 - Getting issue details... STATUS


Holly's reduction to 50% on FOLIO effective August 1, 2021Holly MistlebauerCurrently OLE pays for 50% of my time and Cornell donates 30%, for a total of 80% on FOLIO.  My OLE contract is up on June 30, 2021, and it appears that it will not be renewed.  Cornell has agreed to donate 50% of my time to continue on FOLIO, but aren't in a position to donate the full 80%.  I will not be able to keep all of my current responsibilities at 50%, so I will need to give up some things.  I want to determine what the project needs me for most, with help from this group.

R3 2021 Kiwi timeline

Oleksii Petrenko

Kiwi (R3 2021)

R2 2021 Juniper Feature freeze overdue 

Oleksii Petrenko

Related content