I currently act as scrum master for two teams, one remote and one co-located. I have found that the conversations around expected functionality and business requirements happen on both teams but the information seems to get lost and confused on the remote team.
This perplexed me for a while. I thought I was doing the same things with both teams. The same basic planning and discussion was taking place but the remote team just seemed to always wind up with more confusion. More of their work had to be reworked to get acceptance from our product owner.
Eventually we began writing down all of our decisions and business expectations instead of just relying on the discussion. We started having our business analyst do more documentation of the features in the beginning of the sprint and reviewing what the team was planning to build.
After doing this for a while I could see it was working. The confusion had been cleared. About that time I realized that this is exactly the same thing my local team was doing all along. The only difference was that the remote team took longer to figure out the need so it was staring me in the face as something that was harder for my remote team.
After thinking about this I realize that remote teams take longer to identify and solve issues with how they are doing things. That is really the root cause of this issue. I suspect a lot of my remote ream rules will be incorporating items identified this way. If I can just find a way to fix that root cause the other rules wouldn't be as necessary.
Eventually technology might solve it and eliminate the difference between remote and co-located teams. In the meantime figuring out this set of rules for handling remote teams is my best answer.
Remote Team Rule 2: Team decisions need to be written down and shared.