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

Gestão: Quando o planejamento orçamentário é uma barreira para o crescimento?

por Alexandre Magno e Gisele Araújo

O grande desafio dos gestores para este século é aprender reconhecer e a lidar com o nível crescente de imprevisibilidade dos mercados. Seja em questões ligadas a recursos humanos ou financeiros e de produção, os líderes de empresas, cada vez mais, precisam estar preparados para gerenciar crises e adaptar-se constantemente às mudanças econômicas e políticas mundiais que refletem diretamente no dia a dia de cada organização.

Para obter o melhor desempenho possível na economia atual, é preciso que as empresas se libertem das amarras que as ligam à gestão comando-controle, principal método de gestão aplicado no País. Este modelo, tradicional, é baseado na previsibilidade, definição de metas fixas e planejamento antecipado; e representa uma barreira para o crescimento, uma vez que não permite a livre adaptação ou mudança durante o curso de um projeto.

Em sintonia com os empresários que procuram formas mais atualizadas de gestão, foi desenvolvida a teoria Beyond Budgeting, também conhecida como Código Beta, que busca libertar as organizações do estrangulamento causado pela gestão comando-controle e pela própria burocracia interna, tornando-as sistemas capazes de interagir de forma sustentável em sistemas complexos, como a nossa sociedade atual.

Atividades que fazem parte do calendário da maioria das empresas como a elaboração de um planejamento orçamentário anual ou a existência de metas fixas, por exemplo, dizem muito a respeito do baixo nível de adaptação à imprevisibilidade delas. Curiosamente, mesmo depois das recentes crises mundiais, muitas empresas ainda dedicam meses à preparação de planos para o ano seguinte, mesmo sabendo que qualquer problema econômico pode inviabilizá-los definitivamente.

Nenhum comentário »

Categorias deste post

Agile