Em 16 anos, nunca encontrei uma métrica viável do tipo que você está procurando.
Essencialmente, para ser útil, qualquer coisa precisa ser mensurável, representativa e indecifrável (ou seja, o sistema não pode ser reproduzido por desenvolvedores inteligentes). Há simplesmente muitas variáveis no desenvolvimento de software para torná-lo mensurável como peça de trabalho dessa maneira.
O mais próximo que você chega é o progresso em relação às estimativas - quantas tarefas estão sendo concluídas dentro das estimativas acordadas. O truque aqui é (a) obter boas e justas estimativas e (b) entender onde as estimativas foram excedidas por boas razões pelas quais o desenvolvedor não pode / não deve ser culpado (isso é algo realmente mais complexo do que o previsto). Em última análise, se você forçar demais os desenvolvedores, é provável que você encontre estimativas que gradualmente se elevam a um nível em que elas sempre são atendidas, não por causa do aumento de produtividade, mas por causa de escalas de tempo acolchoadas.
Indo para o outro lado em termos de estimativas (reduzindo-as para criar pressão para entregar) e criando prazos que os estudos mostraram que não aumentam a produtividade e provavelmente causam impacto no moral da equipe (veja Peopleware para mais informações).
Mas, essencialmente, eu me pergunto se você está olhando para um problema ligeiramente falso. Por que os programadores remotos são diferentes de outros programadores quando se trata de medir a produtividade? Como você mede a produtividade de programadores não remotos?
Se é para não confiar que eles funcionem remotamente, isso é basicamente um problema de confiança mais amplo. Se você não confia neles para trabalhar em casa, então você precisa estabelecer essa confiança, não deixá-los trabalhar em casa, ou encontrar alguma maneira de se satisfazer de que eles estão de fato trabalhando quando deveriam estar.