2021-07-12 Capacity Planning Meeting




Guests: Oleksii Petrenko , Charlotte Whitt , Ann-Marie Breaux (Deactivated)

Discussion items

30 minutes maximumApprovals for R1 2021 Hot FixesAnn-Marie Breaux (Deactivated)

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?

Approved two hotfixes from Ann-Marie.

10 minutes maximumStatus updateReviewed some hotfixes not labelled as approved.

Prokopovych team back-end capacityHolly MistlebauerAnnouncement:  On paper the team has 2.5 FTE BE devs, but in actuality it's more like 1.0 FTE.  This will really impact our ability to fix bugs and develop Karate tests during the Kiwi development cycle.

Holly's reduction to 50% on FOLIO effective after Juniper releasedHolly Mistlebauer

SHORT TERM:  Currently OLE pays for 50% of my time and Cornell donates 30%, for a total of 80% on FOLIO.  My OLE contract was up as of 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.

LONG TERM:  I am entering a phased-retirement on February 1, 2022, when I start working half-time.  This half-time will be spent on FOLIO for one-year, until I retire on January 31, 2023. 

Holly will leave the Capacity Planning Team over the next month–Mike has indicated that the Community Council plans on making changes anyway.  Harry will take over the agendas, meetings on Outlook, etc.

Need BE developer to work on FOLIO-3215Mark Veksler

Request from the Tech Council to find a team that can allocate a BE developer to work on  FOLIO-3215 - SPIKE: Improved Reference data handling during upgrades PoC OPEN

Prokopovych is the logical team, but doesn't have BE capacity (see agenda item above).  What about Vega?  Harry and Mark will discuss this outside of our meeting.

Discuss use of JIRA Issue Type "Bug"

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...

  • 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?