Backlog Grooming Sprint 52

Owned by Sam Im (Deactivated)
Last updated: Nov 13, 2018 by Nikodem Graczewski (Unlicensed)

Goal: Release 3.3

Dates:  -  

Next Steps for Team Parrot

  • Team Parrot will start Sprint 52, but will focus on fixing the performance issue for single approve, and performance testing for convert to order. The main goal is to demonstrate/repair that we have NOT degraded in performance. 
  • No new ticket work will start until we fix performance. (Except for Jakub - more details below.)
  • Sprint Q&A: Team Parrot will discuss the performance testing results and day's status.

Performance Testing & Resolution:

  • Single approve - the fix doesn't quite get us to the performance guidelines. What else could we do?
    • Our baseline for single approve is ~20 seconds overall, so that is what we are aiming for in order to say we have comparable performance. looking at the 3.3.0 numbers, our median value looks to be about ~40 seconds before any fix, so in order for us to get down to ~20 second baseline, we need to reduce by about 15-20 seconds, meaning the “fix” should ideally get down to the low single digits
    • Any solution will require a regression of all requisition test cases (and maybe convert to order).
    • Research, collect and record results. Solutions to single approve performance should be reviewed by Sebastian. The goal is to match the baseline or increase performance without impacting too many services which would cause more regression testing.
  • Convert to order - We need to prove we didn't degrade in performance.
    • Everyone needs to test and update performance page with results (testing one convert to order, multiple (8 to compare to baseline) convert to orders, multiple times)
      • 3.2.1 baseline for convert to order:
        Convert 8 requisitions: 20s (POST /convertToOrder 15s, GET /requisitionsForConvert 2s)
        Convert 1 requisition: 6s (POST /convertToOrder 3s, GET /requisitionsForConvert 2s)
    • Once we do some testing and get several more data points, then analyze if performance has gotten slower and if so, what is causing it
    • Analyze convert to order logic and determine solutions to speed it up. Solutions to convert to order performance should be reviewed by Sebastian. The goal is to match the baseline or increase performance without impacting too many services which would cause more regression testing.
  • Additional notes:
    • Sebastian Brudziński - one thought could be to make supply line configuration change for supervisory nodes (which we recently did for Malawi) in perftest. Do we think that may have an impact on the performance results in perftest when comparing to our baseline?
    • Sebastian Brudziński - an option is to spin up a 3.2.1 server with same MW perftest data to be able to compare with 3.3 perftest for the convert to order (Chongsun writes up instructions on how and why)
      • Only if we don't get consistent results on 3.3 perftest
      • If we don't get consistent results, then we can try to see if we don't get consistent results on 3.2.1 perftest, and if so, we can say we didn't degrade because there is no consistent baseline for 3.2.1
    • Jakub Kondrat can move forward with creating tickets for  OLMIS-3498 - Getting issue details... STATUS  and replicating to other services.
    • Chongsun Ahn (Unlicensed) will support all performance testing questions and feedback (Josh is out on Thursday).


Team Parrot

Stock Reason Tagging

Epic link:  OLMIS-4131 - Getting issue details... STATUS

Nikodem Graczewski (Unlicensed): Mary Jo Kochendorfer (Deactivated) we would like to make this epic our Sprint Goal if that sounds right to you. This means that tickets from this epic would have the highest priority in the Sprint.

Stock Based Requisition

Epic link:  OLMIS-3850 - Getting issue details... STATUS

Dependency diagram:  https://www.lucidchart.com/publicSegments/view/71af4a62-0bea-4245-9005-3461919c9d35/image.png

Sebastian Brudziński we would like you/Team Parrot to own these epics just like you did with the POD work after you were in Seattle.

Nikodem Graczewski (Unlicensed): This epic needs to wait for  OLMIS-4131 - Getting issue details... STATUS  to be finished before any progress can be done.


Editing Orderables

Josh: would this UI be helpful for the product registry?

Demo Data

Josh please add ticket here, and flag which are for Team ILL/Parrot:

  • OLMIS-4493 - Getting issue details... STATUS  (Team ILL)
  • OLMIS-4503 - Getting issue details... STATUS (Team ILL)
  • OLMIS-4491 - Getting issue details... STATUS (Team ILL)

UI

Other?

Bugs and Tech Debt

Sebastian Brudziński We would like to start a new process where a percentage of every sprint is set aside for Bugs and Tech Debt. For bugs we propose 20% of the sprint, and you would pull in bugs from the prioritized bug list that Team ILL maintains either on these wiki pages or directly from the Jira backlog (Sam Im (Deactivated) will provide the list). For Tech Debt we propose you/Team Parrot choose what items add the most value (Josh Zamor has ideas about how to get this started).

key summary type priority status labels
Refresh


Team has groomed and estimated Tech Debt for this sprint:




Team Ona

Team ILL

Team ILL still needs to conduct spring planning for 52.


The following were notes and was communicated at the top of the page

  • Team Parrot will start Sprint 52, but will focus on fixing the performance issue for single approve, and performance testing for convert to order. The main goal is to demonstrate/repair that we have NOT degraded in performance.
  • Sprint Q&A: Team Parrot will discuss the performance testing results and day's status.
  • Performance Testing & Resolution:
    • Single approve - the fix doesn't quite get us to the performance guidelines. What else could we do?
      • Our baseline for single approve is ~20 seconds overall, so that is what we are aiming for in order to say we have comparable performance. looking at the 3.3.0 numbers, our median value looks to be about ~40 seconds before any fix, so in order for us to get down to ~20 second baseline, we need to reduce by about 15-20 seconds, meaning the “fix” should ideally get down to the low single digits
      • Any solution will require a regression of all requisition test cases (and maybe convert to order).
    • Convert to order - We need to prove we didn't degrade in performance.
      • Everyone needs to test and update performance page with results (testing one convert to order, multiple convert to orders, multiple times)
      • 3.2.1 baseline for convert to order:
        Convert 8 requisitions: 20s (POST /convertToOrder 15s, GET /requisitionsForConvert 2s)
        Convert 1 requisition: 6s (POST /convertToOrder 3s, GET /requisitionsForConvert 2s)
  • Additional notes:
    • Sebastian Brudziński - one thought could be to make supply line configuration change for supervisory nodes (which we recently did) in perftest. Do we think that may have an impact on the performance results in perftest when comparing to our baseline?
    • Sebastian Brudziński - an option is to spin up a 3.2.1 perftest, and have the 3.3 perftest for comparison for the convert to order (Chongsun writes up instructions on how and why)
    • Jakub Kondrat can move forward with creating tickets for  OLMIS-3498 - Getting issue details... STATUS  and replicating to other services.
    • Research, collect and record results. Solutions to single approve performance should be reviewed by Sebastian. The goal is to match the baseline or increase performance without impacting too many services which would cause more regression testing.




OpenLMIS: the global initiative for powerful LMIS software