Grooming de tarefas no desenvolvimento móvel: o que é, objetivos e processo de condução

O que é grooming de tarefas?

Backlog Grooming (refinamento) é o processo de preparar as tarefas do Product Backlog para sprints futuros. É uma reunião onde o Product Owner e a equipe de desenvolvimento revisam as tarefas: esclarecem requisitos, adicionam Acceptance Criteria, estimam complexidade, identificam dependências e riscos. Não há um evento obrigatório chamado “grooming” no Scrum Guide — é uma prática adicional que as equipes Scrum adotam para reduzir a incerteza no Sprint Planning. A frequência recomendada é uma vez por sprint, com duração máxima de 60 minutos.

O termo “grooming” reflete a essência: a equipe “penteia” o backlog, removendo tarefas obsoletas, esclarecendo as duvidosas e dividindo as muito grandes. No desenvolvimento móvel, o grooming é especialmente importante devido às especificidades da plataforma: uma tarefa para Android pode diferir em complexidade da versão para iOS, sendo necessário considerar targetSdk, compileSdk e compatibilidade com níveis de API. Sem grooming, o Sprint Planning se transforma em caos — a equipe vê as tarefas pela primeira vez e não consegue estimá-las, gerando imprevisibilidade e atrasos.

O resultado do grooming são várias tarefas prontas para o Sprint Planning: têm descrição, Acceptance Criteria, estimativa e atendem à Definition of Ready. O Product Owner deve refinar as tarefas em ordem de prioridade: as mais próximas ao sprint atual devem ser as mais detalhadas. Tarefas para 3–4 sprints adiante devem estar apenas no nível de épico. Técnica de Progressive Refinement: quanto mais próxima a tarefa está do sprint, mais detalhada deve ser sua descrição. Para tarefas do sprint atual — refinamento completo (AC, design, especificação de API). Para tarefas a 2 sprints — nível de história (user story sem detalhes de implementação). Para tarefas a 3+ sprints — nível de épico (apenas nome e valor de negócio).

Definition of Ready: quando uma tarefa está pronta para o sprint

Definition of Ready (DoR) é uma lista de verificação de critérios que uma tarefa deve atender antes de ser incluída no Sprint Backlog. DoR é um contrato entre o Product Owner e a equipe: o PO garante que todas as informações necessárias para o desenvolvimento estão disponíveis, e a equipe garante que pode estimar e concluir a tarefa. DoR não é universal — cada equipe define seu próprio conjunto de critérios. Sem DoR, uma tarefa pode entrar em um sprint com requisitos pouco claros, gerando retrabalho e atrasos.

DoR típico para desenvolvimento móvel: 1) Os Acceptance Criteria estão descritos (formato Given-When-Then). 2) O design está pronto no Figma (para tarefas de UI) com todos os estados: default, loading, error, empty state. 3) A especificação da API está aprovada (OpenAPI/Swagger, exemplos de requisições e respostas). 4) Há estimativa em story points. 5) Dependências de outras tarefas foram identificadas. 6) A tarefa não depende de componentes externos não finalizados. 7) Especificidade móvel: versões alvo do SO definidas, necessidade de feature flag, suporte para níveis de API antigos.

Técnicas de estimativa de tarefas

Planning Poker é a técnica de estimativa mais popular no grooming. Cada desenvolvedor recebe um baralho de cartas com números de Fibonacci (1, 2, 3, 5, 8, 13, 21). O PO apresenta uma tarefa e a explica. Após a discussão, todos mostram sua carta simultaneamente. Se as estimativas diferirem significativamente (por exemplo, 3 e 13), os desenvolvedores explicam seu raciocínio e votam novamente. As iterações se repetem até que haja consenso. O objetivo do Planning Poker não é a estimativa precisa, mas descobrir diferenças no entendimento da tarefa.

T-Shirt Sizing é uma técnica simplificada para estimativas rápidas: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). É adequada para a triagem inicial do backlog quando há muitas tarefas e você precisa de uma ordem de grandeza aproximada. Após o T-Shirt Sizing, uma estimativa mais precisa via Planning Poker é feita para as tarefas do próximo sprint. Affinity Estimation é uma técnica de classificação em grupo onde as tarefas são organizadas em uma mesa da mais simples à mais complexa sem usar números, depois agrupadas em clusters, e cada cluster recebe uma estimativa.

No desenvolvimento móvel, a estimativa deve considerar a complexidade da plataforma. Uma tarefa Android pode ser estimada em 5 SP enquanto a mesma tarefa para iOS pode ser 3 SP (ou vice-versa). Isso é normal: diferentes plataformas têm complexidade de implementação diferente. Dica: estime cada plataforma separadamente se a equipe for multiplataforma. Use uma escala relativa: uma tarefa base (por exemplo, uma tela com texto e um botão) = 1 SP. Todo o resto é relativo a ela. De acordo com a Scrum.org (2025), após 3–4 sprints, a precisão de estimativa da equipe atinge ±20% da complexidade real.

Decomposição: como dividir tarefas grandes

Tarefas maiores que 8 SP devem ser decompostas em tarefas menores. Tarefas grandes não podem ser concluídas em um único sprint, são difíceis de estimar e não proporcionam sensação de progresso. Técnicas de decomposição: dividir a tarefa por camadas horizontais (UI → ViewModel → Repository → Network/DB) ou por fatias verticais (funcionalidade: uma tela completa). A decomposição horizontal funciona melhor para desenvolvimento móvel: Subtarefa 1 — layout de UI (XML/Jetpack Compose/SwiftUI), Subtarefa 2 — ViewModel + State, Subtarefa 3 — Repository + Network, Subtarefa 4 — Testes unitários.

Decomposição vertical — dividir histórias de usuário em histórias menores com valor independente. Exemplo: Épico “Carrinho de compras” → História 1 “Adicionar item ao carrinho”, História 2 “Exibir carrinho”, História 3 “Remover item do carrinho”, História 4 “Finalizar compra”. Cada história tem seu próprio valor de negócio e pode ser lançada independentemente. SPoK (Story Points on Kano): classifique as histórias por valor de negócio (Must-have, Should-have, Could-have) e implemente na ordem de valor.

Lista de verificação de decomposição no grooming: 1) A tarefa é maior que 8 SP? → Decompor. 2) Os Acceptance Criteria estão definidos? → Se não, adicioná-los. 3) Depende de outras tarefas? → Identificar e documentar dependências. 4) Contém incerteza? → Adicionar um Spike (pesquisa) antes da tarefa principal. 5) Precisa de design? → Verificar a disponibilidade dos mockups. Regra INVEST: Independent (independente de outras), Negotiable (pode ser discutida), Valuable (valiosa para o negócio), Estimable (pode ser estimada), Small (pequena), Testable (testável). Se uma tarefa não atende INVEST, ela não está pronta para o sprint.

Processo de grooming: passo a passo

Passo 1: Aquecimento (5 minutos). O Scrum Master lembra a equipe do objetivo do grooming e do DoR. A equipe olha para o quadro e o PO mostra quais tarefas serão discutidas. Passo 2: Revisão de tarefas (30 minutos). O PO apresenta sequencialmente as tarefas do final do sprint atual e do início do próximo. Para cada tarefa: nome, descrição, Acceptance Criteria (se houver), link do design, especificação da API. A equipe faz perguntas esclarecedoras: “Há mockup para o estado vazio?”, “Qual método HTTP?”, “Qual é o minimum deployment target do iOS?”

Passo 3: Estimativa (15 minutos). A equipe estima a tarefa via Planning Poker ou T-Shirt Sizing. Se a discrepância for maior que 2 SP — eles discutem as razões e votam novamente. Regra: se uma tarefa não puder ser estimada (requisitos pouco claros, sem design) — ela é devolvida ao PO para refinamento e retornará ao próximo grooming com esclarecimentos. Não estime tarefas com incógnitas — isso garante erros no sprint. Passo 4: Registro de resultados (10 minutos). O PO registra as estimativas no Jira/Linear, atualiza a descrição da tarefa e define prioridades.

Resultados do grooming: 3–7 tarefas completamente preparadas para o Sprint Planning (com DoR, estimativa, design, API). O PO atualiza o backlog: remove tarefas obsoletas, mescla duplicatas e ajusta prioridades. Importante: o grooming não encerra o trabalho do PO — entre as sessões de grooming, o PO deve preparar as próximas tarefas. Ritmo recomendado: o PO prepara 3–4 tarefas para o grooming e a equipe as trabalha. Se houver mais de 50 tarefas no backlog, o PO deve priorizar (MoSCoW ou Weighted Shortest Job First) antes do grooming.

Diferenças entre grooming e Sprint Planning

O grooming é preparação. Não há compromissos — a tarefa é simplesmente esclarecida e estimada. Sprint Planning é um compromisso. A equipe seleciona tarefas das preparadas no grooming e se compromete a concluí-las dentro do sprint. Diferenças principais: o grooming não está vinculado a um sprint específico (refinamento do backlog como um todo), não há Sprint Goal durante o grooming, e o grooming pode ser realizado a qualquer momento do sprint. O Sprint Planning é estritamente no início do sprint e sempre resulta em um Sprint Goal.

No grooming, as tarefas são apenas estimadas, mas não levadas para o sprint. No Planning, as tarefas são selecionadas do pool preparado. Sem grooming, o Sprint Planning leva de 6 a 8 horas (em vez de 4), porque a equipe vê as tarefas pela primeira vez e não consegue estimá-las rapidamente. Regra 80/20: 80% das tarefas no Sprint Planning devem estar totalmente preparadas (ter passado pelo grooming), 20% podem ser novas (bugs urgentes, hotfixes). Se no Planning mais de 20% das tarefas não estiverem estimadas, o grooming foi insuficiente.

Erros comuns de grooming

Erro 1: grooming uma vez por mês. A equipe acumula tarefas de 3–4 sprints e tenta refinar tudo em 2 horas. Resultado: metade das tarefas fica sem estimativa e o Planning ocupa o dia inteiro. Solução: o grooming deve ser regular — uma vez por sprint, 60 minutos. Se houver muitas tarefas — adicione um segundo grooming no meio do sprint. É melhor refinar poucas tarefas profundamente do que muitas superficialmente. Ritmo: 3–5 tarefas por sessão de grooming, cada uma com discussão e estimativa completas.

Erro 2: estimativa sem contexto. O PO apresenta uma tarefa “Implementar a tela de carrinho de compras” sem design, API ou AC. A equipe estima “de olho” — 13 SP. No Planning, descobre-se que é na verdade 5 SP (porque a tela é simples). Solução: uma tarefa não é estimada se não tiver design ou API. O PO deve preparar os materiais antes do grooming. Regra: “Sem mockup não há estimativa”. Exceção: tarefas Spike — pesquisa de incerteza, são estimadas separadamente sem design (2–5 SP dependendo da complexidade da pesquisa).

Erro 3: grooming se transforma em Planning. A equipe começa a atribuir tarefas a pessoas e discutir quem fará o quê. Solução: lembrar que o grooming é para esclarecer, não para atribuir. A atribuição — no Daily após o início do sprint. O grooming responde “o que fazer?”, o Planning responde “quando fazer?”, o Daily responde “quem está fazendo?”. Misturar essas perguntas em uma reunião reduz a eficácia de cada uma. O Scrum Master deve interromper discussões tipo Planning e redirecionar o foco para o esclarecimento da tarefa.

Erro 4: ignorar a dívida técnica. No grooming, apenas novos recursos são discutidos; tarefas técnicas são ignoradas. Após 3–4 sprints, a dívida técnica se acumula a um nível crítico. Solução: em cada grooming, pelo menos 1 tarefa técnica deve ser estimada. Proporção: para cada 3 funcionalidades → 1 tarefa técnica. Use a métrica Tech Debt Ratio: proporção de tarefas técnicas para tarefas de funcionalidade em um sprint. Valor alvo: 0.25–0.3 (25–30% do tempo em dívida técnica). Se a proporção for inferior a 0.2, a velocidade de desenvolvimento diminuirá nos sprints subsequentes.