As the number of potential engineers increases globally, the shift to remote teams as the standard working environment will steadily increase. As a Principal Product Manager at Eventbrite, I’ve worked with co-located teams, dual-located teams and multi-distributed teams. Below I have laid out the structure, tips and tricks that my dual-located team has used to create a working structure between our two offices in San Francisco, CA USA and Mendoza, Argentina.

The team location types

To produce great software requires a great engineering team. It’s evident that talent and experience leads to high-quality work, but there is a third factor which can significantly impact the teams’ ability to deliver: location. Since teammates have to work with one another to produce the highest quality outcome, the location of each member of the team directly impacts the workflow.

There are four types of location for teams:

1. Co-located (all in the same place) [1]
2. Dual-located (2 locations) [2]
3. Multi-distributed (multiple locations and at least 1 has 2 or more teammates) [3]
4. Fully-distributed (each teammate is in a different location) [4]

Co-location is widely considered the best option since having everyone in the same place enables more frequent collaboration with less friction. Dual-location is next since each of the two sites can still have friction-less interactions, and remember that they still have to share their local conversations with the other side. Although not intuitive, people see Fully-distributed as slightly better than Multi-distributed. In practice, a Fully-distributed team will always know who is in a meeting or not, since 100% of the communication is online whereas on a Multi-distributed team side conversations can happen in one location, and the rest of the team can start to lose context and knowledge transfer.

Streamlining our team meetings

With a remote team, the cadence of scheduled meetings is critical to establishing effective communication. Have a look at our team’s core Scrum meetings which ensure we always convene at least once per day:

1. 1st Monday: Sprint planning (1 hour) [5]
2. 1st Tuesday – 1st Friday: Standup (15 min) [6]
3. 2nd Monday: Backlog Refinement (1 hour) [7]
4. 2nd Tuesday – 2nd Thursday: Standup (15 min) [8]
5. 2nd Friday: Demo (30 min) & Retro (1 hour) [9]

Sprint Planning process

Getting into the Sprint Planning meeting without preparation could be a disaster. It is an expensive meeting, so to make the most of the team’s time, try our process:

1. Scrum master creates a new sprint [10]
2. Scrum master reviews the current sprint with the team and makes sure the status of the tickets are accurate [11]
3. Scrum master ends current sprint and rolls non-finished items into the new sprint [12]
4. Scrum master talks with eng team and determines how many points are already committed to in the new sprint from the tickets that rolled over [13]
5. Scrum master reviews Holidays/Time off of the development team [14]
6. Scrum master multiplies each eng’s working days x 0.75 to determine capacity by engineer and for the team [15]
7. Product owner confirms that backlog is ordered by priority [16]
8. Product owner lays out sprint goal and any specific needs [17]
9. Development team now takes over and moves tickets into the sprint based on priority [18]
10. Engineering team makes sure each engineer has work in the current sprint [19]
11. Engineering team removes any tickets that are above capacity [20]
12. Scrum master clicks start sprint and team agrees to measurable goals for the sprint. For example: “enroll 5 clients into early access”, or “feature part x is working in QA” [21]

Standup process

We run seven standups each sprint. We aim to not disrupt the work of the team, but also find out where we are and synchronize. Take into account the following steps to make it worth it:

1. The scrum master runs standup [22]
2. Standup is not a status meeting [23]
3. The purpose of standup is to align the entire team and identify blockers that the team needs to resolve. It should be more about what is coming next than what has already happened (but both are necessary sometimes) [24]
4. If the team needs a more detailed conversation on a specific topic/issue, then the necessary parties should either stay after standup or set up a separate meeting [25]

Backlog Refinement process

The Backlog Refinement meeting has become the best meeting to introduce new initiatives and refine tasks of existing ones. If done correctly, this meeting will result in pointed tasks that are ready for Sprint Planning –enabling your team to have more detailed discussions about what should be in or not in the sprint. Have a look at how we handle this meeting:

1. The purpose of Backlog Refinement is to introduce new concepts and break down work into pointable tasks [26]
2. It is essential that all team members are part of the meeting so that everyone knows what is coming and if an expert is needed they can assist (e.g., there is a discussion between Design and Frontend it’s crucial that Backend is present in case they are needed to offer potential alternative approaches to meet design needs) [27]
3. Given that, there is a spectrum of granularity of what the team could break down, types include: [28]
   • A) Estimating any tasks in the current sprint that the team has not pointed (violation of team agreement) (lead by Engineering)
   • B) Pointing tasks starting at the top of the backlog and going down. If a task can’t be estimated and a spike is needed, then create spike and point the spike (lead by Engineering)
   • C) Reviewing updated designs based on user testing results and updating any tasks and estimations that the team have already created (lead by Design & Engineering)
   • D) Evaluating new designs and looking at current user stories to create the initial Frontend and/or Backend tasks (pointing is optional but not likely) (lead by Design & Engineering)
   • E) Introducing new Initiatives and reviewing Produce Requirement Documents (PRDs) with the entire team that generally kicks off user research (lead by Product)
   • F) Discussing potential initiatives that the team might see PRDs for (lead by Product)
4. After each task or story is created or updated, the Engineering team (lead by QA) should update the JIRA issue with the agreed upon Acceptance Criteria  [29]
5. The Scum master should work with Product before the meeting to understand which types (a – f) should be included in the meeting and agree on the order ( a → f ? or f→ a? ) of the agenda [30]
6. During the actual meeting, if a single discussion point is taking too long, the scrum master should ask the group if it makes sense to have a separate conversation or if they would like to finalize the discussion right there. It is up to the people in the conversation to decide [31]
7. Refinement is never done, so it is vital to be efficient with the time and also start and end the meeting on time [32]

Demo process

The Demo is a crucial meeting to keep your team members accountable and get direct feedback from stakeholders. This process makes it easy to record and distribute for your remote colleagues:

1. The scrum master should discuss with the development team what they can present [33]
2. The scrum master should email the attendees of demo in the morning with the list of items the team will present [34]
3. When the demo starts, the scrum master should record the demo with sound [35]
4. The scrum master should say at the beginning of the demo what the priorities for the sprint were [36]
5. Product owner should say why these items were the priority and speak on any challenges outside of Engineering that occurred [37]
6. The engineering team should present their work so that they can get feedback from demo participants directly [38]
7. At the end of the demo, Product should let attendees know what the current thinking for priority for the next sprint is [39]
8. After the demo, the scrum master should share a link to the video recording to everyone on the calendar invite so that those participants who couldn’t make it can watch [40]
9. The scrum master may decide to include the video link in the overall sprint report as well, which is sent on the upcoming Monday [41]

Retro process

It is essential to look back at the end of the sprint and discuss what went right, what didn’t and how the team can improve. Try our plan to make your team better constantly:

1. The scrum master is in charge of facilitating the meeting. Based on the most significant events of the sprint, the team must decide which technique to use [42]
2. The scrum master should meet the day before retro with the engineering manager to confirm the techniques to use [43]
3. It is optional to make an icebreaker to disperse the members [44]
4. Review the aspects identified in the previous section and its compliance [45]
5. The scrum master explains the selected retrospective technique and the participants have 5 to 10 minutes to write their notes [46]
6. The notes are analyzed and grouped by categories [47]
7. We proceed to vote those we want to discuss in detail [48]
8. Each voted topic is analyzed and discussed. The team extracts action items for the future and assigns an owner [49]
9. The retrospective is closed [50]

JIRA tricks

JIRA is one of the most common workflow tools for engineering teams. It is a powerful tool but can also be cumbersome since it has many features. Have a look at the JIRA tricks the team uses to streamline our process and produce quality software at scale:

1. JIRA stories should follow the format “As a user, I can do X.” The product owner should write the stories [51]
2. JIRA stories should be pointed 0 and assigned to the product owner. The team brings the story into the sprint at the same time as the first task of the story. The story should be marked as done once the last task for a story is done. This allows for easy analysis of how long a story took since Sprint names are appended to tickets as they move from one sprint to the next. [52]
3. The team tried sub-tasks and found them problematic visually and from a velocity reporting standpoint. As such, the team simply creates JIRA tasks for each story and references the parent JIRA story issue. [53]
4. JIRA tasks should start with either FRONTEND or BACKEND as the team has several filters set up in JIRA that are powered by this text. Engineers are encouraged to assign themselves tasks that they feel they can complete, regardless of this label and their specialty. [54]
5. Engineers should write the JIRA tasks [55]
6. JIRA design issues should be created and assigned to Design to give transparency to the team about what Design is working on. This should not be granular workflow but rather high-level issues like “Explore EPIC NAME.” The product owner should manage the design issue. [56]
7. JIRA tasks should be assigned by engineers to themselves and then moved through the swim lanes. A task in RESOLVED means that the code has landed on QA and is ready to be verified. The Engineer who performed the task should include “Steps to Reproduce” in the ticket and assign a “QA owner” [57]
8. The “QA owner” of a task either moves it to DONE or leaves feedback. If feedback is minor, it is okay to leave the task in RESOLVED. However, if it is more extensive or will take more time, the task should be moved back to TO DO [58]

One-on-Ones (1:1)

It’s important to remember that with remote teams, there is no opportunity for catching up on one’s lives throughout the day. As such it’s critical that the first part of recurring 1:1s between the remote team members start with general life-catch up items as simple as “how was your weekend?” or “what are you doing Friday night?”. Reinforcing the human connection between team members lays the groundwork to have more direct and critical discussions about actual work.

1:1s should repeatedly happen to ensure that there is dedicated time set aside to catch up with each remote team member, including:

1. Weekly 1:1s with the engineering tech lead [59]
2. Every-Other-Week 1:1s with engineering team members [60]
3. Every-Other-Week 1:1s with QA [61]
4. Every-Other-Week 1:1s with the scrum master [62]
5. Every-Other-Week 1:1s with the engineering manager [63]

Wrapping Up

Working with remote teams is hard. In this post, we have seen tips to streamline the main scrum meetings, including sprint planning, standup, backlog refinement, demo, and retrospective. We also discussed some tips to work with JIRA, and reviewed best practices when running your remote one-on-ones.

Do you work on a remote team? Is it Dual-located, Multi-distributed or Fully-distributed? Please write into the comments any additional tricks and or structures you’ve adopted to make your workflow process more smooth –and please share with your colleagues if you find any of this helpful. And if you’re interested in more from me, check out my previous blog post How to Make Your Next Event App Remarkable with these 4 Mobile Navigation Gestures.