As metodologias ágeis de gestão de projeto não estabelecem uma regra para o levantamento de requisitos no começo de cada iteração. De acordo com o SCRUM após as reuniões de Sprint Planning a equipe deve possuir um Sprint Backlog estimado e priorizado em conformidade com o que o Product Owner e a equipe do projeto acreditam que deve ser executado na Sprint atual. Durante essas reuniões, o time inteiro e o Product Owner são incitados a tirar dúvidas e levantar mais detalhes em relação a cada User Story que foi selecionada como escopo da Sprint, porém não há nenhuma recomendação sobre formas de propagar requisitos ou até mesmo descrevê-los.

Como os próprios métodos ágeis pregam, devemos tentar fugir ao máximo de documentos e artefatos que pouco agregam ao time. Se no seu caso, as reuniões de Sprint Planning e conferências com o Product Owner são suficientes então nem continue lendo esse post. A nossa proposta é sugerir formas de manter esses requisitos na mente dos desenvolvedores e também trabalhar mais a fundo essas propostas, de forma a estimular a criatividade da própria equipe e disseminar o conhecimento dos requisitos.

A primeira técnica que já utilizei foi o famoso gravador de voz. Durante as reuniões com o cliente, levávamos um gravador MP3 para registrar todos os momentos com o Product Owner. O arquivo era posteriormente distribuído através do repositório da projeto. Os desenvolvedores e o Scrum Master sempre poderiam revisitar o arquivo de áudio e esclarecer possíveis dúvidas que surgem após um determinado tempo.

A segunda técnica consiste em utilizar um membro da equipe para, após as reuniões de planning, criar uma apresentação com uma visão geral sobre cada requisito/user story e seus impactos. A grande vantagem dessa abordagem é a subsequente reunião que é feita após a definição desses requisitos. Todos os membros da equipe são encorajados a refinar os requisitos e a discutir de forma criativa as soluções que foram dadas aos problemas. Inclusive pudemos observar que a participação de engenheiros de teste foi bastante útil uma vez que eles são capazes de antecipar com maior critérios os fluxos secundários e os impactos de cada User Story no que já foi desenvolvido.

Existem várias outras possibilidades como o uso de vídeos, combinação de ténicas acima, uso de cartões e etc… O que realmente importa é garantir que  a todo momento todos os membros da equipe têm claro o que devem fazer e o que deve ser coberto ou não por cada estória a.k.a definição de pronto.