Scrum for global teams: What works?

Epic groomings

Yep, they are Epic! Epic-based. We started to focus our grooming sessions on epics, instead of estimating points for miscellaneous tickets. We don't refine more than one epic per meeting. As I mentioned before, the value of the grooming session for us lies in the conversation it generates between engineers. That's when the implementation starts, even if no line of code is being written. The foundations of an epic grooming session are:

• One meeting, one epic. No more than one epic should be refined in a session.

• No rush, take your time. There is no time pressure to move to the next ticket. We take as much time as needed, even if that means spending the whole meeting on one single ticket. We prioritize deep discussions, saving our time during the implementation rather than having a fast session and a slow implementation.

• Write a list of definitions. These get copied to the task description during the discussions, so information is not lost.

• Create many tickets. It helps to break down work.

Boosted daily meetings

As humans, we recognize the importance of daily meeting small talk. It helps us stay connected with the team and creates stronger relationships between members. But we all know the classical problem of the daily meetings: a person joins, tells everyone their update, and then goes to do something else and stops paying attention.

In this system, the main value of these sessions is mainly for the EM and PM, while for the rest of the team, they’re pretty much just another routine task occupying prime time in the calendar. This is what we have changed in our daily meetings to add more value to everyone:

• We have made the meeting flexible. It doesn't happen every day, and if we need to schedule another important team session at that same time, no big deal.

• We don't rush through it. While some people, including ourselves, try to speed up the discussion, make it asynchronous, or remove it altogether, we went in the opposite direction. And it worked! The books say it should take 15 minutes. We have increased it to 30. We start with some small talk, then we do the regular daily meeting updates, and we dedicate the rest of the time to project reviews.

The project review consists of selecting a project in progress and going deeper into where we are and what is next. This is a way I found to start more conversations about our projects, which would be common in an office environment when people are going to have lunch, walking to grab a snack, or going back to their desks after a meeting.

These conversations add so much value and were neglected in the remote work world. With them, it becomes easier to spot gaps, improve alignment, and raise awareness on the multiple parts of a project being built together.

Asynchronous sprint planning

Spoiler alert: moving many ceremonies to asynchronous mode was my first idea when thinking about Scrum optimizations. But this was the last attempt I made to apply this, and it's the only one that worked. And it works very well in my opinion. 

As someone who spent most of my career as a software engineer and now leads teams as a Senior Engineering Manager, I’ve always found sprint planning painfully tedious. They generally involve endless debates over priorities, technical debt, engineering tasks, and bugs. I only cared about one outcome: the finalized sprint backlog. To fix this, I introduced asynchronous sprint planning for engineers, giving them more uninterrupted focus time (PMs and I still meet synchronously).

To prepare, you will need to calculate the amount of story points that your team can commit to in the next sprint. There are many ways to do it, but this is how I do it: I look at the time off calendar to collect the total number of engineering availability per sprint, and I calculate the story point capacity for the next sprint based on the historical spreadsheet of story points completed per day of engineering availability.

With this information ready, I meet with the PM to pick together the tasks for the next sprint and define the sprint goal. 

The last thing I do is to record a 5-minute video where I go over the previous sprint metrics (mainly predictability), and whether its goal was achieved or not, then I talk about the tasks of the new sprint and its goal. The engineers seem to like the video and interact a lot with it, pointing out dependencies and important points needed to meet the sprint goal. Asynchronous sprint plannings save our team a lot of engineering time and increases awareness about our goals.

And that’s it! I hope you found these tips useful! If you agree (or disagree) with any of them, I’d love to hear your thoughts.

I'll be back soon with more software engineering and management posts. Until then, find me on LinkedIn.