Exemplo, digamos que uma historia requer uma funcionalidade complexa que pode demorar mais de uma semana para ser analisada, desenvolvida e entreque, mas existem outras diversas historias que são bem menores. Como gerir isto nas reuniões de sprint e diárias?
hoje, com a Alura e o Google Gemini
Uma prática para resolver isso, é dividir a entrega da funcionalidade maior em alguns sprints mas em cada sprint adicionar funcionalidades menor.
Por exemplo, vamos supor que o time consiga entregar 20 pontos e a funcionalidade maior tenha sido estimada em 25 pontos, em geral evitamos fazer um sprint apenas com uma historia, entao poderiamos quebrar a entrega da funcionalidade em 2 ou 3 sprints e adicionar funcionalidades menor aos sprints. Dessa forma na entrega do primeiro sprint apresentariamos as historias menores e dariamos um report de como anda o desenvolvimento da historia maior. Nas dailys não mudariamos nada, apenas teria que ter mais cuidado para conseguir manter o controle da historia maior, ou seja evitar que o status da historia maior seja sempre iterativo e nao repetitivo.
Respondendo a pergunta considerando um pouco mais o Scrum, tenho os seguintes itens:
Paulo, boa noite.
Na sua citação, o item 3 diz que "Todo Incremento deve ser funcional e ...".
Minha dúvida é: os requisitos não funcionais não poderiam também ser incrementos se validado o devido valor agregado ao cliente pela equipe?
. . .
Quando digo deve ser funcional eu não estava me referindo aos tipos de requisitos funcionais e não funcionais, quis dizer que o Increment deve estar em condições de uso atendendo a Definition of Done. Mas você está certa na sua indagação. Apesar dos requisitos não funcionais serem normalmente colocados na DoD, eles também podem estar presentes no Product Backlog.
Paulo, bom dia.
Correto. Compreendido. Você quis diz requisito em conformidade. Agradeço por postar e aprender o significado de DoD: Definition of Done.