Team practices

Team practices

Sprint ceremonies

• We work in two week sprints.
• 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 ZenHub sprints to manage sprints.
• The product owner helps break down and groom stories and determine priorities. 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 work with the Product Owner to prioritize tasks related to 18F's transition off of the project (like coaching and training) and product work.
• In sprint review, we’ll show working software (when applicable) and discuss which planned stories were completed and not.
• G&A, 18F, and CIO folks will participate in bi-weekly retros and speedbacks to reflect on and refine how we work together.

Making decisions

• We use Architectural Decision Records (ADRs) to record decisions that have significant impact on the product architecture. ADRs help us have a clear decision-making process around these sorts of decisions, as well as a public project history.
• Summary: Using ADRs to make proposals for significant decisions helps us:
  • Socialize proposals publicly
  • Makes the decision-making process more explicit
  • Aligns with best practices identified by 18F and other organizations
  • Uses the GitHub repository to keep decisions close to the code
• See ADR 0 for a detailed explanation of how our ADRs work.

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:

Column	Definition	When Things Move In/Out	Who Moves It
New Issues (Inbox)	New issues automatically show up in this column, and will be prioritized by PM/PO.	We believe in making our work visible and create new issues whenever they’re needed--If you are doing work, it should map to an issue on the board.	PO
IceBox	Bright ideas we don’t want to lose sight of, but aren’t going to be in scope any time soon.	During sprint planning or backlog grooming, it’s determined the issue is not within the current scope of the project.	Anyone on the team.
Product backlog	Unprioritized and unrefined issues that we know we’ll need to complete.	During backlog grooming and throughout the sprint as needed.	PO and whoever is facilitating backlog grooming.
Prioritized backlog	Prioritized issues that are getting urgent that we may want to work on next.	New issues may move in at any time from the inbox, product backlog or icebox. They are prioritized during backlog grooming.	PO and whoever is facilitating backlog grooming.
To do	Refined, prioritized, labeled issues ready to be worked that we’ve committed to for the current sprint.	During sprint planning we move the issues we commit to complete during the sprint from the prioritized backlog.	PO and whoever is facilitating sprint planning.
In progress	ssues that are in progress, assigned (or self-assigned) to someone, and actively being worked on.	Anytime during a sprint, any team member takes on a card from the “to do” column.	Assignee
In review	Issues that are currently in active review or when work is ready for peer or PO review (PRs, waiting for acceptance from a teammate, waiting for feedback).	Anytime during a sprint	Assignee
Blocked/waiting	Issues that are blocked or in a holding pattern (blocked by another story, waiting for feedback from stakeholders, on hold until an upcoming meeting, etc).	During sprint planning or anytime during a sprint.	Assignee
Epics	Slices of core functionality around which we’re organizing our work.	Should be revisited once a quarter. May occasionally have new issues added or reprioritized.	PO
Done	Completed issues, closed by assignee.	Anytime, as work is completed	Assignee

The inbox should be triaged throughout the sprint by the PO and any remaining issues reviewed and moved out of the inbox weekly during /backlog grooming and sprint planning

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.