Skip to content

Commit

Permalink
Update Change Management Plan.md
Browse files Browse the repository at this point in the history
  • Loading branch information
@beckyphung
beckyphung authored Dec 12, 2024
1 parent 17ec018 commit a2e34ef
Showing 1 changed file with 53 additions and 58 deletions.
111 changes: 53 additions & 58 deletions products/ask-va/product/Change Management Plan.md
View file
Original file line number Diff line number Diff line change
@@ -1,93 +1,88 @@
# Ask VA VA.Gov Change Management Plan



| Date | Version | Author |
| ----------------- | --------------------- | --------------- |
| November 3, 2024 | Initial Draft | CeeCee O'Conner |
| December 11, 2024 | Updates from CRM sync | Ariel Martinez |

### Goal
This plan defines the ongoing ways of working between the Ask VA VA.gov and CRM teams.

To define the ongoing ways of working between Ask VA.Gov and CRM teams.
- Manage and process incoming feature requests.
- Communicate and align priorities between the two teams, and plan for subsequent iterations of Ask VA.
- Establish processes to support smaller releases.
**On this page:**
- [Manage feature requests and bugs](#manage-feature-requests-and-bugs)
- [Prioritize initiatives](#prioritize-initiatives)
- [Implement initiative](#implement-initiative)
- [Test before launching](#test-before-launching)
- [Manage releases](#manage-releases)
- [Open questions](#open-questions)

### Feature Requests and Bug Reports
## Manage feature requests and bugs
**If the CRM team receives a feature request from a business line**, they can send it to the VA.gov team's shared email inbox (❓TBD).

#### Features
Feature requests should be sent to a shared email inbox. Each feature request must contain the following details:
- A description of the feature or desired change
- I.e updates to rules or logic, creation of a new topic, page UI updates, etc
- The reason for the change
- I.e feedback from business lines or other business justification
Please include these details in the email:
- Dscription of the feature or desired change
- I.e updates to rules or logic, creation of a new topic, page UI updates, etc
- Reason for the change
- I.e feedback from business lines or other business justification

#### Bugs
For issues found via monitoring in the #ask-va-notifications channel, please see TBD.
**If the CRM team discovers bugs**, they can send them to the shared email inbox (❓TBD) or the TBD slack channel (❓Why not use an existing Ask VA channel). For issues found via monitoring in the #ask-va-notifications channel, please see TBD (❓What are we trying to say here? If our team finds issues?)).

User discovered bugs can also be reported to the shared email inbox or the TBD slack channel. The following information must be included in each bug report:
Please include these details in the message:
- Description of the issue
- Steps to reproduce the issue
- The impact this bug has on the system, clients, and/or team
- Expected behavior
- Actual behavior

The recommendation is to collate feature requests and bugs (i.e a Github project view) to track their status and discussions regarding the feature/bug. For example, the Ask Va VA.Gov team decided not to move forward with a feature.

The Ask VA VA.Gov and CRMS teams should periodically review feature requests and bug reports in the CRM sync or in other joint meetings.
- Impact bug has on the system, clients, and/or team
- Expected behavior
- Actual behavior

### Planning
**The VA.gov team will** add feature requests and bugs as issues in our GitHub repo and prioritize them against existing stories.

For each iteration, Ask VA VA.Gov product team creates an [initiative brief](https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/teams/vsa/product/initiative-brief-template.md) to cover what features the team plans to build and outcome(s) the Ask VA VA.Gov team is driving towards. The brief should also contain tentative release dates.
**Both teams will** periodically review feature requests and bugs in the CRM sync or other joint meetings.

The CRM conducts PI planning every 12 weeks. During this time, the initiative brief is reviewed with CRM team identify dependencies, gather feedback, and align priorities. It's recommended that the Ask VA VA.Gov follow a similar planning cadence, thus each brief would encompass 12 weeks of development work.
## Prioritize initiatives
**The VA.gov team will** create an [initiative brief](https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/teams/vsa/product/initiative-brief-template.md) for each new feature. It will contain problems the feature will solve, expected measureable outcomes, tentative release dates, etc.

Ideally, collaboration cycle kickoff and PO sync should occur prior to development starting, in case OCTO rejects some items. The Product outline also needs to be updated with a link to the initiative brief.
**The VA.gov team will** review new and existing initiative briefs with the CRM team every 12 weeks. This is because the CRM team conducts PI planning every 12 weeks. We'll jointly
identify dependencies, gather feedback, and align priorities. The VA.gov could follow a similar planning cadence. Each brief would encompass 12 weeks of development work.

### Development
**The VA.gov team will** submit a collaboration cycle request and schedule a PO sync before development, in case OCTO rejects some items (❓Why the concern).

Once confirmed, features in the initiative brief are broken down into epics that are plotted on a roadmap.
- Epics and their issues are labeled with the release they are associated with.
- Each sprint will have defined goals to track the initiative progress.
- Ask VA VA.Gov operates in 2 weeks sprints (Tuesdays to Tuesday)
### Testing
**The VA.gov team will** add a link to the initiative brief to the product outline.

Each feature shall go through Platform review (required by OCTO) and shall be quality assured
Our initial expectation is that a new feature may be to manually execute a tes
## Implement initiative
**The VA.gov team will** develop epics of work for the initiative. In our GitHub projects view, we'll label epics and their issues with the related release and define sprint goals. We have 2 weeks sprints (Tuesday to Monday).

## Test before launching
**The VA.gov team will** define the scope of QA testing before launching.

Moving forward for testing at the feature level, we will:
- have the product manager or a defined business partner execute a manual test.
- (future state) as a part of the dev tasks, the expectation is create or add an automated test for new feature
- run the core test suite ( the 5 test scripts for launch noted in the test plan to start) will be run at the build pipeline level
For each feature:
- The product manager or defined business partner executes a manual test
- Run the core test suite at the build pipeline level. [See test scripts](https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/products/ask-va/engineering/test-plans/ask-va%20form-dash-testing-plan.md#e2e-automated-testing-cypress) in this GitHub doc.
- (Future state) Expand our automated test suite by creating at least one new automated test for each new feature

On a batch level:
- the Ask.VA.GOV team will run an automated test suite of a larger batch of automated test scripts at a weekly level
- the goal of this activity is to provide confidence for regression testing without signficantly extending the amount of time in development for a developer to run the test suite in the build pipeline.
- Run automated test suite of a larger batch of automated test scripts at a weekly level (❓Our goal is to just do this generally at any time?)
- We're doing this to provide confidence for regression testing without signficantly extending development time for a developer to run the test suite in the build pipeline.

(❓What is the difference between release level and feature level from your perspective)
On a release level:
- the team shall define the a potential number of manually executable test ( while we are burning down the list of potential automated test scripts to be developed from the Form and Dashboard manual test execution list)
- the team shall define the a potential number of manually executable test (while we are burning down the list of potential automated test scripts to be developed from the Form and Dashboard manual test execution list)
- the team shall execute the Insomnia tests to confirm the APIs and mapping are running as expected.

## Manage releases
**The VA.gov team will** use feature flags and toggles to define the stream of work coming through the Continuous Integration and Deployment pipeline. This prevents us from promoting potentially unready work up the environments to production. For example, we separated dashboard code used during our research study from the continuation of development.

### Release Management

- **Feature Flags and Toggles:** through leveraging feature flags and toggles the team will be able to clearly define the stream of work coming through the Continuous Integration and Deployment pipeline (this will prevent us from promoting potentially unready work up the environments to production.)
- An example of this used by the team has been how the Dashboard Research pilot was made separate from the continuation of development.

(❓What's the purpose of include collab cycle info? Who is our audience?)
Collaboration Cycle
After the kickoff request and PO sync, the required touchpoints are:
- Architecture Intent
- PRISS/Security Review
- Staging Review
Additional touchpoints may be recommended by the Governance team after reviewing the kickoff request. However, given the smaller scope of an initiative, less effort should be

### Open Questions
Additional touchpoints may be recommended by the Governance team after reviewing the kickoff request. However, given the smaller scope of an initiative, less effort should be

| Question | Answere |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| How do we handle freezing in shared environments with CRM and Pats R? | AVA CRM/PATSR separation: Ask VA ATO needs to get granted. Submitting in Feb 2025. 90 day timeline to get approved, if there are no changes. Around when portal launches. Once approved and completed all work for separation, shared environment freezes won't be issue<br> |
| How do we define what is our future joint testing between the Ask VA VA.gov + CRM APIs (ex . testing for rules, update to payload, contract testing etc.) | |
| Can the architecture intent and other touchpoints cover all releases in an initiative or must they must be done for every release? | |
| Should an additional Slack channel be created to handle bug reports? | |
| Do we want to version releases somehow?<br>Helps with tracking. Can use labels and/or milestones to link epics and issues to releases.<br>Github also has a release management feature that could be used. | |
## Open questions
|Question|Answer|
|---|---|
|How do we handle freezing in shared environments with CRM and PATS-R?|AVA CRM/PATS-R separation: CRM currently working on separate Ask VA ATO needs to get granted. Will submit in Feb 2025. 90 day timeline to get approved, if there are no changes. Around when portal launches. Once approved and completed all work for separation, shared environment freezes won't be issue.|
|How do we define what is our future joint testing between the Ask VA VA.gov + CRM APIs (ex . testing for rules, update to payload, contract testing etc.)?| |
|Can the architecture intent and other touchpoints cover all releases in an initiative or must they must be done for every release?| |
|Should we create another Slack channel for people to report bugs?| |
|Do we want to version releases somehow?<br>Helps with tracking. Can use labels and/or milestones to link epics and issues to releases.<br>Github also has a release management feature that could be used.| |

0 comments on commit a2e34ef

Please sign in to comment.