Availability Framework (Remote Config)

[kellylein]

---

Project Objective:

Goal: Establish a way to address critical errors immediately

Today, when critical errors affect the Mobile Application, we currently do not have an immediate way to address them outside of the normal app store release and review process. As a result, users experience a broken app until it can be fixed.

We are proposing a solution to be able to "turn off" or restrict the feature remotely so that the user will not have a bad user experience. The user will receive a message indicating that the feature is currently experiencing an error. The user will then proceed to update the app via the store in order to get the actual fix and to regain the data originally restricted to them.

Product Brief.

[Use Case Summary](Availability Framework Use Cases-MVP 9_11_23.pdf

Status: Shipped Jan 2024

Current Dependencies / Blockers

Blockers

|Blocker | Team / Owner | Est to Resolution | |-------|---------|-------| | N/A | | | | | | | |

Project Timeline

Milestones

|Step | Timing | |-------| ---------| |Sprint 0 - Discovery | Q3- 2023 | |Step 1 - Strategy |Q3-2023 | |Step 2 - Design |Q3-2023 | |Step 3 - Building / Implementing | Q4-2023 | | 100% Release |ESTIMATED- NOV 2023 |ESTIMATED- NOV 2023| Shipped Jan 2023 |Step 4 - Post Verification| |

Monthly Update

Updates

|Month| Project Health | Progress & Key Accomplishments| Issues/Risks/Blockers| |-------| ---------|--------|---------| |July '23| N/A |Aug '23| GREEN- Discovery |Sep '23|GREEN-Implementation Start |Oct '23|GREEN-Completing Implementation and QA start |NOV '23|GREEN-Estimated Release Nov 23 2.17 (Not confirmed)

Detailed Project Scope

Problem Statement

Today, when critical errors affect the Mobile Application, we currently do not have an immediate way to address them outside of the normal app store release and review process. As a result, users experience a broken app until it can be fixed.

We are proposing a solution to be able to "turn off" or restrict the feature remotely so that the user will not have a bad user experience. The user will receive a message indicating that the feature is currently experiencing an error. The user will then proceed to update the app via the store in order to get the actual fix and to regain the data originally restricted to them.

Assumptions

1. Remote config attached to features alone will not suffice. This will remove a feature, but it takes time to flush cache.
2. For message content, current message content available for any existing errors supersede and will apply before any new messages for remote config.

Risks

1. Hindering veteran app experience is worse than some of the outcomes we are attempting to avoid. We will need to be clear where and what is being disabled and be as minimal as possible.

Definition of Done

Following needs to be true

|Item | Completed | |-------| ---------| | | | | | |

Project Scope

**MVP Scope:** We are proposing a solution to be able to "turn off" or restrict access to the affected feature or screen remotely when critical errors occur, so that the user will not have a bad user experience. We will explain to the user that we’re fixing an issue and offer the ability to get that information some other way in the meantime, so that users are able to complete the task they came to the app to do. When appropriate/available, we will allow the user to update the app via the store in order to receive the actual fix and the functionality originally restricted to them. **Out of Scope:** 1.IOS or Playstore Rollbacks 2. Feature Rollbacks by % (Paced Rollouts) 3. A/B Testing

Items in and out of scope

|In Scope | Out of Scope| |-------| ---------| | | | | | |

Important Project Links

Links

- [Github](url) - [Product Brief](https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/va-mobile-app/features/Remote-Disaster-Mitigation/Remote-Disaster-Mitigation.md) - [Product Canvas](url) - Design - [Discovery](url) - [Mockups](url) - [Final Design](url) - [Figma File](url) - Research - [Document 1]([Availability Framework Use Cases-MVP 9_11_23.pdf](https://api.zenhub.com/attachedFiles/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBb1NLIiwiZXhwIjpudWxsLCJwdXIiOiJibG9iX2lkIn19--cf00d27494395bef2b2b8055e38a6f987a7c877f/Availability%20Framework%20Use%20Cases-MVP%209_11_23.pdf) ) - [Document 2 ](url) -Analytics - [Document 1](url)

Team Members

Contact List

- **OCTO Product Leads:** Rachel Han and Ryan Thurwell - **PM:** Rachel Han - **Ad Hoc PM:** Stacy Blackwood - **Engineering:** Jon Bindbeutel - **Design:** Holly Collier - **External Team 1 & Role:** Content- Misty M. - **External Team 1 & Role:**

OKR and Analytic Metrics

Metrics

|What we are measuring | Why | Event Name |-------| ---------| ----- | | | | | | | | |

Checklist

Toggle Product Checklist

**Project Kickoff & Requirements Gathering** - [X] Project Kickoff session - [X] Initiative Scope finalized - [X] Link Product Brief - [Sprint 0 ](https://docs.google.com/document/d/1WHDJ1iCt9J-acLx8_DSL4tkRKoVYqJGaRUqXuFf7ceg/edit# ) - [ ] Link to Implementation Strategy - Implementation Plan - UAT Plan - Release Plan - Metrics Identified (what metrics are we capturing, how do they tie into stakeholder OKRs, etc) **Pre-Production Readiness** - [ ] Associate Readiness - [ ] Update product guide - [ ] Coordinate with contact center support teams - [ ] What’s New Content - [ ] App Store/In App messaging (if applicable) - [ ] Coordinate with Release coordinator - [ ] App store Content changes required? Y/N - [ ] App store images needed? Y/N - [ ] QA Signed off - [ ] UAT complete - [ ] Obtain Go/No Go decision **Feature Go Live** - [ ] Ensure Waygate/Feature toggle release ticket submitted w/engineering & QA - **Template: Turn on Waygate/Turn off feature flag** - [ ] Coordinate with content & release coordinator if what’s new in app is required

Toggle Team Collaboration Checklist

- [ ] Design Intent & Feasibility discussions - [X] Research needed? No - [ ] UAT Needed? Yes/No - [ ] Ticket creation - [ ] Demo feature (mid check, end of development)

Toggle Design/UX Checklist

- [X] Review problem/opportunity statement - [X] Add questions and assumptions to product brief - [X] Add research links to product brief - [ ] Document high-level research/design plans - [ ] Create lo/hi fi wireframes & user flows if applicable - [ ] Add links to Epic & applicable GitHub folders - [ ] Socialize designs - [ ] Sign off received - [ ] Complete Design QA - [ ] Does it require component review? - [ ] Accessibility review needed?

Toggle Content Checklist

- [ ] Review product brief and surface any questions, assumptions & risks - [ ] Participate in project discovery and kickoff activities/ceremonies - [ ] Complete comparative analysis/content research activities for net-new content - [ ] Review current content and determine where app may need to differ and potential improvements to share with web - [ ] Review past VA research and decisions documentation - [ ] Support Research & UX Design in research sessions and synthesis - [ ] Make content recommendations for lo-/hi-fi wireframes in collaboration with UX Design - [ ] Collaborate with Sitewide Content team for alignment, improvements, and sign-off - [ ] Participate in FE hand off - [ ] Complete content QA - [ ] Write copy for What's New In App - [ ] Write copy for app stores' What's New sections. - [ ] Write copy for updated screenshots in app stores

Toggle Engineering Checklist

- [ ] Are UI designs/ specs available/ready? If yes, they should be attached to attach specs. (We are assuming the design specs have been approved) - [ ] Are there any deadlines that need to be met? - [ ] What is the roll out plan? (Do we need a feature toggle? is this going to be available to every user immediately or do we want to roll out to a few users first) - [ ] Does this project require api integration? if yes, what api endpoint are we integrating with and what is the expected response body? - [ ] Do we want to capture analytics for this projects (i.e. update GA, add logs to grafana/datadog etc)?If yes, what metrics would we like to capture?

Toggle QA Checklist

- [ ] Create test plan - **Template: QA Test Plan** - [ ] Identify test data needs - [ ] Gotten & incorporated test plan review - [ ] QA Complete - [ ] Waygate tasks complete - [ ] Added new feature cases to the RC in TestRail - [ ] Added feature cases to appropriate section of active cases in TestRail - [ ] Spun up a (future) UI automation ticket for new feature

[bischoffa]

Per Q3 Planning this work is to start in Q3 and to carryover into Q4 - can see this in SoS board as Step 3 Part 1 is in the last sprint of Q3 which is 10/10

[StacyB2023]

@bischoffa New plan is start this one a step 0/1 in sprint 79 and continue from there in Q3

[StacyB2023]

Notes from last weeks meeting. I will convert this to markdown at some point this week after our other meetings and add to a github folder. Maybe a consolidated file.

Meeting Notes

cc: @dumathane @mistymg @htcollier

[StacyB2023]

Notes from 9/6/23 Meeting

cc: @dumathane @htcollier @mistymg

[StacyB2023]

Use Case Summary:Availability Framework Use Cases-MVP 9_11_23.pdf

USE CASE SUMMARY

[bischoffa]

@StacyB2023 @dumathane can you please add points to the Availability framework tickets? There are some on the board that are blank

[StacyB2023]

@dumathane These are the use case ones i mentioned moving the status/and adding points to. cc: @bischoffa

[StacyB2023]

Note: ESTIMATED release here is 2.17. Not yet released. Added comments under project timelines.

cc: @ajsarkar28

[StacyB2023]

11/16/23: Testing may continue into sprint 85 and if so we will not release in 2.17 as planned. We need to complete testing and demo

[bischoffa]

Updated release date from 12/19 to 1/16/24 as it was part of the 2.19 release. Mobile decided to do a freeze during the holidays which delayed the release.

Meaning AF will only work for Veterans using Mobile App Version 2.19 or newer

[StacyB2023]

Shipped- Jan 2024 (corrected)

[bischoffa]

@StacyB2023 shows 2023 above I think you meant 2024.

[StacyB2023]

Ooops correct. Still speaking in 2023. :)

Implemented Jan/2024