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.
Muito bom, Alexandre. Parabéns!
Na minha equipa Scrum utilizamos a DoR, no entanto o PO tem muita dificuldade em colocar as stories INVEST. Procura a equipa para reuniões de grooming muitas vezes e sinto que a equipa perde o foco na sprint atual uma vez que lhes chega informação (e problemas) a mais do que o desejado.
Como ajudar o PO na DoR sem prejudicar a equipa e a sprint?
Viva Daniel,
Primeiramente recomendo investir na educação do PO. Ele deve ser treinado para trabalhar com o Product Backlog, o que inclui técnicas de elaboração, refinamento, manutenção e priorização. Como ele tem dificuldade para colocar as stories como INVEST, recomendo também que o ScrumMaster trabalhe bem próximo dele por algumas Sprints dando coaching no aprendizado desta técnica.
Quanto às sessões de Grooming, é muito importante que ela seja “time-boxed” e que – como falei do post – já tenha dia|horário conhecido por todos, assim o time se planeja para a Sprint já sabendo disso. Por exemplo, PO, Dev Team e SM entraram em um acordo para, a partir da próxima sprint, haver sempre uma sessão Story Grooming de 4hs. no 7o. dia de cada Sprint.
Espero ter ajudado. Abs.
Quais exemplos de técnicas para de elaboração, refinamento, manutenção e priorização?
Obrigado André! 😉
Eu sempre defendo que um time ágil precisa tem alguém no time com um skill muito bom de teste. Esse, pra mim, é um grande gap em Scrum, por exemplo, quando não se tem um “testador”: muitas vezes com a prioridade e velocidade com que se dá o desenvolvimento do backlog esquecemos de questionamentos simples.
Existem diferentes técnicas de testadores ágeis para sanar este gap, a principal é o ATDD [1]
Com ele conseguimos ambas visões: DoR e DoD
[1] http://testobsessed.com/wp-content/uploads/2011/04/atddexample.pdf
Abraços!
Olá Elias, obrigado pelo comentário!
Na verdade este e diversos outros gaps existentes no Scrum são propositais, por isso sua definição como framework, e não metodologia. Scrum é incompleto por definição, pois entende que em sistemas complexos há diversas formas de se construir um produto ou solução, e cada time/empresa tem o seu direito (e necessidade) de escolher e definir o “como” fará isso.
Quando utilizando Scrum em projetos de desenvolvimento de software, concordo plenamente com você: o skill de testes deve existir DENTRO do time, e para isso normalmente é necessário um especialista no assunto. Concordo que ATDD pode ser de extrema ajuda. E sim, um “testador” pode ajudar muito o PO e o Dev Team no alcance da DoR e DoD.
Grande abraço!
Olá Alexandre, parabéns o artigo é muito bom! Este é um problema que estou enfrentando nos projetos, gostaria de esclarecer: nesta afirmativa “Caso ele (P.O.) precise envolver o Dev Team neste trabalho, seria interessante “oficializar” reunião(ões) de “Grooming” que já fossem previstas no TimeBox da Sprint.”, isto significa que eu devo incluir atividades de reuniões na sprint atual (em Dev), para refinamento do backlog da próxima sprint, certo?
Olá Roni, obrigada por acompanhar o Blog Adaptworks. Sobre sua dúvida é resposta direta é sim. Mas além do sim algumas mudanças aconteceram desde a escrita do excelente artigo do Magno, atualmente chamamos as reuniões de discussões de requisitos, que podem estar expressos em User Stories de “Backlog Refinement” (abaixo deixo um link do SAFe sobre o assunto) e independente de uso de frameworks ágeis essa dinâmica entre time e P.O. tem trazido excelente resultados aos times. Pois aumenta entendimento sobre o produto, diminui tempo de discussões na reunião de planejamento e tem boas consequências como aumento de qualidade da entrega e maior engajamento. É normal programar essa atividade de duas a três vezes na semana com duração entre 45 minutos a 01 hora.
Espero ter ajudado!
Read more at: http://www.scaledagileframework.com/team-backlog/
Copyright © 2010-2017 Scaled Agile, Inc.
Request permission to use text and graphics: http://www.scaledagile.com/permissions-form/
muito interessante seus conteúdos gostei muito deles. Parabéns 🙂