Analise de requisitos x Scrum

Oi Decio,

o grooming não é bem uma reunião, mas um trabalho que tem que ser feito pelo P.O. do time, que pode pedir ajuda de peers desenvolvedores.

A origem do backlog é a lista original de requisitos, mas ainda não necessariamente refinados. São vontades do cliente/usuário de resolver um problema que os incomoda, otimizar ou estruturar um processo, ou algo do gênero. Conforme esses itens sobem de prioridade, eles vão sendo analisados e desenvolvidos.

O Scrum não rege sobre quando vai acontecer a Análise e há casos de sucesso de times que fizeram das mais diversas formas. Em ambientes pouco burocráticos, a análise vira uma das fases do Critério de Pronto e, assim, fica dentro da Sprint. Em cenários nos quais a análise leva mais tempo, há times que preferem executá-la one sprint ahead, quer dizer, o P.O. pensa mais que uma Sprint à frente, para que a Análise dos itens de maior prioridade já esteja pronta quando o time for para o Planning Meeting.

Eu, particularmente, prefiro a primeira opção. Primeiro, porque ela é mais simples de gerenciar. Segundo, porque o time trabalha no que realmente vai entregar valor nessa Sprint. E, por último, porque faz com que todos trabalhem para tornar a parte de Análise rápida o bastante para caber dentro da Sprint, o que pode significar descobrir soluções criativas para reduzir o tempo desse processo. :-)

Grato pela excelente resposta. Ainda estou tentando entender a dinâmica do Scrum, tirar a linearidade do meu pensamento. Mas confesso que ainda não está muito claro para mim. Sendo o grooming uma atividade e o backlog uma lista original de requisitos, como nascem estes requisitos? Pelo o que entendi é uma lista "bruta" de vontades e necessiades do cliente, mas que ainda não foram analisadas e modeladas, correto? Estou tentando entender o papel de um analista de negócios / requisitos na metodologia ágil. Mas não está claro para mim esse papel, ou o momento de atuação do mesmo.

Oi Decio, desculpe a demora.

Entendi a questão, agora. :-)

É bem comum que analistas de negócio experientes passem a ser o P.O. do seu time, já que têm uma visão mais completa do projeto como um todo, do valor que cada item agregar ao produto, das dependências entre as funcionalidades e tudo mais. Se pensar nisso é seu trabalho hoje em dia, então a migração natural seria para o papel de P.O.

Há times, no entanto, nos quais o Analista permanece em sua função "tradicional" e atua bastante logo no início da Sprint e vai migrando para outros tipos de trabalho, por exemplo, design nos testes que garantirão que os novos desenvolvimentos funcionem corretamente integrados ao restante do projeto.

Ambas são opções válidas e a definição de qual delas usar apenas depende do seu contexto.

Ficou um pouquinho mais claro? :-)

[]s, Ceci

Fantástico. Muito obrigado pelo esclarecimento

Ótima discussão, ajuda a agregar no treinamento.