Growth/Team/Norms

This page is intended to document the Growth Team's norms and ceremonies. Team ceremonies for Growth is defined as a series of acts and processes performed regularly with the intention of creating an environment that promotes iterative improvement, innovation and productivity.

On this team, process is not intended to become performative, rather it is intended to provide the needed structure to:

• Improve Iteratively; Learn and Adjust  
  • Experiment
  • Fail Fast
  • Reflect
• Collaborate
• Share Knowledge, Wins & Lessons
  • With Each Other
  • Our Communities
  • The Foundation
• Set and Meet Goals
  • Adding Value/Priorities > Scope  
  • Wikimedia Foundation Annual Plan
  • Short and Long Term

Team ceremonies can be altered if it is collectively determined after trial they are not effective as is. Plans and goals are set as a baseline and something to strive towards. Plans and goals if not met should not result in condemnation or negative tones. Not meeting plans and goals should be viewed as an opportunity to learn what needs to be adjusted, rather it is process, priorities, scope or expectations.

Standup

Asynchronous standup

• Goal of async standup: Provide a brief and focused status update on individual and team progress, identify any obstacles or issues, and facilitate communication and collaboration within the team.
• Team Norms:
  • Meeting Facilitator: Product Manager
  • Async updates should be added in a form of a new message (not a thread) to the #growth-standup Slack channel.
  • Team members are expected to answer the following questions:
    • What have you been working on? (Since your last async update)
    • What is your next priority?
    • Are there any blockers?

• Cadence of updates
  • Daily (Monday-Friday) or Every other day with the update combining what was worked on for the previous day for Engineers, QA Engineer, and Designer
    • Post at the beginning of each working day.
  • Weekly for CRS, Engineering Manager, Product Manager, Design Researcher, Data Scientist
    • Post by EOD of the first working day in a given week.

Synchronous standup

• Attendees: Growth team members (mandatory) + cross-functional team members (mandatory)
• Meeting Goal: Provide a brief and focused status update on individual and team progress, identify any obstacles or issues, and facilitate communication and collaboration within the team.
• Meeting Preparation: make sure your assigned tasks are up-to-date
• Agenda:
  • Each team member shares:
    • What have you been working on?
    • What is your next priority?
    • Are there any blockers?
    • Anything positive you want to share? This is optional, and should be brief. It can be work-related or personal.

• Team Norms:
  • Meeting Facilitator: Product Manager
  • To keep this meeting brief, we will start promptly on the hour. If a task or blocker is identified that needs further discussion, involved team members should stay on the call after standup ends to discuss.
  • All Growth team members (who aren't on vacation or listed as optional) should join this meeting.  If you need to miss this meeting, please decline the invite in advance with a note.
  • The Product Manager will share the Phab board of our current sprint filtered to the team member talking.
  • Standup is handled async on other work days, but synchronously on Wednesday.

Task Estimation

Phab board triage occurs asynchronously. It is done by engineers as part of the daily chores process.

• Attendees: team engineers (mandatory), other team members (optional, but highly encouraged if your work is blocked by an engineering task). Any team member is welcome to join and estimate tasks, specially if they are familiar with the task domain.
• Meeting Goal: Collaboratively estimate the development cost of a task in story points
• Meeting Preparation: Attendees are encouraged to get familiar with the tasks to be estimated during the session. These are any unestimated tasks in the Up Next  column and, if time allows, the high priority tasks in the Backlog column on the Growth team Phabricator workboard.
• Agenda:
  • Estimation: using planning poker game, estimate as many tasks as the meeting timing allows. We will be using Mountain Goat pack (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, ☕)
  • What do the points mean?
    • ½ = about a half day of engineering effort (For example about 2 hours of code + 2 hours of code review)
    • 1 = one perfect day of work*
    • 2 = two perfect days of work*
    • 3 = three perfect days of work*
    • 8 = eight perfect days of work* / approximately a sprint worth of effort
    • 13 = 13 perfect days of work* / unlikely to be completed within one sprint
    • 20/40/100 = this task represents an epic and should be broken down before being pulled into the sprint.
    • ? = too many unknowns / impossible to estimate (we should likely create a research spike subtask before working on this)
    • ☕= I am not adding a numeric vote due to lack of knowledge in this area
  • NOTE: * “a perfect day” represents a silent Friday or a day of uninterrupted work. In a two week sprint with 10 working days, an engineer is unlikely to have a 10 point capacity, because they have meetings, code review, time off, etc.  

Sprint Planning Meetings

• Attendees: Growth team members (mandatory) + cross-functional team members (highly encouraged)
• Meeting Goal: Collaboratively define the scope of work for the upcoming sprint, establish a shared understanding of the objectives, and determine which backlog items will be tackled.
• Meeting Preparation: Engineering tasks are estimated. The Product manager has prioritized the “Up Next” column.
• Agenda:
  • Reprioritization: are there any tasks that should be reprioritized? (For example, a high-impact bug or other high-impact priority that is missing or seems mis-prioritized).
  • Capacity: each team member reviews their schedule for the coming sprint and shares what number of team days they have available for Growth team work (considering other commitments, meetings, vacation, time off, etc.)
  • Commitment: each team member claims the tasks they believe they have capacity for in the coming sprint, and we review together as a team.
• Team Norms:
  • Meeting Facilitator: Product Manager
  • Notes: No notes, updates made in Phabricator.
  • The team should be familiar with the top priority tasks in the backlog, as identified in the Async “Sprint Backlog Refinement” email sent by the PM the Thursday before planning. Any open questions should already be asked in Phabricator, and Growth’s Technical Lead should help break up engineering tasks if any tasks are too large to be completed within a two week sprint.
  • During a sprint, we start with a Right to Left analysis of the new sprint board and estimate tasks that were added to other list columns on our sprint board. We discuss and attempt to unblock these tasks so that we can have capacity to handle more within a sprint. Once we get to the Incoming column, we estimate the tasks which have no explicit ownership first. If we have story point bandwidth remaining, in that the maximum number of story points of a sprint haven’t been reached, we head to our backlog column on our main board where we can add new tasks for estimation to the sprint starting from the highest priority moving downwards.

Team Discussion Meetings

• Attendees: Growth team members (mandatory) + cross-functional team members (highly encouraged) + Ambassadors (optional)
• Meeting Goal: In the second week of our sprint, we will have a 50 minute meeting for any needed Team Discussions.  The goal of the meeting is to facilitate in-depth team discussions, which may include topics such as design exploration, experiment analysis review, release planning for larger releases, or guest speaker presentations as needed to enhance team collaboration and project understanding.
• Meeting Preparation: Will be communicated in advance via email, the Thursday prior to this meeting.
• Agenda: The Team Discussion agenda is set in advance by Growth’s Product Manager, in collaboration with other team members.

• Team Norms:
  • Meeting Facilitator: Product Manager
  • Notes: Notes taken in the associated Planning document.
  • The Growth team’s Product Manager will send out a Meeting Agenda and any "homework" on the Thursday prior to the meeting. Often, the team will cope with wide geographical distribution by assigning "homework," to mitigate the need for synchronous meetings. This will often take the form of a pre-recorded video or slide deck, which members of the team will watch ahead of a meeting to discuss it. The minimum time to get homework ahead of such a meeting is 2 days, not including the day the video was sent and the day the video will be discussed.
  • All Growth team members (who aren't on vacation or listed as optional) should join this meeting.  If you need to miss this meeting, please decline the invite in advance with a note. Ambassadors are encouraged to attend, but listed as optional attendees.

Sprint Review

• Attendees: Growth team members (mandatory) + cross-functional team members (optional)
• Meeting Goal: Showcase the work completed during the sprint, gather feedback from stakeholders, and assess whether we met our individual and collective sprint goals.
• Meeting Preparation: Be ready to discuss and possibly demo what you completed.
• Agenda:
  • Share Sprint metrics
  • Demo completed work
  • Review current sprint board in Phabricator
• Team Norms:
  • Meeting Facilitator: Product Manager
  • Notes: No notes, updates made in Phabricator.

Retrospective Meetings

Retrospective Meetings (retros) are bi-weekly meetings attended by the team every other Monday. During Retrospectives, the team revisits action items from the last retrospective and reflects on the past two weeks progress by collectively answering the following:

• Attendees: Growth team members (mandatory) + cross-functional team members (optional)
• Meeting Goal: Reflect on the recent sprint, identify what went well and what could be improved, and collaboratively plan actionable changes to enhance team performance and processes.
• Meeting Preparation: Add kudos and topics for discussion in advance.
• Agenda:
  • Share some Kudos/Accomplishments from this Release  
  • What things are working?
  • What could we improve for next time?
  • What is confusing?
  • List & Review Action Items.
• Team Norms:
  • Meeting Facilitator: Engineering Manager

Google Calendar

New members of the team will be added to the Growth team calendar. If a team member will be out of the office for four or more hours during a working day, they are to share it on the team calendar at the earliest indicator that they may be out. This practice will help the team manage expectations when estimating what work can get accomplished during planning. Team ceremonies will also be represented on the Google Calendar.

Code review

Availability

The purpose of the code review availability table is to promote predictability and transparency for the Growth team code review backlog. Code review availability time means engineers will use that time to review patches that fall into the team’s responsibility in priority order. Priority can be complex to determine but high level that would be:

• UBN issues that are blocking train deploys or causing a bad impact in one of our products
• CI issues that are blocking merging code normally in one of our repositories
• “Code review” column in the current team “Sprint X” board
• Other patches in our Gerrit dashboard that do not fall into the prior categories

Availability for reviewing is an euphemism for async, proactive, individual commitment for review work. Given the current team’s maintenance duties (see Developers/Maintainers ) and engineering resources, a dedication between 5-8h a week is recommended. For reviews that require or can benefit from in-person discussion we have a weekly event Synchronous Code Review session, patches for each session are listed in Synchronous Code Review session Meeting Notes. Each engineer in the team is welcome to state their CR availability time in the following table:

Engineer	Times dedicated to focusing on code reviews (in UTC)
Martin Urbanec	Usually ~07:00-09:00.
Sergio Gimeno	Mon 10:00 - 11:00, Tue - Fri 10:00 - 12:00
Cynthia ‘Cyndy’ Simiyu	Mon - Thu 14:00 - 15:00

Time to response

The Growth team works in Sprints of two weeks which makes code review critical for being able to deliver features by the end of the sprint. Deliver as in have them available for testing in the Beta cluster. For that reason the time to response should be short enough to facilitate re-working patches within the duration of a sprint. Growth engineers have a agreed to set the time to response expectation to two working days, excluding Fridays.

Tools

The Growth team uses Gerrit, a code collaboration tool, for peer code review. Some Growth repositories are hosted in gitlab, where we use merge requests to signal new code to be reviewed.

Comment formatting

Starting June 2024, the Growth team uses conventional comments as the formatting standard for review comments in the team maintained repositories (see Developers/Maintainers). The goal of the format is to clarify the comment intent, standardize the tone, make comments more actionable and alike benefits described in the project's page. Individual contributors reviewing changes in the team's maintained repositories are also welcome to adopt the standard.

Phabricator

Phabricator is the organization’s task/issue tracking tool that houses the Growth team’s user stories, tasks, progress and prioritization of work. Tickets at the top of the Ready for Development column in the Current Sprint Milestone are considered the highest priority and next up in the queue to work on.

Translations

Our software contains hundreds of text strings. We rely on volunteers and Product Ambassadors to translate these texts into various languages, and want to reduce the burden of translation as much as possible when adding new texts. In order to do so, we will:

1. Create a "finalize messages and qqq.json" task for an epic. For a given epic of work, there should be a task to finalize messages. In this task, we will make a patch to finalize the copy for en.json and the qqq.json.
2. Allow 7 days for translation. Once the text strings are finalized in step 3, we should allow for at least 7 days before enabling the feature for wide use. That allows ambassadors and volunteers time to translate the text. Examples:
   1. If the messages are finalized on Tuesday, after the branch cut, then the feature using these messages should not be enabled for broad use until the following Thursday, at the earliest.
   2. If the messages are finalized on a Friday, the messages should not be enabled for broad use until 13 days later, on Thursday (group2 deployment) at the earliest. That's because the translators would only have Saturday/Sunday/Monday to get translations done in time for the next week's train.

Updating an existing message

• Once your change is merged, consider that the old string will remain in place in production until it is newly translated. Make sure the overall meaning and intent of the string does not change.
• Give translators time to make their updates, by merging the patch on a Tuesday, for example, so there are 6 days until the next branch cut.