Deixando tudo mais claro com a Definição de Pronto

Já vimos por aqui que histórias pequenas são de grande valor no decorrer de um ciclo de desenvolvimento. Foi a forma que consegui contornar os sprints plannings de longa duração. Um item que nos ajudou bastante para conseguir deixá-las bem pequenas, foi a definição de pronto. Essa semana irei falar sobre isso :).

Quando falamos sobre esse framework, temos em mente que um dos fatores mais importantes é, justamente, o time de Scrum. É graças a ele, que conseguimos entregar incrementos e deixar todo mundo mais feliz ou com raiva.

E quando pensamos em time de Scrum, estamos falando diretamente de pessoas. Ou seja, cada pessoa é única, com suas crenças, valores e limitações. Devido a esses aspectos, é muito importante deixar evidente o entendimento de qualquer coisa para todos. Pensando por esse lado, temos a definição de pronto pelo guia scrum:

Quando o item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa.

A definição de pronto é um acordo (in)formal entre o time de desenvolvimento e o product owner (PO) para deixar claro o que se espera de uma estória. É através dela que sabemos quais fatores devemos desenvolver em uma funcionalidade para ser entregue como um incremento.

Como eu disse no início do post, trabalhar esse acordo foi de extrema importância para conseguirmos deixar os itens do backlog realmente bem pequenos e factíveis. Mas Diogo, como vocês faziam?

Muito simples. Durante o backlog grooming, o PO deixava claro o que o cliente esperava do próximo item a ser planejado pelo time de desenvolvimento. Depois, durante o sprint planning, o time definia os critérios técnicos necessários para garantir a qualidade daquele item, procurando alinhar com a expectativa do cliente.

Por exemplo, para a funcionalidade de formulário de contato de um sistema estar finalizada, os critérios técnicos devem conter alguns cenários de BDD (behavior-driven development) e testes automatizados. Por outro lado, como critério de negócio podemos citar que a entrega da mensagem do usuário, desse sistema, para o cliente (via e-mail) resultará em um aumento de 2% no lucro da empresa. Baseado nisso, o time sabe exatamente o que tem que ser feito e o PO sabe exatamente o que vai receber do time sem surpresas. Fácil, não?

Recomendo fortemente que a definição de pronto seja vista e pensada para cada estória a ser desenvolvida. Caso essa definição precise mudar ou ser adaptada durante a sprint, é necessário realinhar com todos os envolvidos.

Outra dica importante é deixar para definir esses critérios próximo ao desenvolvimento da estória. Definir tudo no início do projeto é um tiro no pé ;).

Portanto, fica claro a importância da definição de pronto durante o desenvolvimento das funcionalidades. O alinhamento das expectativas, sobre o que vai ser feito e o que vai ser entregue, é essencial e traz benefícios enormes.  Evita que algumas surpresas apareçam para o time no meio do ciclo de desenvolvimento, tendo como resultado a temível hora extra.

Espero que esse post ajude vocês de alguma forma.

Um grande abraço.