Definition of Ready : Qualidade na entrada das Sprints

Uma reclamação frequente de times de desenvolvimento (Dev Team) em Scrum é que, com o discurso de agilidade, requisitos chegam nas Sprints com baixa qualidade. Não é difícil encontrar Product Owners que mantém no topo do Product Backlog itens com granularidade ruim, pouco (ou nenhum) detalhamento e  – pior – baixo entendimento do próprio Product Owner sobre o que está sendo pedido. Isso, na maioria das vezes, transforma a Sprint Planning Meeting em uma reunião arrastada e com muitas perguntas não respondidas. Consequentemente, times fazem um planejamento de baixa qualidade e são surpreendidos ao longo das Sprints com impactantes descobertas do Product Owner sobre aquele item, o que resulta em mudanças no objetivo e desenvolvimento. Resultado: Time desmotivado. Sprint não consegue atingir meta. Product Owner insatisfeito com o time. Sistema em colapso.

Requisitos Ready se transformam em entregáveis Done

Uma prática que tem ajudado bastante nestes casos é a adição ao Scrum do conceito de “Definition of Ready”. Este conceito age de forma bem parecida com a conhecida “Definition of Done”, mas enquanto “Done” garante qualidade na saída da Sprint, “Ready” garante qualidade na entrada da Sprint.

Enquanto o Dev Team tem o compromisso de entregar ao Product Owner apenas funcionalidades Done, este por sua vez assume o compromisso em manter apenas itens Ready no topo do Product Backlog.

Um exemplo de Definition of Ready

Uma “Definition of Ready” precisa ser capaz de expressar o mesmo significado para todos que a lêem, principalmente Dev Team e Product Owner. Um exemplo:

Um Product Backlog Item está Ready quando:

– Está escrito como uma User Story INVEST;
– Possui um Teste de Aceitação automatizável;
– Possui um Wireframe de baixa fidelidade;

Caso você trabalhe com itens de diferentes tipos no seu Product Backlog, como por exemplo: itens de negócio, itens técnicos, spikes, bugs, etc., você pode optar por ter uma Definition of Ready diferente para cada um deles; afinal de contas pode não fazer sentido gerar um Wireframe para um Spike entitulado “Escolha de solução para Pagamento de Cartão de Crédito”, certo?

Quem tem a responsabilidade de tornar um item Ready?

A responsabilidade é do Product Owner, mesmo que para isso precise envolver outras pessoas. Enquanto o Dev Team trabalha, por exemplo, na Sprint 3, o Product Owner tem que garantir que os itens do topo do Product Backlog estejam Ready para quando da Planning Meeting da Sprint 4. Caso ele precise envolver o Dev Team neste trabalho,  seria interessante “oficializar” reunião(ões) de “Grooming” que já fossem previstas no TimeBox da Sprint.

O uso de “Definition of Ready” não está limitado ao Scrum, e pode ser muito útil também quando trabalhando com Kanban e outros métodos.

Treinamentos da AdaptWorks relacionados ao tema

Certified Scrum Product Owner
Requisitos Ágeis

6 Comentários »

Categorias deste post

Gestão de Produtos, Product Owner, Scrum, Time de desenvolvimento

O ambiente do dia a dia

Outro dia estava conversando com o @jonasabreu e ele comentou sobre a atual fase em que se encontra a consultoria que ele está prestando em uma empresa. Segundo ele, a parte crítica já havia passado, mas que haviam deixado a salinha de “guerra” onde estavam até então para irem para o “salão comunal” – um enorme salão, sem paredes, onde dezenas de outros desenvolvedores trabalham juntos.

Em treinamentos, consultorias, conversas de bar, etc., sempre que falamos sobre ambiente de trabalho para times, sugerimos que seja um ambiente que propicie muita interação. Programação em par. Conversas. E criar este tipo de ambiente nem sempre é fácil.

No caso do “salão comunal”, a interação é muito maior, inclusive com pessoas que não sejam membros do seu time de desenvolvimento, você pode ter a opinião de muito mais pessoas, sem contar a flexibilidade que um local assim proporciona. Mas por outro lado, por ser um ambiente compartilhado por muitas pessoas, fica muito mais difícil satisfazer a todos – questões como temperatura, som, iluminação podem ser bastante controversos.

Um ambiente assim, para mim, seria o caos. Barulho em excesso ou de forma contínua fazem com que eu perca a concentração e até conseguir retoma-la levo um certo tempo e exige uma boa quantidade de esforço de minha parte. No meu caso, o ambiente que temos na AdaptWorks funciona bem melhor: uma sala com uma mesa enorme, onde cabem até 8 pessoas tranquilamente. E muitos quadros brancos.

E você, qual o ambiente no qual melhor se adequa?

2 Comentários »

Categorias deste post

Time de desenvolvimento