Team practices

Team practices

Sprint planning

• We use sprint planning to commit to a set of issues achievable within a sprint.
  • During sprint planning, we review the prioritized user stories, develop sprint goals, and pull achievable issues based on capacity into the upcoming sprint.
  • We use Github milestones to reflect sprints.
• Team meets biweekly for backlog grooming in order to break down upcoming user stories into tasks based on upcoming sprint goals and milestones, and to revisit backlog issues to ensure they are still relevant. We groom with the Product Owner who helps determine priorities based on goals and upcoming milestones.
  • Ideally, issues that need to be created for an upcoming sprint should be determined during backlog grooming and created before sprint planning.
• We create new issues as needed, whenever. New issues:
  • Should include “we’ll know we’re done when” criteria.
  • If large, should be broken down into discrete issues.

Maintaining the board

We maintain an open project board of planned, in progress, and completed issues.

• Icebox - Planned for later, not yet ready, or not yet refined
• New/unprioritized - new issues automatically show up in this column, and will be prioritized by PM/PO
• To do - Refined, prioritized issues ready that are ready based on priorities to be pulled into a sprint
• In progress - Issues that are in progress, assigned to someone, and actively being worked on
• In review - Issues that are currently in active review (PRs, waiting for acceptance from a teammate, waiting for feedback)
• Blocked/waiting - Issues that blocked or in a holding pattern (waiting for feedback from stakeholders, on hold until an upcoming meeting, etc)
• Done - Completed issues, closed by assignee

Once an issue is pulled into a sprint, it should remain in the sprint unless the team re-prioritizes.

• For issues not completed in a sprint, we will revisit during planning and determine whether they should be carried over, broken down further, or reprioritized.
• For issues that will span multiple sprints, try break it down into smaller issues that won’t carry over if possible.
• We only move issues scoped for a sprint to the left of the board (for example, from in progress to icebox) when we’re closing out a sprint or starting a new sprint unless the team makes a prioritization call mid-sprint.

When possible, link related issues together by referencing issue #s.

• User stories will have context on our goals and assumptions, and tasks related to the user story should be linked to the user story.

Labels

We use labels to help us filter the board, view workstream-specific issues at a glance, and to explain closed issues that are duplicative or no longer valid.

• engineering, UX research, design, acquisition, and product workstream labels - Show which part of the team owns the work. These labels are applied by anyone at any time.
• focus labels - Tie issues to specific prototyping focus areas / features. PM will apply this to user stories. Team members should apply these to related tasks.
• bug - Something isn’t working. Anyone can log a bug and should add this label when they do.
• dependency - Used for issues capturing external dependencies that we need to track.
• duplicate - This issue or pull request already exists. Anyone can add this label when they notice a dupe.
• invalid - This doesn’t seem right or is no longer a relevant issue and can be closed. Anyone can add this label.
• needs refinement - Used for issues that need to be refined in order to pull into a sprint. Anyone can add this label to draft issues but PM/PO may apply this when more detail is needed prior to prioritization.

Sharing and reflecting on our work

• We regularly conduct sprint reviews to show work and get feedback on these from other team members as well as stakeholders or other interested parties.
• We regularly participate in retrospectives.