Como elicitar/registrar regras de negócio para cada história

Bom dia Abner!

A função das histórias de usuário é definir o que o usuário precisa, e não como será feito em detalhes.

https://pt.wikipedia.org/wiki/Hist%C3%B3ria_de_usu%C3%A1rio

"Em desenvolvimento de software e gerenciamento de produto, uma História de usuário (User Stories) é uma especificação de uma ou mais sentenças na linguagem de negócio ou cotidiana do usuário final ou usuário do sistema que captura o que um usuário faz ou necessita fazer como parte de sua função de trabalho. Histórias de usuário são usadas com metodologias ágeis de desenvolvimento de software como a base para definir o escopo de um projeto de software.[1] É uma técnica de análise de requisitos. Ela captura o "quem", "o quê" e "por quê" de um requisito em uma forma concisa e simples, geralmente limitada em detalhes, de forma que possa ser escrita a mão em um pequeno cartão de notas de papel."

Não sei dizer se o Scrum define um padrão ou recomenda alguma maneira de definir / entender as regras de negócio, imagino que não. Sua equipe vai criar a maneira dela de fazer as coisas.

As regras de negócio e condicionais serão detalhadas quando a história for desenvolvida. Apareceu uma dúvida sobre alguma determinada regra? É só consultar o P.O. e/ou o cliente. Há casos onde nem o P.O. sabe em detalhe da regra, só quem faz a atividade a conhece em detalhes.

Não se esqueça dos princípios do Manifesto Ágil!

http://www.manifestoagil.com.br/

"...passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas.

Software em funcionamento mais que documentação abrangente.

Colaboração com o cliente mais que negociação de contratos.

Responder a mudanças mais que seguir um plano."

As histórias de usuário são elaboradas pelo ou a partir do Product Owner já que ele, inicialmente, é quem tem maior conhecimento do negócio. Porém, na literatura, recomenda-se até que o time de desenvolvimento crie suas histórias. Como o conhecimento do negócio vai se disseminando ao longo do tempo, é possível que isto ocorra de forma natural.

A elicitação no Scrum, se dá de forma às vezes explícita, às de vezes de forma implícita e começa desde o pré-jogo ("Sprint 0") até durante as iterações (principalmente, durante as reviews onde ocorre feedback das entregas). Quando o negócio não está claro, até mesmo para o P.O., é possível que ocorra reuniões com os usuários para se tirar tais dúvidas. É possível até mesmo que o time acompanhe. Não há esta visão de que o DevTeam não deva entrar em contato com os usuários. Isto só não é permitido quando os usuários entram em contato com os usuários para fazer demandas.

Já o registro dos requisitos é feito com as histórias de usuário e, onde muitos negligenciam, os critérios de aceite, que são igualmente importantes. Muitos requisitos podem ser adicionados como critérios de aceite.

Em alguns casos, onde existe muita complexidade de negócio ou há arquivos anexos estes podem ser guardados em wikis corporativas. Mas não deve ser tomado como regra. Exceção da exceção.

Lembrando que a documentação ágil só tem valor a partir dos 3 C's (cartão, conversação, confirmação).