Como lidar com a aceitação de múltiplas construções dentro de um sprint ágil

Outros aqui já levantaram a preocupação que a sua pergunta traz à mente: Como você pode estar usando um processo ágil com apenas uma construção em cada sprint? Se esse é realmente o caso (e essas compilações são consideradas muito frequentes por alguém da sua organização), então eu serei mais directo do que os outros: você provavelmente não é realmente ágil.

Um primeiro princípio do scrum é que a equipa produz código de trabalho (ou código pronto para produção se você for um purista) em cada sprint. Se a sua equipa não está a construir e a testar durante o sprint, então eles não estão a entregar o código de trabalho no final, e não estão a "fazer" scrum.

Na verdade, na sua pergunta mencionou que considera um sprint como uma forma de gerir o trabalho de uma semana. Isso sugere que você está apenas usando prazos semanais para verificar o progresso da equipe, com código de trabalho para ser visto após algum número de semanas.

Se eu entendi errado, então desconsidere o acima exposto e concentre-se no que os outros aqui disseram: Qualquer sistema que você use para gerenciar seu código (você usa um, certo?) deve acompanhar o que está incluído em cada compilação. É claro que isso não é conveniente para os forasteiros entenderem, e é por isso que uma das peças realmente importantes da documentação que sai de uma equipe de scrum é as notas de lançamento. Se você está gerenciando itens de trabalho em uma ferramenta, você deve ser capaz de obter uma lista muito clara do que foi completado em um sprint. Se a sua infra-estrutura está realmente madura você deve ser capaz de incluir links para casos de teste e resultados também.

Uma grande parte do avanço de um processo ágil depende de automatizar o máximo possível. Mesmo que você esteja gerenciando itens de trabalho com Notas PostIt, seu código deve ser um sistema de gerenciamento de controle de código fonte e seus builds e deploys para seu ambiente de teste devem ser automatizados. Até que você tenha isso, sua equipe está muito sobrecarregada para fazer isso manualmente para ser verdadeiramente ágil. E uma vez que você tenha isso, ninguém deve ter problemas com a equipe fazendo tantos builds quanto eles precisam para entregar seus sprints.