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 Zehub sprints to manage 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.

Creating issues

• We create new issues as needed, whenever. New issues:
  • Should be created using our issue templates (we have one for user stories and one for tasks) that include "we'll know when we're done" criteria.
  • If large, should be broken down into discrete issues.
• 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.
• We write action-oriented headers, so that someone scanning the board can get a general understanding of the work that the card involves.
• Write behavior-driven stories. Try to write stories in a behavior driven way + with acceptance criteria when applicable (rather than as tasks). Good for us as we work. Also sets an example for our partners.
• Should be tied to relevant epics, and relevant labels should be applied.

Maintaining the board

• We maintain an open project board of planned, in progress, and completed issues.
• As a team, we all manage the board by creating and moving issues across the board as work progresses.

We use the following sprint lanes/pipelines to track work:

• 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.

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.