Na minha opinião, você NÃO deve liberar o planejamento como uma equipe de 10 pessoas. Muito provavelmente você terminará em uma reunião gigantesca, em que, em qualquer discussão, 6-8 pessoas se sentirão completamente desconectadas e entediadas. Acrescente a isso a exaustão de 3-4 horas sendo trancadas em uma sala juntas. E considere que, se 10 pessoas falam, você tem muita conversa. Se eles não falarem, você pode não receber informações valiosas.
Fizemos algo muito semelhante à empresa de Joseph. Versão anterior, tínhamos 8 engenheiros e o planejamento da versão levou duas semanas sólidas. E foi absolutamente brutal. Poucas horas por dia, acho que todos nós começamos a tentar falar o mínimo possível para que a reunião terminasse mais cedo.
Este lançamento, o tamanho da nossa equipe mais que dobrou. Por isso, dividimos em equipes menores que assumiriam a propriedade permanente de uma área de um produto. Cada uma das equipes menores tinha liderança. Em seguida, fizemos um planejamento de lançamento de alto nível com apenas os leads, que foram muito mais rápidos e eficientes, porque agora tínhamos apenas quatro desenvolvedores em uma sala. Durante esse período, identificamos qual equipe faria quais histórias e como o produto será dividido. Além disso, isso fornece uma imagem maior de todo o produto.
Em seguida, cada líder voltou ao seu próprio time e repassou a parte do release pela qual somente esse time era responsável. Durante esse período, preenchemos alguns detalhes e atribuímos valores de pontos da história.
Por fim, tudo foi montado e fizemos uma explicação final (mais uma apresentação do que uma discussão) para que todos na equipe saibam o que está acontecendo com toda a equipe.
Embora não tenhamos um lançamento completo com sucesso com esse método, acho que o planejamento geral de lançamentos foi muito mais suave do que antes e tivemos muito mais com isso. A chave era que nunca tivemos mais de 3-4 desenvolvedores em uma determinada reunião e a voz de todos ainda era ouvida.
Se possível, eu recomendo que você divida seus 10 desenvolvedores em 3 grupos. Se você não conseguir dividir sua versão geral em três áreas que não se sobrepõem, então até dois grupos seriam melhores que uma grande equipe.