We have proposed a 'relay race' style of development where in-house and remote team members hand off active development on code modules as their work days start and end with the rotation of the earth. This manner of work necessitates very granular requirements so that individual requirements can be completed within a day.

Is this, however, just a nice theoretical way of working? Isn't it common to get into a task and go down a rabbit hole when you discover a deep issue or a refactoring opportunity? What you thought you could finish in the last two hours of the day turns into something much bigger. So, then you end up not committing your changes and your counterpart on the other side of the globe doesn't have an accurate picture of your progress before they begin to work. Duplicate and conflicting work may result.

Yep. That's going to happen fairly often. But, having a TDD mindset can help with this scenario.

The mantra "red-green-refactor" tells us to do the simplest thing possible to go from a failing test to a passing test, then think about how to make the code more beautiful and robust via refactoring. With this approach, we can make the simple change that causes the test to pass and immediately commit the change. Then, if we get deeply involved in some refactoring or deep investigation, we have established a clear indication of our progress. Even our refactoring can be done incrementally. At the end of the day, we can commit what we have accomplished so far and leave notes for what is left to do tomorrow.

When our counterpart starts his/her work day, they will see which requirements have been completed and can move on to the next one. Good notes in the code may also help indicate what issues you are planning to address the next day to prevent conflict.

This won't solve every issue that causes you not to finish a task within a day, but it is a very helpful manner of working in this sort of project.