Collaboration Cycle - Add PO sync touchpoint to Collab Cycle

[shiragoodman]

Problem Statement

VA.gov Platform leads from OCTO have had difficulty overseeing what products, features and iterations are being built by VFS teams for VA.gov. This can be problematic for a few different reasons.

1. Products that have minimal value to the Veteran end up being prioritized, over other, more valuable features.
2. Even if a product/feature has value to a veteran, the approach the VFS team is taking may follow our normal build patterns for VA.gov. (Engineering track in Collab Cycle?)
3. The VFS may not be aware of all the resources, services and tools available to them, causing them to built their own solutions for existing problems (eg building their own components or patterns, creating their own notification systems, etc).
4. VFS may take on initiatives that require additional support services such as mobile or CAIA, potentially overburdening other teams.

The purpose of this initiative is to introduce an opportunity for the OCTO Platform POs to sync with the VFS POs (whether they're within OCTO or not) so that they may discuss the product brief to understand what product/feature is being built and why.

How might we introduce a new touchpoint without burdening the VFS team? How might we be mindful of OCTO schedules and availability? How might we inform the VFS team of this new touchpoint and ensure they participate?

See proposal, approved August 27, 2024, for a full overview of the planned work.

Hypothesis or Bet

If we introduce a new PO synch touchpoint post Kickoff, Platform OCTO-DE folks will have greater awareness of what's being built for VA.gov.

If we introduce a new PO synch touchpoint post Kickoff, we can ensure that VFS teams are aware of all the resources available to them so they don't reinvent the wheel.

If we introduce a new PO synch touchpoint post Kickoff, we can ensure that Platform and Sitewide teams that provide support to the VFS team have the bandwidth available to help.

We will know we're done when... ("Definition of Done")

• [ ] We have added a new touchpoint to the Collaboration Cycle that occurs post Kickoff, pre Design Intent

Known Blockers/Dependencies

List any blockers or dependencies for this work to be completed

Projected Launch Date

• When do you expect to be completed rolling out this initiative*

Launch Checklist

Guidance (delete before posting)

This checklist is intended to be used to help answer, "is my Platform initiative ready for launch?". All of the items in this checklist should be completed, with artifacts linked---or have a brief explanation of why they've been skipped---before launching a given Platforminitiative. All links or explanations can be provided in Required Artifacts sections. The items that can be skipped are marked as such.

Keep in mind the distinction between Product and Initiative --- each Product needs specific supporting documentation, but Initiatives to improve existing Products should reuse existing documentation for that Product. VSP Product Terminology for details.

Is this service / tool / feature...

... tested?

• [ ] Usability test (TODO: link) has been performed, to validate that new changes enable users to do what was intended and that these changes don't worsen quality elsewhere. If usability test isn't relevant for this change, document the reason for skipping it.
  • [ ] ... and issues discovered in usability testing have been addressed.
  • Note on skipping: metrics that show the impact of before/after can be a substitute for usability testing.
• [ ] End-to-end manual QA or UAT is complete, to validate there are no high-severity issues before launching
• [ ] (if applicable) New functionality has thorough, automated tests running in CI/CD

... documented?

• [ ] New documentation is written pursuant to our documentation style guide
• [ ] Product is included in the List of VSP Products
  • List the existing product that this initiative fits within, or add a new product to this list.
• [ ] Internal-facing: there's a Product Outline
• [ ] External-facing: a User Guide on Platform Website exists for this product/feature tool
• [ ] (if applicable) Post to #vsp-service-design for external communication about this change (e.g. customer-facing meetings)

... measurable

• [ ] (if applicable) This change has clearly-defined success metrics, with instrumentation of those analytics where possible, or a reason documented for skipping it.
  • For help, see: Analytics team
• [ ] This change has an accompanying Platform Release Plan.

When you're ready to launch...

• [ ] Configure your communication to teams about your work using the Change Communication Guide
• [ ] Conduct a go/no-go when you're almost ready to launch.

Required Artifacts

Documentation

• PRODUCT_NAME: directory name used for your product documentation
• Product Outline: link to Product Outline
• User Guide: link to User Guide

Testing

• Usability test: link to GitHub issue, or provide reason for skipping
• Manual QA: link to GitHub issue or documented results
• Automated tests: link to tests, or "N/A"

Measurement

• Success metrics: link to where success metrics are measured, or where they're defined (Product Outline is OK), or provide reason for skipping
• Release plan: link to Release Plan ticket

TODOs

• [ ] Convert this issue to an epic
• [ ] Add your team's label to this epic
• [ ] Add this initiative to the Digital Experience Product Board using these instructions

[shiragoodman]

@humancompanion-usds FYI - please feel free to add on/refine.

[shiragoodman]

@humancompanion-usds Planning. Will move into In Progress on 8/15, next sprint. Refinement will take place 8/8, so I will have a better idea of timelines by the end of the week. FYSA, since the output of this work will heavily involve you and Danielle, we will likely need your input and involvement.

[humancompanion-usds]

This will allow the OCTO Design Practice leads to speak with OCTO Product Owners after they file a kick-off ticket and before they reach design intent. This relates to zero silent failures as I will be asking all POs if they are aware of the endpoint monitoring requirements and whether they currently have silent failures then informing them that they won't be able to ship until they have audited their applications for silent failures.

[humancompanion-usds]

This is done! 🥳