Staging review

Last updated: May 5, 2025

Is your team getting ready to launch your product or feature? You may be ready for the Staging Review, a required touchpoint of the Collaboration Cycle. Follow these guidelines to get started.

This touchpoint is only for teams building products for Veterans, their caregivers, families, survivors, and representatives. Teams building products for organizations (e.g., VA employees, contractors, representatives working in an organizational capacity, etc) should not schedule this touchpoint.

Watch this video for a quick, high-level overview of the Staging Review meeting. For complete details, read the article below.

What is the purpose of the Staging Review?

The goal of the Staging Review meeting (or “touchpoint”) is to ensure that you’re launching a product that meets VA.gov Experience Standards and Platform QA Standards. This is your last opportunity to ensure your product is accessible, compliant, and consistent with VA.gov standards before releasing it to VA.gov users.

Preparing for the Staging Review

Scheduling and Requirements

We encourage VFS teams to schedule a Staging Review when you can ensure that all requirements are met. To allow time for the Governance Team to complete the review, your application must meet these requirements 4 business days before your review.

The VFS team agrees to:

1. Verify that the product/feature is ready for production, with no additional development planned outside of addressing findings from Staging Review.

2. Make the product available for testing on an approved staging environment 4 business days before the Staging Review meeting.

3. Provide information about known issues and bugs, including planned solutions, in the Collaboration Cycle ticket.

4. Provide test user information with valid credentials if the product requires authentication.

5. Document all user scenarios and how to test them, i.e.: in-progress form, submitted form, new form.

6. Update the product’s primary entry point page and include it for review, if applicable.

7. Provide all other artifacts marked as required in the Collaboration Cycle ticket.

8. Not make changes to code or artifacts during the 4-business-day window before the meeting.

The Governance Team might postpone your Staging Review if:

• Any requirements still haven’t been met while we’re testing your product in the 4-business-day window.

• There is a third-party dependency or system access issue that prevents the team from completing the Staging Review.

What artifacts will be needed?

Required artifacts

• URL(s) to review the product

  • The product should be available on an approved staging environment.

  • List pages, sections of pages, and/or user flows impacted by this work.

• Drupal or Staging URL for updated primary entry point: the main way Veterans will access the tool through site navigation (not search).

  • If the primary entry point is not a page on VA.gov, include information about how to view it. Reach out to @platform-governance-team-members on Slack with any questions.

• Test users and scenarios (when applicable)

  • Store test user information, passwords, and tasks in a .md file in the va.gov-team-sensitive repository.

  • Make sure all user scenarios can be tested, i.e.: in-progress form, submitted form, new form.

• List of known issues and bugs

  • Include a list of known issues and/or bugs that might be flagged at Staging Review.

  • If possible, please include links to relevant tickets.

• Link to Sitewide CAIA intake ticket, if applicable.

• Completed accessibility testing artifact: see instructions and link to accessibility testing template.

• QA Artifacts*: artifacts that correspond to each of the QA Standards.

  • Regression test plan

  • Test plan

  • Coverage for References

  • Summary (Defects) reports

  • E2E tests

  • Code coverage

  • Endpoint monitoring playbook

* A VFS team that launches a static page through the Collaboration Cycle will not be held responsible for upholding the QA Standards. Static pages do not have dynamic content that requires extensive testing.

Not required, but nice to have artifacts

• Content source of truth: link to CAIA Content feedback, such as a content source of truth.

• Information Architecture spec: link to CAIA IA feedback, such as an IA spec.

How to schedule a Staging Review

Follow the steps in your team’s Collaboration Cycle Request GitHub ticket.

1. Schedule: Use the Calendly link in the Before Meeting > VFS Actions section to select a date for the touchpoint meeting. The Governance Team will reach out within a business day via Slack to confirm that your touchpoint has been scheduled.

2. Add artifacts: Go to the Before meeting > Staging Review artifacts checklist and make sure the requested artifacts are linked.

Please request your Staging Review meeting and provide artifacts at least 4 business days ahead of time so the Governance Team can review your artifacts.

Who should schedule the Staging Review?

No one specific role on the VFS team is required to schedule the Staging Review.

Who should attend the Staging Review?

The VFS team’s product manager, OCTO-DE Product lead, and anyone from your team or VA stakeholders who contributed significantly to the artifacts should attend the Staging Review.

The Governance team will ensure that the relevant Platform and OCTO-DE participants are invited.

What happens during the Staging Review?

Meeting format

• 30-minute synchronous Microsoft Teams meeting

• Hosted by the Governance Team

• Recorded for later reference

Agenda

Staging Review meetings often follow this format:

• The Governance Team welcomes everyone to the call.

• Your team then has the opportunity to provide any updates, if any.

• The Governance Team will go over their findings, starting with QA.

• If any launch-blocking or other issues are found, the Governance Team will review any Github issue tickets they’ve created.

What sort of findings can teams expect?

The Governance Team uses the VA.gov Experience Standards and Platform QA Standards to identify any launch-blocking or other high-priority issues.

Launch-blocking issues can include:

• Test coverage for a category is below 80% or no E2E tests

• Content that is contradictory or confusing to the user

• Missing breadcrumbs component

• Important content or components are missed by screen reader users

Non-launch-blocking issues can include:

• Typos

• The first segment of <title> tag, current breadcrumb, and H1 text are not the same

• Use of imposter components

• A link opening to a new tab without warning users

• Extra padding on a page’s design

Note: This is not an exhaustive list of potential issues; it's possible that other issues may be identified during the Staging Review.

After the Staging Review

After the meeting, the Governance Team will add the link to the recording to the Collaboration Cycle Request GitHub ticket.

GitHub issue tickets are linked to the Collaboration Cycle Request GitHub ticket and can be found through the associated Milestone. For more information, please review the Anatomy of a Staging Review Issue ticket page.

If any launch-blocking issues have been identified, those issues must be addressed before launch. Once you’ve addressed the launch-blocking issues, you don’t have to schedule an additional Staging Review; you can launch.

Lastly, after you launch, you are required to submit a VA 508 Office Audit Request. Please review the guidelines on how to request support from the 508 office on the platform website.

Help and feedback

• Suggest content changes to this page.

• Submit new Platform Website content.

• Get help from the Platform Support Team in Slack.

• Submit a feature idea to the Platform.