Definição de Preparado: Garantindo a Integridade da Sprint Planning

A Definição de Preparado é um artefato utilizado para garantir que os itens a serem considerados na reunião de Sprint Planning estejam preparados segundo um critério bem definido.

O principal resultado esperado das sessões de Refinamento do Backlog do Produto, realizadas pelo Product Owner em conjunto om o Time de Desenvolvimento, é que um número suficiente de itens a serem considerados na reunião de Sprint Planning seguinte esteja preparado para ser desenvolvido.

Esse trabalho de refinamento do Backlog do Produto é realizado, ao longo da Sprint, em sessões agendadas ou esse pode ser um trabalho contínuo.

A preparação é importante para diminuir os riscos de um Sprint mal planejado, já que de outra forma detalhes de mais são deixados para ser discutidos na reunião de Sprint Planning.

Esse trabalho excessivo torna a reunião longa, cansativa e ineficiente, levando-a muitas vezes ao fracasso e colocando em risco todo o trabalho da Sprint.

Definição de Preparado

A Definição de Preparado é um acordo formal entre Product Owner e Time de Desenvolvimento sobre o estado em que um item do Product Backlog deve estar para estar qualificado para discussão na reunião de Sprint Planning.

Caso um dos itens de alta prioridade não chegue à reunião de Sprint Planning preparado de acordo com a Definição de Preparado, o item será rejeitado pelo Time de Desenvolvimento Scrum.

Podemos ver na figura abaixo o fluxo de um item do Product Backlog através de uma Sprint.

Caso o item do Product Backlog esteja preparado de acordo com a Definição de Pronto (trabalho que é feito nas sessões de Refinamento do Backlog do Produto), ele pode ser aceito para apresentação na reunião de Sprint Planning, e consequentemente pode fazer parte da Sprint.

Se, ao final da Sprint, o item estiver pronto e de acordo com a Definição de Pronto, ele é aceito na reunião de Sprint Review e sai da Sprint como parte do Incremento do Produto gerado na Sprint.

Sprint Planning ineficiente

O Product Owner inicia o Sprint Planning apresentando os itens mais importantes do Product Backlog, um a um.

O Time de Desenvolvimento então, que ainda não conhecia esses itens, faz perguntas de todo o tipo, que são prontamente respondidas pelo Product Owner.

Os Critérios de Aceitação de cada item ainda não foram discutidos e, para alguns dos itens, sequer foram criados.

O Product Owner não teve tempo de prepará-los previamente. Como é aprimeira vez que tem acesso a esses itens, o Time de Desenvolvimento também ainda não os estimou.

O Time de Desenvolvimento e o Product Owner então consideram item a item para discutir e preparar os Critérios de Aceitação. É um trabalho detalhado, que gera muitas ideias e discussão e, assim, mais um tempo considerável é necessário para esclarecimentos.

Em seguida à Definição dos Critérios de Aceitação de um item, o Time de Desenvolvimento realiza a atividade de Planning Poker para estimá-lo, de onde surgem novas dúvidas que, novamente, são prontamente esclarecidas pelo Product Owner.

O Time de Desenvolvimento logo identifica que um dos itens mais importantes é muito grande, e que provavelmente deve ser quebrado em itens menores.

Product Owner e o Time de Desenvolvimento então colaboram para dividi-lo, e decidem que uma de suas partes não tem importância para essa Sprint e deve voltar para o Product Backlog.

O Product Owner procura negociar e até mesmo convencê-los a aceitar para o Sprint esse item importante, mas o Time de Desenvolvimento recusa, pois considera muito arriscado que um item com pouquíssimos detalhes faça parte de seu Sprint Backlog.

Essa negociação eleva o nível de estresse da reunião e o Scrum Master, enquanto facilitador, faz o seu melhor para que o conflito seja resolvido.

Após algumas horas de reunião, mais próximo do final do dia, o Time de Desenvolvimento e Product Owner estão exaustos. Tantos detalhes foram discutidos e tantas negociações ocorreram que ambos sentem que o resto da reunião não será mais produtiva.

Os itens que restam são discutidos mais rapidamente e, pelo cansaço, o Time de Desenvolvimento está mais propenso a aceitá-los com uma compreensão menor dos detalhes.

Meta da Sprint ineficiente

Uma Meta para a Sprint é rapidamente negociada, e o Time de Desenvolvimento parte para a segunda parte da reunião, onde quebrará os itens em tarefas. A exaustão toma conta do Time de Desenvolvimento, e o que seus membros mais querem é chegar ao fim do dia.

As tarefas são geradas sem o cuidado e reflexão adequados, e o Sprint Backlog resultante não representa um bom plano para a Sprint. Como consequência, o Sprint é bastante conturbado.

Muitos esclarecimentos são necessários, e uma quantidade grande de novas tarefas são diariamente adicionadas ao Sprint Backlog.

Ao final, o Time de Desenvolvimento não atinge a Meta da Sprint. O que levou o Time de Desenvolvimento ao fracasso nesse Sprint? Será que uma preparação não o teria ajudado?

Formato para a Definição de Preparado

A Definição de Preparado, assim como a Definição de Pronto, tem geralmente o formato de uma lista de critérios ou condições.

Um exemplo comum de Definição de Preparado para um item do Product Backlog pode conter os seguintes tópicos:

• O item deve possuir Critérios de Aceitação, discutidos, compreendidos e acordados entre Product Owner e Time de Desenvolvimento;
• O item deve ter sido estimado pelo Time de Desenvolvimento;
• O item deve ser pequeno o suficiente, de acordo com algum critério estabelecido pelo Time de Desenvolvimento

Assim como a Definição de Pronto, a Definição de Preparado é criada, compreendida e compartilhada por todos os membros do Time Scrum.

Assim, deve-se manter visível para todos eles.

Sobre o autor:

Jefferson Duarte – Gerente de Programas e Projetos na empresa Claro Brasil. Certificaçação PMP®, ITIL® e MCTS® em Microsoft Project. MBA Executivo Internacional em Gerenciamento de Projetos pela FGV e Gestão de Projetos de T.I. pelo IBTA. Pós-Graduado em Tecnologia WEB para Sistemas de Gestão Empresarial. Graduado em Ciências da Computação. Atuação profissional na área de T.I. com Processos e Projetos por mais de 15 anos. E-mail: contato@gp4us.com.br e site: https://www.gp4us.com.br