PDS Team Meeting Guide - NASA-PDS/nasa-pds.github.io GitHub Wiki

Overview

PDS EN currently runs 3-week sprint increments and 6-month release increments. Within this timeframe we have several meetings to help (hopefully) move the project along and make sure we are doing what we think we said we are going to do.

Stand-ups

Twice weekly 30-minute stand-up meetings on Tuesday and Thursdays to give a quick status and keep the team in the loop on what is going on.

Meeting Prep Checklists

  • Team Members
    • Update stories in Github Issues:
for each open(story):
   check_is_in_correct_sprint_milestone(story)
   check_is_in_correct_pipeline(story)
   status_in_comments(story)
   note_repo_and_issue_number(story) # to help Facilitator if having trouble tracking down

  • Come prepare to answer these 3 questions in 2-minutes or less:

    1. How did you crush it since the last tag up meeting?
    2. How are you going to crush it before next tag up?
    3. Any blockers/obstacles standing in your way from crushing it?

  • Team Facilitator

    • Review all In Progress and Review/QA tickets and prepare for discussion.
    • Review open pull requests and assign as needed.
    • Review the Sprint and Release Backlog to ensure we have the next up in the case something is closed.

  • Product Owner

    • Triage any open tickets and add into the Product Backlog
    • Update priorities of stories in Release Backlog and Product Backlog
    • Review open pull requests

Meeting Agenda

Around the room with each team member getting ~2-minutes to discuss:

  1. How did you crush it since the last tag up meeting?
  2. How are you going to crush it before next tag up?
  3. Any blockers/obstacles standing in your way from crushing it?

Any technical issues that pop up, let's try to take offline to the Breakout meetings, unless they are blockers.

Breakouts

Twice weekly technical meetings for more detailed discussions identified during stand-ups. These are placeholders on our calendars, but should be created on-the-fly as needed for any blockers.

Sprint Review Expectations & Guidelines

Purpose

Sprint Reviews are for showing what we delivered and getting feedback from our customers and stakeholders.

Focus on outcomes, not status.

What to Present

Everyone contributing to development or operations should have meaningful work represented in the review.

Good topics include:

  • New features or capabilities
  • Deployments
  • Bug fixes
  • Performance or reliability improvements
  • Operational improvements or automation
  • Prototypes, benchmarks, or investigations with actionable results
  • Customer-requested improvements

Whenever possible, show the work with a demo, screenshot, metric, example, or other tangible result.

Avoid:

"Worked on Registry performance."

Prefer:

"Registry ingestion is now faster because of X. Here is the measured improvement and what it means for users."

Before the Review

  • Add your topic to the agenda.
  • Link relevant GitHub issues when useful.
  • Prepare your demo, slides, screenshots, or other material.
  • Be ready to answer:
    • What changed?
    • Why does it matter?
    • Who benefits?
    • What can users do now that they could not do before?
  • Test demos ahead of time when possible.

Preparing for the Sprint Review is part of completing the sprint.

Presenting

Present your own work whenever possible.

If you prefer not to present, provide your material to another team member, Tomas, or the EN Manager to present on your behalf.

Keep presentations:

  • Customer-focused
  • Outcome-oriented
  • Concise
  • Demonstrable
  • Understandable without deep implementation knowledge

Review Format

Sprint Reviews will generally follow:

  1. Sprint goals and highlights
  2. Delivered capabilities, demos, fixes, and improvements
  3. Upcoming deployments or near-term changes
  4. Customer questions and feedback
  5. Follow-up actions

Topics will generally be grouped by capability or product area rather than by individual.

Bottom Line

Every review should answer:

What did we deliver? Why does it matter? What can our customers do with it? What feedback did we learn from?

Meeting Info

When is it?

Every 3 weeks, on Thursdays at 2pm PDT

Who is it for ?

  • developers
  • product owner
  • I&T personal & management
  • operation personal & management
  • cloud migration management
  • key users in discipline node

What is it for?

Sprint reviews are used to communicate on the tasks the dev team has been working on during the latest sprint (3 weeks):

  • Done tasks: a demo or some kind of presentation (web page, wiki docs, slide ...) of the outcome of the task
  • Uncompleted tasks: short status, percentage of completion, reason for not being complete.

Since it is a review, we expect anyone to give feedback on anyone's work, in a convivial way. For example, someone working on UI can ask question on the Nucleus.

We want the sprint review to be as lively and convivial as can be.

Agenda template

Demos: The demo will be added to the agenda the morning of the review at the latest. Each will be 5 minutes or less + questions. Uncompleted tasks: Walk through burn down report and discuss status

Retrospective

TBD