Goal: To prepare for a 3.2.1 release candidate at the end of October (~Oct 25 2017). See Release Candidate Process.  Team ILL will focus on Performance.  Team Parrot will focus on fixing bugs and the MUST tickets until performance tickets are available. BUGS are in priority order in the backlog. 

Bugs

Go to backlog, they are in priority order (and there are 17 of them).

These two bugs in the backlog are assigned to Team ILL

•  (Team ILL)
•  (Team ILL)

Requisitions

•  (MUST)
  • We didn't take this ticket as there is a lot of unanswered questions.
•  (MUST)
  • How do we want to approach this ticket? If we do a check before rejecting and then reject the requisition someone can still initiate a requisition in between.
  • There is no mockup.
  • Should it be only warning or should the newer requisition be deleted when we click the reject?
  • Maybe performance improvement would be to create/update rows in one database request?

F&E

•  (MUST)
  
  • How many values do we want to include in the CSV file for performance testing?
  • It is highly unlikely that this endpoint will work in less than 0.5 s as every item has to be parsed.
  • What is configure ISA page? Is it the page with upload export?

Stock Management

•  (MUST) 
• Ticket for creating more demo data (maybe for Team ILL)

Admin Screens/ Configuration Reporting

•  (MUST) Sam Im (Deactivated) there are still open questions in the ticket.
  • Won't it be better to use current implementation of reset password and send email with link to password change page?
•  (Team ILL - Sam to work with Chongsun and Josh on questions in this ticket before it can be worked on)

CCE

Reference UI

•  Team ILL (this could be fast)
•  Team ILL
•  Team ILL
•  Team ILL
•  Team ILL

Low Priority

•  (wait)
•  (wait)

Platform

• Set up Demo environment for TechNet presentation (Team ILL)
•  (already in sprint 35) — Team ILL retrospective idea "pipeline not rejecting, notifiying developer, and preventing deployment to test"
• "automated tests are not visible/documented in a way implementers and stakeholders can read them" — Team ILL retrospective idea
• "No checks on test quality/confidence" — Team ILL retrospective idea
• "Not sure how to write testing stuff in tickets" — Team ILL retrospective idea
• Pull together performance testing progress/results and present to Product Committee? (Team ILL) 
•  (Maybe... for the implementers' guide?) Team ILL

UI Performance Sprint Spike for Team ILL (75%)

Goals: 

• Get UI Performance metrics so we can track our progress
  • Get sample data (from MW), put it on our test servers, do manual testing
    (Using core OpenLMIS back-end services and front-end UI app.)
    • Steps/Tasks: 
      1. Get MW data
      2. Identify worst case user/s (which user account, which Facility/ies, which Program/Essential Medicines, ...)
      3. Load data into PerfTest server
      4. Run automated tests using worst case user
      5. Run manual tests/exploratory testing to discover UI performance priorities
         (within Requisitions and Orders)
      6. Use Daily Standup meetings to prioritize and turn ideas into action
    • Risk: The Malawi code-base is customized, so that codebase may have different issues.
  • Capture Before and After states to tell our story
    • Use network and browser tools to simulate LMIC internet connectivity speeds/latency/intermittent connectivity
• Get UI Performance into an acceptable state
  
  • Define what is acceptable for non-functional performance
  • Turn issues/problems into ticket assignments for Team Parrot

Re-Supply Ticket Writing for Team ILL (25%) 

For Planning Only

Malawi-UI

Nick Reid (Deactivated) is this really something we should be taking on prior to a release?

Goal here is to un-fork MW-UI files to make upgrading possible (and establish extension patterns)

• 
• Malawi-Performance

 (Team ILL)

Requests from Malawi

Ben Leibert and Christine Lenihan, please make sure the following tickets are in priority order so that we can review for the next backlog grooming call on 21 Sep 2017 . If bugs come in after that, please make sure to flag prior to 26 Sep 2017 so we can review prior to planning.

•  (Malawi can simply set up email rules for now.)

•  (Not urgent, but perhaps worth mentioning so it isn't forgotten.)

Goal: Squash bugs for the 3.2.1 release. Judiciously continue with F&E features and performance improvements.

Grooming Question: There have been discussions around modifying the release process this time. I'd like to make sure we are clearly communicating the plan to the team. Brandon Bowersox-Johnson do you have an update from the conversations with Josh Zamor?

UPDATE: No decisions yet about the 'release candidate' process or doing a 'slow down and go careful' release for 3.2.1. So for now we are grooming priorities on this page for a squash-bug-and-release scenario, but that could change before sprint 36 begins.

Issue: Malawi faces time-outs when configurations are incorrect. Is there a way to provide an error versus timing out? See the recent slack ex