Definição de Pronto

Os ciclos de inspeção e adaptação do Scrum exigem transparência, a fim de serem eficazes. Formalmente definir o significado de ‘pronto’ reduz a probabilidade de entregar trabalho não feito e aumenta a transparência ao medir o progresso de forma inequívoca (‘pronto’ ou ‘não pronto’).

Uma perfeita Definição de Pronto inclui tudo o que a organização tem de fazer para entregar o produto aos clientes. Alcançar isto deve ser relativamente fácil para um único grupo de produtos. Quando a equipe não é capaz de alcançar a perfeita Definição de Pronto, ela pode definir ‘pronto’ como um subconjunto da definição perfeita. O objetivo da equipe é melhorar de modo que, um dia, a sua Definição de Pronto seja perfeita e ela possa lançar o produto a cada Sprint.

A Definição de Pronto é uma lista acordada de critérios que o software irá atender para cada item do Product Backlog. Atingir este nível de integridade exige que a equipe execute uma lista de tarefas. Quando todas as tarefas são concluídas, o item está pronto. Não confunda a Definição de Pronto com os critérios de aceitação, que são condições específicas que um item individual tem de cumprir para ser aceito. A Definição de Pronto se aplica uniformemente a todos os itens do Product Backlog.

Criando a Definição de Pronto

A Definição de Pronto inicial deve ser acordaao antes do primeiro Sprint. Isso geralmente acontece na oficina de Refinamento Inicial do Product Backlog.

Os seguintes passos devem ser seguidos para a criação da Definição de Pronto:

• Definir as atividades necessárias para enviar aos clientes finais.
• Decidir quais atividades podem ser feitas a cada Sprint.

Vamos explorar estes passos com maiores detalhes.

Definir as atividades necessárias para enviar aos clientes finais

A pergunta-chave é: “Que atividades são atualmente requeridas para lançar o nosso produto?”

• Lançar significa “entregar aos clientes finais” e não “enviar para fora do departamento de desenvolvimento.”
• Desafie a necessidade de artefatos intermediários. Será que realmente precisamos que documento de especificação?

As equipes de escrevem notas em post-its com as atividades necessárias. Estas atividades incluem codificação e testes, mas também podem incluir ambiente de suporte ao cliente, criação de hardware, ou mesmo atividades de marketing. Referimo-nos a essa lista como as atividades necessárias para ter um produto potencialmente lancável.

Com este passo, você criou uma meta perfeita para a organização realizar todas essas atividades para cada item de cada Sprint. Os grupos de produtos frequentemente perceberão que isso vai trazer um monte de melhorias.

Decidir quais atividades podem ser feitas a cada Sprint

A pergunta-chave é: “Considerando nosso contexto atual e capacidade, quais atividades podem ser concluídas cada Sprint?” Este subconjunto é a Definição de Pronto inicial. A Definição de Pronto é fraca quando é um pequeno subconjunto e forte quando ela é quase igual ao Potencialmente Lancável.

As equipes discutem o seu contexto e selecionam o subconjunto das atividades que todas as equipes acreditam ser realisticamente possível fazer durante a Sprint. Esta é a sua Definição de Pronto inicial (ver exemplo na Figura 1). As equipes que conseguirem fazer mais irão expandir esta Definição de Pronto do produto para dentro de suas equipes.

A diferença entre a Definição de Pronto e o Potencialmente lançável é referida como Trabalho Não Feito. A Sprint é planejada de acordo com a Definição de Pronto e assim o Trabalho Não Feito é excluído, ou seja, planejado para ser deixado de lado.

Termos da Definição de Pronto

Os termos Potencialmente Lançável e Definição de Pronto muitas vezes não são utilizados de forma consistente, mas no LeSS eles tem um significado muito preciso. Para esclarecer os termos:

Potencialmente Lançável—Todas as atividades que devem ser realizadas antes do produto ser lançado.

Definição de Pronto—Um acordo entre as equipes e o Product Owner em que as atividades serão realizadas dentro da Sprint. A Definição de Pronto é perfeita quando igual a Potencialmente Lançável. As equipes se esforçam para melhorar no sentido de criarem uma perfeita Definição de Pronto.

Trabalho Não Feito—A diferença entre a Definição de Pronto e Potencialmente Lançável. Quando a Definição de Pronto é perfeita, então não há trabalho por fazer. Se este não for o caso, então a organização tem de decidir, (1) Como podemos lidar com o Trabalho Não Feito, e (2) Como podemos melhorar para que haja menos Trabalho Não Feito no futuro.

Trabalho Incompleto—Trabalho que foi planejado em uma Sprint, mas não foi concluído. Isso é muitas vezes confundido com o Trabalho Não Feito. ‘Incompleto’ é o trabalho que a equipe planejou mas não terminou, enquanto Trabalho Não Feito nunca foi sequer planejado. Quando uma equipe tem um trabalho que não foi concluído, em seguida, eles devem discutir ações de melhoria durante a sua retrospectiva.

Equipes nunca devem deixar o trabalho em andamento ao final da Sprint e “movimentá-lo” para a próxima. Isto provoca uma falta de transparência e reduz a flexibilidade de escopo. Se elas prevêem muito trabalho, então elas precisam remover itens completos que ainda não foram iniciados.

Matemática do ‘Pronto’

Potencialmente Lançável = Definição de Pronto + Trabalho Não Feito
Trabalho da Iteração = Item do Product Backlog * Definição de Pronto

Trabalho Não Feito -> Riscos e Atraso

Primeiramente vamos explorar os efeitos do Trabalho Não Feito atraés de um cenário.

As equipes completaram vinte itens do Product Backlog na primeira Sprint, de acordo com a Definição de Pronto. Elas não têm nenhuma trabalho incompleto, mas há um monte de Trabalho Não Feito devido à sua fraca Definição de Pronto. Depois as equipes completaram quarenta itens do Product Backlog em três Sprints, de acordo com a fraca Definição de Pronto. A quantidade de Trabalho Não Feito cresceu enormemente causando uma falsa sensação de progresso.

Mas elas não podem lançar o produto. Elas estão gerando funcionalidades “prontas”, mas a sua fraca Definição de Pronto causou uma grande quantidade de Trabalho Não Feito acumulado. Este Trabalho Não Pronto provoca atrasos e riscos ocultos.

Atrasos—Esforço extra é necessário para realizar o Trabalho Não Pronto. Isso gera uma falta de flexibilidade para o Product Owner, pois ele não pode responder diretamente às necessidades do mercado e mudanças. A dor causada por este atraso é agravada pelo fato de haver alta variabilidade e imprevisibilidade dos esforços necessários para completar o Trabalho Não Pronto.

Riscos—O Trabalho Não Feito provoca uma falta de transparência e gera riscos ocultos. Por exemplo, se o teste de desempenho é deixado de lado aumenta-se o risco de entregar um sistema com baixo desempenho.

Um bom Product Owner quer uma perfeita Definição de Pronto para reduzir o risco do produto e evitar atrasos.