Guiding principles and practices

While there’s almost always someone on the team, who is on the team may fluctuate a lot!! Anyone working on this might get drafted to a billable project with little notice, so we optimize for helping people quickly onboard, contribute, and roll off. Facilitators strive to keep task assignments up to date, given that people may need to hop on and off the team with little notice.

Agile ceremonies

We work in two-week sprints. Standing meetings and what they’re for:

Tuesday at the start of the sprint: Combined sprint review, retro, planning mtg
Second Tuesday of each sprint: Coworking power hour
Standups weekly on Tuesdays, Wednesdays, and Thursdays (standups typically cover, Hello!, Yesterday, Today, Blockers, to Discuss)

Github issues

We aim to keep issues scoped to what can be done within one week to give folks a good chance of completing a task they’re assigned to in the event they’re staffed to a project.

The scope of an issue is any task associated with the product. This includes onboarding and offboarding as well product ownership tasks.

We’ve created a few issue templates for basic task tracking, and onboarding an offboarding new teammates. These templates are synced across a few repos to help save time and track work consistently. If you make changes to the templates, an automatic PR should prompt you to check and see whether those changes need to be made to the UX guide templates and/or the Methods templates. You can read more about syncing here.

Labels & milestones

We use primarily use labels to communicate:

the type of change the issue will result in (e.g., enhancement, bug fix)
skills the work might require (e.g. UX design, front end, engineering)
to which products the work is relevant (e.g. method cards, ux guide, other guides)
and the status of the issue (e.g., new issue, needs refinement)

We use milestones as part of a rough prioritization framework:

We organize milestones into three-month increments.
We name milestones for the season/year. For example, Winter 2022, Spring 2023, etc.
We define high level goals for each three month increment.
We attach milestones to the issues that we believe ladder up to those goals.

How issues move through the board

Column name	Definition	How issues move
No Status	Where new tasks go until discussed with the team	Anyone on the team can create an issue, and add a “new issue” label. New issues are discussed as a team during backlog grooming. “New issue” label should be removed when discussed before moving into “Priority backlog”
Priority backlog	Work we know we want to do at some point	Product owners move new issues from “No Status.” Issues enter “Priority backlog” when they are identified as a body of work that will improve at least one Guide and create a range of options for the team to work on. Issues typically move into the “Priority backlog” during backlog grooming. “Needs refinement” label should be removed before moving into the “To do” to make sure it's scoped narrowly enough for a sprint.
To do	Items that are committed to for the current sprint	Team members self assign issues from “Priority backlog” in “To do”
In progress	Tasks someone is actively working on	Anytime during a sprint, any team member takes on a card from the “To do” column. WIP limit = 2
Blocked/Waiting	Issues that can’t move forward at the moment	Issues only get moved here from in progress. Whoever is assigned the issue can move it to blocked when they encounter a blocker
Done	Product Owners or people tagged to approve an issue can merge and move issues to Done	Issues are archived and move out of the done column by Product Owners after every sprint review

Code review

Pull Requests should have at least one member of this team approve it in order for merge Try to have another Engineer look at any tech-heavy PR’s It’s helpful to call out in the PR description why someone has been requested for review and to point them towards specific things to look at.

Example: “Tagging @Melissa for design review of the UI and @Greg for technical review of the configs”

When commenting on PR’s as a reviewer, it’s helpful to specify whether your comment is blocking or non-blocking for approval. You can use Conventional Comments Syntax for this if you’d like to.

Once the PR has been approved, merging can be done by either the reviewer or the submitter, so we don’t have mergeable code waiting around for too long.