2021-07-19 Capacity Planning Meeting




Guests: Oleksii Petrenko

Discussion items

30 minutes maximumApprovals for R1 2021 Hot Fixes

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 MODORDERS-542 and MODINVSTOR-744 as a last minute addition to the R1 2021 Hot Fix #3 release.

10 minutes maximumStatus update57% of test cases have been passed.

What should BE devs on Prokopovych focus on for Kiwi?Holly Mistlebauer

As mentioned at last week's meeting, the Prokopovych team has 2.5 FTE BE devs on paper, but only about 1.0 FTE in actuality.  We need to focus our limited BE capacity on what is most important.  Aside from critical bugs that pop up with Juniper, what should we focus on first?

  • UICHKOUT-726 (SPIKE: Improve check-out speed) – this is a P2 because you are able to check-out items, but it takes too long - starting ticket is CIRC-1181 (Research checkout speed)
  • UICHKIN-269 (SPIKE: Improve check-in speed) – this is a P2 because you are able to check-in items, but it takes too long - starting ticket is CIRC-1182 (Research check-in speed)
  • Karate tests

(Note:  Code freeze for Kiwi is in less than two months, on September 17th.)

Creating Karate tests is important, but we really need to figure out how to improve performance with checkouts and check-ins.  It is summer now, so performance will get worse when the fall semester starts.   The likelihood that we will have a long-term fix in place by then is slim, but we need to start on this ASAP.  

The team is focused on fixing P1 and P2 BE bugs right now.  We will see if another team can donate a BE dev with circ experience to work on bugs while our BE dev focuses on this research. 

We will start with checkout given patron is standing at the circ desk waiting (while check-in is usually completed without the patron standing there). Our person should work with Martin.  We should define both short-term and long-term solutions. 

Need to include test where data import is occurring while doing checkouts and check-ins. 


Charlotte Whitt

Planning roll out of implementation of Elasticsearch in Inventory - timeline: Lotus? 

The current technical approach for search in Inventory is using PostgreSQL, JSONB columns, CQL and RAML Module Builder. Using Elastic Search as a long term solution has been explored Autumn 2020 - Spring 2021 (POC). We should now plan for when to swap the current solution and use Elasticsearch in production. 

Harry will talk to Magda and Khalilah about the long-term plan and how to research it.

Hold for next week–ran out of timeContinue discussion 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/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.
  • Share information about
  • What are we actually doing with statistics?  Who is doing something with this information?