Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Review High Level Release Plan Proposal
  • Discuss Story Pointing Approach
  • Review List of Functional Test Cases
  • MultiVIM update
  • Review M2 checklist
  • Communication (IRC)
  • Labs
  • Documentation
  • Round Table

Notes:

  • Release Plan - high level proposal reviewed with the team;
    • Sprint One: 8/1 - 8/16
      • Identify the functional test cases [APPC-105]
      • Restart LCM action [APPC-88]
      • Bug fix contribution [APPC-100]
      • Functional test case automation - part 1
        • Can we automate any during sprint 1?
      • SONAR blockers- Part 1
      • ODL upgrade???
        • Updated ETA from SDNC is now 8/4; so tentative at this point if this is Sprint 1 or 2
      • OAM Epic (APPC-38)
        • Action: Discuss with Sharon if some stories need to be in Sprint 2; 
    • Sprint Two: 8/17 - 8/31
      • AT&T feature contributions (epics: APPC-9, 22,12,10,11,53,57,62,63)
      • ODL upgrade ??
      • Functional test case automation - part 2
      • LCM API Doc upgrade
      • SONAR blockers/criticals - Part 2
    • Sprint Three: 9/1 - 9/14
      • MultiVIM integration testing
      • SONAR - blockers/critical - Part 3
      • Documentation updates (Epic APPC-89)
      • Release Notes
      • API Guide
      • User Guide
      • APPC Client Library Guide
    • Sprint Four: 9/15-9/29 - Hardening
      • University training recordings
        • Scott - APPC overview
        • Paul - APPC model driven
      • Defect fixes as needed
  • Comments on release plan:
    • no major issues raised by team
    • question/concern raised on heavy loading of Sprint 2, but that is where the bulk of the code contribution from AT&T and AMDOCs is coming. We will need to see how we can mitigate this during Sprint 2.  Will explore to see If there are opportunities to get some of this in Sprint 1. 
    • JIRA APPC board currently reflect above plan for the most part: APPC JIRA Board
  • Story Pointing Approach….
    • We did not get a chance to cover this topic, but my proposal is to use a simple story point method for R1 : 1 or 0
      • 1 means in-progress
      • 0 means it's done.
    • This method seems most reasonable for this release since many of the contribution are coming items being worked by various companies and being pushed to ONAP..
    • Reminders of JIRA good practices:
      • When you start to work a story or bug, move State to In-Progress.
      • When you deliver or close a story or bug, don't forget to update the Resolution field; i.e., don't leave it Unresolved!
  • Review list of Test Cases (unit, functional, integration) - what can be automated, what can’t be automated; any we can undertake in Sprint 1