We believe that interal communications is not being succesfully executed in a way that people know what success looks like from the DEPO perspective, and agree with that definition of success. This can be seen in the neutral repsonse on the team health survey, and in pain points around internal VSP communications identified in retrospectives.
HMW be more intentional with solving for team awareness and recognition needs?
Hypothesis or Bet
Experiementing with DEPO communication strategy will improve the VSP contract team's sentiments around DEPO communication on the team health survey.
We will know we're done when... ("Definition of Done")
We will know this has improved when we have successfully improved that rating for the fourth quarter, and reduced the occurance of those themes in team retros.
Launch Checklist
Guidance (delete before posting)
This checklist is intended to be used to help answer, "is my VSP 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 VSP initiative. 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
[ ] (if applicable) Post to #vsp-service-design for external communication about this change (e.g. VSP Newsletter, 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.
andreahewitt-odd
commented
4 years ago
Problem Statement
We believe that interal communications is not being succesfully executed in a way that people know what success looks like from the DEPO perspective, and agree with that definition of success. This can be seen in the neutral repsonse on the team health survey, and in pain points around internal VSP communications identified in retrospectives.
HMW be more intentional with solving for team awareness and recognition needs?
Hypothesis or Bet
Experiementing with DEPO communication strategy will improve the VSP contract team's sentiments around DEPO communication on the team health survey.
We will know we're done when... ("Definition of Done")
We will know this has improved when we have successfully improved that rating for the fourth quarter, and reduced the occurance of those themes in team retros.
Launch Checklist
Guidance (delete before posting)
This checklist is intended to be used to help answer, "is my VSP 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 VSP initiative. 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?
... documented?
products/platform/PRODUCT_NAME/platform/PRODUCT_NAME/README.mdplatform/PRODUCT_NAME/, unless you already have another location for it... measurable
Required Artifacts
Documentation
PRODUCT_NAME: directory name used for your product documentationTesting
Measurement
TODOs