Skip to end of banner
Go to start of banner

2021-06-07 Capacity Planning Meeting

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Date

7-June-2021

Attendees

MembersAttended
Khalilah Gambrell
Mike Gorrell
Harry Kaplanian
Holly Mistlebauer
Jakub Skoczen
Mark Veksler

Guests:


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)

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