2021-10-08 - Sys Ops & Management SIG Agenda and Notes

"Grooming": Work on Epic(s) and User Stories & Sub-Stories for those

No progress

Bring this to Cap Planning

Harry explained how Cap Planning does its work. Started 2-3 years ago, there was a large issue with novice POs scoping work for development teams (scope was ~80% too large per interval). Harry and Mark Vexler created a massive spreadsheet to organize development teams, epics, etc. to organize bug fixes & feature development, full time & part time, front-end & back-end developers in order to determine the available capacity.

POs started understanding dependencies for new features and were able to prioritize some of the base requirements over the final feature. Formulas in the spreadsheets did the math to estimate what was possible for the next 5 releases based (given an increasing level of uncertainty for far future projections) on all the above development and PO variables.

Harry would review the spreadsheet with POs and help them make difficult prioritization decisions. Estimate accuracy increased over time. As each release went by, POs added to the backlog as new information became available.

Cap Planning doesn't decide "who does what", it helps POs understand what is possible in a given timeframe. Kate and Harry brought in super-imposing priorities to help the project stay on the roadmap and mitigate tunnel vision from individual SIGs on their specific needs.

Haven't done the spreadsheet in 8 months, because there is a new spreadsheet that shows who funds development teams (EBSCO, IndexData, Knowledge Integration, Community Org Developers). There are 3 teams that are "Community Development Teams" DevOps, Core Platform, Prokopovich (formerly Core Functional).

Prokopovich is largely in bug-fix mode due to staffing levels (high turn over of community developers). As a result some of the responsibilities are being moved to the Vega team because they have some additional capacity (but that does move some Vega work back in the schedule). 

EBSCO has contractual obligations to customers, so they are setting the priorities for it's development teams. EBSCO's customer's needs often line up with the community priorities, but not always.

OLE has dissolved and the developers that were part of that have faded, the community funds 1 FTE Developer (decrease from 4 at start of FOLIO). How do we fund developers as a community?

MarcCat project failed to deliver the target functionality, EBSCO contractually owes the features that failed and had to pivot. (Authority record control).

Cap Planning is largely doing release schedules because the Community no longer has Capacity to plan for. Result is that FOLIO is largely market-driven for prioritization.

NFRs can be handled because they are going to hit a critical point, at some point EBSCO may redirect development time towards them.

Roadmap is seen as a "Wish List" from the Community, but might not actually be actionable.

Breaking changes to interfaces result in long release schedules.

===================== End of Meeting =======================

A mega session about technical debt at the next WolfCon

News of the status of the work of the Integrations Working Group (if any)

• Integrations Pain Points Tab Folio Source Data and Integrations

• Migration scripts between FOLIO instances; e.g. circulation rule migration