2021-07-26 Capacity Planning Meeting

Date

26-July-2021

Attendees

Khalilah Gambrell	X
Mike Gorrell	X
Hkaplanian	X
Holly Mistlebauer	X
Jakub Skoczen
Mark Veksler	X

Guests: Oleksii Petrenko , Anton Emelianov (Deactivated)

Discussion items

30 minutes maximum	Approvals for R1 2021 Hot Fixes		Questions to answer: What is issue? How many people are impacted? What is effort to fix it? What will it take to test the fix? None
10 minutes maximum	Status update	Oleksii Petrenko and Anton Emelianov (Deactivated)	Iris Hot Fix #3 tickets are closed except for 2 from Thunderjet team. They have said we should not wait for them, so Iris Hot Fix #3 will go public today. The 2 tickets from Thunderjet have been moved to Iris Hot Fix #4 (which has not been planned yet). There are 94 tickets that are P1/P2 with a Release of "R2 2021 Bugfix." Only 13 are still in open state. Still have test cases to complete, and 29 are still unassigned. Many of the teams have less bugs reported this time around.
	Update on Elastic Search	Hkaplanian	Magda is on vacation–back on Monday.
	Capacity on Core: Platform Team	Mark Veksler	Limited capacity will impact our ability to work on Optimistic Locking. Quick fix is to allocate more of Julian's time to Core: Platform Team. Long-term fix is to ask Community to contribute a BE dev for this purpose. Harry & Mike have CC meeting next and will let them know about this. Also the PC.
	LDP App	Hkaplanian	Angela wrote an email about being disappointed that the LDP app didn't make it into the release. She thinks that the freeze dates were not advertised well enough. We also have concerns about including the LDP in a FOLIO release given it is not part of the FOLIO code repository. Harry will construct a response and share it with this group.
	Continue discussion of JIRA Issue Type "Bug"	Holly Mistlebauer	Issues related to what we define as a "bug"... Historically, I have created bugs in situations where I (as PO) made a mistake in a user story by overlooking something or stating something incorrectly. I believe the the PO is part of the dev team, so POs are the cause of bugs too. The devs don't want PO bugs to count against them because they are "graded" based on the number of bugs they have. POs need these to be bugs because only a bug can be part of a bugfix/hotfix release. This issue was discussed ages ago, along with the possibility of making a new JIRA Issue Type for PO bugs. I'm not sure that is the answer. Perhaps we need to stop "grading" the teams on bugs? We have situations where the dev team that caused the bug is not the dev team that fixes the problem. This also counts "against" the dev team that fixes the bug. (See Cate's document) Need to discuss further. Some ideas/questions from last meeting... No public statistics? We don't need to compare teams with stats that have no context. Comparing teams is anti-Agile. Find other ways of measuring team success in a non-public way. Share information about the "spirit" behind the statistics. No intention to shame specific teams. What are we actually doing with statistics? Who is doing something with this information? From today's meeting... Have a collective score–no need to publicly share how other teams are doing. There should not be a comparison made. No need to share the team comparisons at Scrum of Scrums. Each Scrum Master should address issues individually with their team. Other devs and POs don't need to see these numbers.