O Product Owner é o principal responsável pelo Product Backlog. Quando já há uma boa maturidade com o Scrum, a equipe de desenvolvimento e seu Scrummaster recebem, do Product Owner, o Product Backlog com o qual trabalharão. Na maioria dos casos, porém, não é isso o que acontece.
Você ouvirá algumas coisas boas e ruins sobre o Sprint Zero. Eu só falarei de coisas boas. Uma das coisas que valorizo muito no Extreme Programming é a máxima Fix XP when it breaks, ou seja, se a metodologia não está funcionando, conserte a metodologia! O Sprint Zero pode parecer uma anomalia, já que ele não implica em nenhuma entrega incremental para o produto, mas eu acho que ele é extremamente importante na criação e incentivo da cultura Scrum dentro de um projeto ou uma empresa. Em resumo, o Sprint Zero coloca o espírito do Scrum em ação antes de o Scrum começar. Além disso, ele já destaca o papel do Scrummaster como o facilitador, incentivador e fiscal dos processos e das ferramentas sociais do Scrum desde o princípio, com o apoio necessário e fundamental dos patrocinadores do projeto. Você lerá mais sobre o Sprint Zero mais adiante. Por enquanto, basta você saber que a apresentação do Product Backlog para a equipe é uma das coisas que acontecem nele.
Nesse exercício, você será o Product Owner, iniciando a prática do Scrum em um novo projeto, com um novo cliente. Você seguiu minhas recomendações e leu o livro, linearmente, até aqui. Seu cliente (que pode ser a sua própria empresa, organização, escola ou até sua família) está convencido de que “o grande contrato” nunca funcionou e está disposto a tentar pôr em prática a sua ideia de estabelecer um projeto de desenvolvimento ágil. Exija uma reunião com a participação de todos os que serão beneficiados pelo novo projeto e faça o seguinte:
- Apresente a ideia original do projeto, aquela que seu contratante ou principal patrocinador passou para você. Coloque essa ideia como o ponto central em um quadro branco para, a partir dela, começar a criar o mapa mental do que será construído (pode ser um produto, um novo software, um evento, qualquer coisa).
- Divida seu público-alvo em equipes de, no máximo, quatro pessoas e forme, no mínimo, três equipes. Você provavelmente vai querer que a contribuição de ideias seja a mais ampla possível, por isso, procure diversificar bem os grupos. Especialmente, faça com que o pessoal de marketing e os nerds de TI estejam bem misturados com os grupos de usuários. Por exemplo, se você tiver 12 pessoas à sua disposição (e esse é um bom número), forme três grupos de quatro pessoas – quanto mais diversificados em talentos, melhor.
- A partir da ideia central, peça que as pessoas do grupo escrevam, em notas adesivas, o que elas gostariam de ver desenvolvido. Cada pessoa fará essa tarefa individualmente.
- Em cada grupo, peça que escolham entre três ou quatro histórias que gostariam que fossem priorizadas. Use seu julgamento: se os grupos escreveram muitas histórias, permita que selecionem cinco ou seis a serem priorizadas.
- Dentre as histórias priorizadas, olhe para cada componente dos grupos, no fundo de seus olhos, e diga a eles que só uma história será executada: aquela pela qual eles dariam suas vidas.
Parabéns! Você acaba de construir seu primeiro Product Backlog. É claro que, nesse exercício relâmpago, boas ideias podem ter ficado de fora. Porém a equipe teve um saudável choque de priorização. É comum, em exercícios assim, que a equipe de TI, já antevendo o que terá de desenvolver, queira priorizar tarefas do tipo “criar o modelo para a base de dados”, “definir quais as ferramentas de gestão de conteúdo a serem utilizadas” e outras coisas que são necessárias, mas que estão fora do domínio daqueles que se beneficiarão do que será desenvolvido. Essas tarefas necessárias, mas não aparentes, devem entrar no detalhamento das fases para o desenvolvimento das histórias do Sprint Backlog, mas não precisam estar no Product Backlog, que é uma visão de mais alto nível do que será desenvolvido.
Uma variação desse exercício, de que eu particularmente gosto, é pedir que as pessoas escrevam, em notas adesivas, o que querem como resultado do projeto antes de discutirem umas com as outras. Cada etiqueta deve conter apenas uma ideia, uma necessidade ou um desejo. Isso deve ser feito em um tempo curto, no máximo, 15 minutos. Depois disso, agrupo as notas em um quadro, buscando juntar ideias similares ou complementares. Redistribuo, então, as notas entre as equipes (as ideias de todo o grupo estarão misturadas) e peço que, como no exercício anterior, escolham entre quatro ou cinco ideias que consideram mais importantes. Afinal, faço uma repriorização, com a participação de todo o grupo, com o auxílio do Poker do Planejamento, ou Scrum Poker.
