Imagine o seguinte: você precisa preparar uma refeição.
Alguém lhe informa que você tem 60 minutos para concluir a tarefa, e ao final, a refeição precisa estar pronta na mesa de quem vai comê-la.
Mas trata-se de uma refeição que você nunca fez antes.
E para fazê-la você precisa de: receita bem detalhada, ingredientes disponíveis e com qualidade, facas e colheres necessárias para o preparo.
Mas você não recebe o que precisa, e mesmo assim aceita fazer a refeição. 🙁
Qual será o resultado do seu trabalho?
Definition of Ready (DoR) – A importância do item Ready no Scrum
Em times que rodam Scrum como framework para desenvolvimento existe um rito chamado Sprint Planning.
Nesse rito espera-se que o Product Owner (PO) – em times que possuem este papel – forneça o escopo que será produzido no Sprint.
Esse escopo deve ser uma “fatia” do Backlog do Produto (Product Backlog) com itens detalhados, priorizados e “preparados o suficiente” para o Dev Team (Devs de um time Scrum) desenvolvê-los.
Cada item de backlog que o PO vai incluir para o time para planejar o trabalho do sprint precisa estar “Ready To Dev” (pronto para ser desenvolvido).
Eu prefiro chamar de o “ready” de “preparado”, porque gera confusão com a DoD (Definition of Done), que é a definição de item pronto, concluído. Então entenda Definition of Ready também como “Definição de Preparado”
Uma Definição de “Preparado” viabiliza que apenas escopo pronto para se desenvolvimento – Ready – entre no Sprint.
Importante lembrar que o Dev Team não tem obrigação de aceitar itens não Ready na Sprint Planning. Na realidade a obrigação é não aceitar, afinal, o combinado não sai caro, mas também não sai barato. Se o time aceitar itens não Ready e não entregá-los no fim do sprint, complica… 🙂
A Definition of Ready (DoR) é um conjunto de “combinados” entre o Scrum Team (PO + Devs + SM) que cada item de backlog que vai para uma Sprint Planning deve atender.
Os itens de backlog que atendam a DoR são itens Ready.
É comum dizer que “item que entra Ready no sprint sai item Done”.
Isso quer dizer que, se o item de backlog entra com a qualidade necessária no sprint, a probabilidade dele ser concluído no sprint aumenta muito.
DoR por Produto, Item de Backlog, Sprint, Time ou Projeto?
A Definition of Ready (Dor) é um check que cada item do backlog do sprint vai passar por ele, para garantir que está no nível que precisa antes de começar a ser feito.
Muitos profissionais ficam na dúvida se a DoR deve ser por Produto, Item de Backlog, Sprint, Time ou Projeto.
É mais o menos o seguinte:
- Por Produto: para o Produto A tem uma DoR e para o produto B tem outra DoR.
- Por Item de Backlog: para a User Story X tem uma DoR e para a User Story Y tem outra DoR.
- Por Sprint: para o Sprint 1 tem uma DoR e para o Sprint 2 outra DoR.
- Ou todas essas variações combinadas.
Cada cenário é cada cenário, mas eu acho melhor assim:
- Uma DoR por time, que deve ser reavaliada Sprint a Sprint (melhoria contínua), e no detalhe dela colocamos especificidades por tecnologia, tipo de item de backlog etc. se for necessário.
Exemplos de Definition of Ready (DoR)
Vejamos dois exemplos de DoR, em dois contextos diferentes.
Cenário 1 – Time Web de E-Commerce
- User Stories de interface gráfica com ok do UX.
- User Stories de interface gráfica com Wireframe desenhado e anexado.
- Todos os itens (User Story, Spike ou item técnico) com Critério de Aceite.
- Todos os itens (User Story, Spike ou item técnico) não podem ter tamanho de camisa maior que G (equivalente a 5 Story Points, por exemplo).
- User Stories que tocam o módulo de pagamento ou faturamento devem ter descritos nos Critérios de Aceito os cenários de teste que devem ser executados e regras de negócio especificadas.
- User Stories devem ser INVEST.
- Todos os itens (User Story, Spike ou item técnico) devem ter sido refinados previamente com a área de negócio e time técnico.
Cenário 2 – Time de BI e Analytics
- User Stories de relatório com ok do UX.
- User Stories de relatório devem possuir os scripts de carga para testes anexados.
- User Stories de relatório devem ter filtros e níveis de grão especificados.
- User Stories de ETL especificar quais as fontes/destino de dados e tabelas para extração e para gravação.
- Todos os itens (User Story, Spike ou item técnico) ter o Requisito Não Funcional de Performance contendo o tempo de processamento esperado.
- Todos os itens (User Story, Spike ou item técnico) com Critério de Aceite.
- Todos os itens (User Story, Spike ou item técnico) não podem ter tamanho de camisa maior que G (equivalente a 5 Story Points, por exemplo).
- User Stories devem ser INVEST.
- Todos os itens (User Story, Spike ou item técnico) devem ter sido refinados previamente com a área de negócio e time técnico.
De repente você vai pensar assim: puxa Plínio, mas não tem muito rigor nos seus exemplos? Sim, tem um pouco. Mas o combinado não sai caro. Fazendo certo, dá certo. Salvo em times muito maduros (+ 2 anos de perenidade e com mindset ágil já no DNA) a ausência desse rigor sempre causa problemas.
Quem é responsável pela DoR?
Em times Scrum os papeis e responsabilidades precisam estar claros.
Importante lembrar que falamos a todo momento “time”, ou seja, não é um jogo de “acabei minha parte agora é com o outro”.
Garantir que o uso da DoR está funcionando é responsabilidade de todos.
- O PO (Product Owner) tem a responsabilidade de garantir que os itens estejam Ready ao traze-los para Sprint Planning.
- O Dev Team tem a responsabilidade de somente aceitar itens Ready.
- O SM (Scrum Master) tem a responsabilidade de garantir que o Scrum Team saiba do que se trata e está aplicando da forma correta.
- Todo o time tem a responsabilidade de garantir que tem uma DoR que todos estejam de acordo, que ela esteja sendo usada de fato e que a cada Sprint a DoR é revisitada para ajustes necessários.
É isso!
Qualquer dúvida, crítica ou sugestão, fique à vontade nos comentários! 😉