Processes

Weekly Sync

The team holds weekly syncs.

The meeting notes of team syncs can be found our sync meeting notes Google Doc.

Before team syncs, teammates and stakeholders should write down under “Agenda” in the meeting notes document anything that they’d like to bring up for discussion with the whole team. Attendees are encouraged to add comments on talking points asynchronously before the meeting too.

Planning and prioritization

We plan and track our day-to-day work on our GitHub board. The project is separated into multiple views: Current iteration, Next iteration (both grouped by issue status) and All iterations (grouped by milestone).

Our current process is as follows:

• We work in 2-week iterations. Every iteration has a GitHub milestone, which is created at least one iteration in advance.

• Incoming tickets (from team members or from other teams) are added to the GitHub project automatically when they are labelled team/code-insights and will be visible in the “All issues” view under “No milestone”. This represents our backlog of unscheduled work.

• While an iteration is ongoing, we plan the next iteration. This is a mostly asynchronous process.

  • Engineers, designer, PM and EM propose issues to be worked on the week before the mid-iteration Monday sync by adding them to the next iteration milestone and setting “Status” to “Proposed”. This is done considering our higher-level goals and roadmap.

    • The issue should also have its Estimate column filled out, so that it can be evaluated whether it fits into the iteration. If the proposer lacks the information to estimate the issue, they reply on the issue in GitHub or raise it in our Slack channel to get the missing information or get an estimate from the appropiate person. Teammates may also discuss this in ad-hoc synchronous meetings if beneficial. An assignee may also already volunteer or be proposed, but this may still be changed at the Monday sync to distribute workload.
      • If technical exploration is needed to get more information, a spike (a time-boxed investigation task meant to facilitate more granular planning) can be proposed for the next iteration instead to get that information.
        • Estimations include the testing time necessary to fully test an issue against test plans or test cases defined in the issue.

  • As much as possible, the proposer involves the necessary stakeholders asynchronously to get agreement on whether the issue should be worked on in the next iteration before the Monday sync. For example, the PM or EM might ping engineers in GitHub or Slack on whether an issue seems feasible, or engineers might ping their EM and PM to get buy-in whether the issue fits into our goals.
    If a task needs synchronous discussion with a smaller group than the whole team, teammates are encouraged to meet synchronously in a smaller group to have more clarity before the mid-iteration Monday sync.

  • Teammates can reorder proposed issues on the “Next iteration” board before the mid-iteration sync to their liking. The order at the time of the mid-iteration Monday sync is the proposed order.

  • At the mid-iteration Monday sync, we take a look at the proposed issues together on the “Next iteration” view to reach agreement on the set of iteration issues, their assignees, and order, taking into account our goals and roadmap, technical aspects, estimates, workloads on individuals, and release dates (the 20th of every month).
    As a rule of thumb, the sum of estimates for each individual should not exceed 8 days (out of a 10-work-day iteration) so we have enough buffer, time to reply to asks from other teams, to plan the next iteration’s projects, and self-organized slack time.

  • On the Thursday before the next iteration begins, we have a brief synchronous meeting to finalize our planning for the iteration. Depending on our needs, this meeting may cover: questions about priority, clarity, or edge cases of specific features for the next iteration; refining plans for the following Monday iteration start; surfacing any missing GitHub issues (for known items) ahead of the Monday kickoff so they can be made before Monday. This meeting is also an opportunity to review the status of our current iteration and examine if any issues should be carried over to the next iteration. This meeting is in experimental stage – we will try this process through mid-February 2022 and then decide if it’s consistently worth the time.

• During an iteration, teammates work on their assigned issues for the iteration in the order they are listed in the “Current iteration” view of the board. When starting work on a task, the teammate updates its status column to “In Progress” to communicate it to their team. This gives a good overview in the “Current iteraton” view, which can also be viewed in Kanban layout, on how the iteration is tracking.

• If one or more issues that were planned for an iteration are looking to not get finished (which includes testing) in the current iteration (while maintaining sustainable work practices) the assignee raises this as soon as possible asynchronously to the team (including the PM and EM), e.g. on the GitHub issue or Slack. These issues then become proposed issues for the next iteration (meaning nothing carries over automatically, but we also don’t just drop and forget missed issues).

Product Feedback

Specific product feedback about well-defined, small features can be found directly in the GitHub board. More general product feedback that applies to larger features, or that needs more research and planning to be actionable, is kept in Productboard.

Retrospectives

Every two weeks, we hold a review/retrospective meeting to reflect on the past two weeks. We use this meeting to:

• Review the previous retro’s action items to ensure they get completed
• Give Shoutouts! to teammates to show appreciation for something they did that we appreciated
• Discuss things that went well in the past two weeks and that we should do more of / invest more into it
• Discuss the things that could have gone better and what we can learn from it to improve
• Talk about processes that we should revisit/refine/propose to improve our efficiency.

We capture and assign actions to individual teammates. Teammates should consider actions coming out of the retrospective as a very high priority.

Teammates contribute to the retrospective asynchronously during the iteration by adding their thoughts to our retrospective document. Teammates are highly encouraged to comment on points raised before the sync meeting in the document.

We rotate who leads the retrospective to allow all teammates an opportunity to lead the session. Teammates can find the rotation schedule at the top of the retrospective document.

Code reviews

The team follows the default code review guidelines with the following addition:

1. If the author would like any of the requested reviewers to merge the PR after approval they add the label merge-on-any-approve
2. If the author would like their PR to be merged once all of the requested reviewers have approved it they add the label merge-on-all-approve
3. When there are only minor issues, reviewers are encouraged to give “approval with comments” and trust their teammates to address the comments without requiring a follow-up review.