There is no such thing as a team without processes, only teams with undocumented processes. Therefor, we prefer to document the way we do things, and evolve it over time!

We share the Developer Insights org’s processes, plus the following for our team. We use our bi-weekly retrospective to identify any tweaks we should make that would improve our process.

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.

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


Despite following two-week iterations, our releases are monthly on the 20th and we may sometimes need to order tasks in a way that we can get important projects into the next release.

We also intentionally plan so we can avoid merging significant work less than two days before a release (if a release is on the 20th, our last day to merge is the 18th). Exceptions require explicit approval of both the PM and EM.

Planning larger projects

Larger (usually multi-iteration) projects coming from our roadmap go through three phases. (Note that these three phases are the team collaboration phases, but there are often additional individual phases like product/design research processes or technical research that may come before phase 1.)

  1. Product context and scope agreement (usually 1-2 weeks)
    The PM (or other driving individual) creates a product-level RFC summarizing user desires from feedback and proposes a reasonable timeline to reach a scope agreement (mentioned in the RFC). Engineers, designer (as applicable), PM, and EM discuss the needs in the RFC and the feasibility/complexity of different options. The goal of this phase is to agree on a scope for the project, which will generally be a subset of the desires the PM/driver outlined in the RFC based on the implementation complexity, how long it would roughly take to implement, and how much time we want to dedicate to the project. After discussion, the agreed-upon scope is recorded in a section at the bottom of the RFC.

  2. Design and implementation planning (usually 1-2 weeks)
    For a UI project, our designer will create wireframes and designs which are reviewed and discussed by all teammates in Figma. Similarly, engineers will make a proposal for the needed GraphQL APIs (e.g. in an RFC) and agree on the API shape, think the implementation through, and create concrete implementation sub-tasks with estimates, testing plans, and a tracking issue collecting them. The goal of this phase is to be “ready to go” for the implementation phase – having a plan (with reasonable confidence) that only needs to be executed.

  3. Implementation and testing (usually 1-4 weeks)
    Engineers execute on the implementation plan, putting a set of issues from the tracking issue into each iteration. This also includes that each sub-implementation-task is sufficiently tested, meaning by the end of this phase the project is ready to ship to customers with confidence.

We sequentialize and parallelize projects in a way that we can plan projects (step 1 and 2) while another project is currently being implemented, so that we always have the next project ready to be implemented by the time a project has finished implementation. We will however make sure to never have multiple projects in planning phase at the same time, as this leads to cognitive overload while also delivering on an implementation for another projects. This means a teammate may have to think at most about 2 projects at any given time: one that is being implemented, and one that is being planned, and a teammate will never have to implement more than one larger project at the same time.

Tracking issues

To plan projects that span multiple iterations and need to be broken up into sub-tasks, we make use of tracking issues. The tracking issue is created by one of the teammates with a descriptive accompanying label, e.g. insights-dashboards-v1 (milestones are not used for this, as they are used for iterations).

Suffixes like v1 can be used to communicate we are aiming for an initial, well-defined scope to avoid scope creep. After the agreed upon scope for the project is completed, the tracking issue is closed. Further improvements are either tracked as individual tasks in iterations, or if a new, larger, multi-iteration improvement, a new tracking issue is created with a new label.

Individual tasks of the tracking issue are assigned to iterations through their milestone.

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.


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.