menu

Dissecando o Grooming

Por

“Like a garden growing wild when left unattended for too long, the product backlog becomes unwieldy when it’s neglected.”
Roman Pichler

O que é (propósito)

Grooming, em inglês, significa Preparar. Logo, o grooming nada mais é que um ou vários momento(s) específico(s) em que se iniciam os preparativos para o próximo sprint ou release. Enquanto o time trabalha na sprint atual, o Product Owner (PO), com mais alguns convidados de seu interesse, começa a refinar e amadurecer as histórias e objetivos da próxima sprint ou release. Você pode encontrar o termo Pré-planning também, referenciando o mesmo momento.

Contexto

Como sabemos, uma das responsabilidades do PO é refinar o Product Backlog de modo que os Product Backlog Items (PBI), ou Itens de Backlog do produto, estejam adequados à Definition of Ready (DoR). Acontece que apesar de ser responsabilidade do PO fazer este refinamento do Backlog, ele não é obrigado a fazer isso sozinho.

Muitas cerimônias de Planning (Planejamento) podem acabar sendo pouco efetivas, em geral isso se dá pelo fato do Product Owner (PO) não ter preparado adequadamente os itens de backlog candidatos a fazer parte da Sprint que se inicia. Durante o planning, inclusive, acontece do PO perceber que não possui resposta a algumas perguntas da equipe, forçando-o ou a deixar para um próximo Sprint ou a alterar o Sprint Backlog durante o Sprint, o que não é aconselhável no Scrum e dependerá de um OK do Dev Team para isso.

Participantes

O PO e quem mais ele achar interessante para ajudá-lo. Ele pode envolver o Dev Team ou parte dele, o Scrum Master (SM) e/ou outras pessoas com o expertise necessário. Vale ressaltar que é uma opção do PO se ele precisa de uma reunião de grooming e quem ele utiliza para ajudá-lo.

Como funciona

O Product Backlog possui itens em vários estágios de granularidade e detalhamento. Em geral, vai se formar uma espécie de Iceberg, que pode ser dividido em três partes:

image00

  • O Sprint: terá itens bem detalhados, granulares, de grande importância e que atendem ao DoR, o que em geral significa que são itens INVEST – Independent (Independentes), Negotiable (Negociáveis), Valuable (de Valor), Estimable (Estimáveis), Sized appropriately or Small (De tamanho apropriado) e Testable (Testáveis).
  • A Release: terá itens de tamanho médio, e não muito detalhados.
  • Próximas Releases: apresenta itens pouco granulares, de menor importância e pouco ou nada detalhados.

Assim, caso o PO acredite ser uma boa opção envolver o Dev Team, é fundamental criar uma cadência para as reuniões de Grooming (ou de refinamento). Deve haver um encontro, mais frequente, para transformar alguns PBI do bloco da Release em itens do Sprint e outro encontro, menos frequente, para preparar alguns PBI para entrar em uma Próxima Release.

Durante o Grooming, novos itens podem ser descobertos e descritos, assim como os existentes podem ser alterados ou mesmo excluídos. O Grooming também pode servir para o Dev Team começar a estimar os itens do backlog.

Lembre-se, como praticamente tudo que ocorre no Scrum, sendo ou não parte integrante dele, deve ser Timeboxed.

Resultado

O Product Backlog priorizado, com os itens mais relevantes decompostos e detalhados adequadamente.

Conhecimentos importantes

Em nenhum momento até aqui citei Histórias de Usuário (User Stories), pois elas também não fazem parte do framework Scrum, apesar de serem o padrão para representar os Itens de Backlog do Produto. Um conhecimento importante relacionado à análise é o de como escrever boas Histórias de usuário, planejar testes para validá-las e saber como quebrá-las em Histórias menores.

Problemas ou contra partidas

Caso o PO realmente decida utilizar o Dev Team, gasta-se uma pequena porção do Sprint com uma atividade não ligada à meta do Sprint, ou seja, o foco é desviado. Fora a possibilidade dos itens em discussão neste Grooming serem muito diferentes do que se está trabalhando, principalmente quando o assunto for próximas Releases.

Se a opção for fazer o Grooming mais frequente é importante verificar o nível de energia e de foco de todos, pois muitas reuniões seguidas podem se tornar contra-produtivas e desgastante para o time.

About the author: Leonardo Campos

Leonardo Campos trabalha na área de TI desde 2000, atuou boa parte deste tempo como desenvolvedor Java, mas também desenvolveu profissionalmente com Ruby, .NET, VB, PHP e ASP. Desde do começo de 2009 vem atuando com Agile e hoje trabalha na ThoughtWorks Brasil. É estudioso de processos e entusiasta de Lean e Agile, sendo um dos organizadores do Lean Coffee São Paulo e editor da InfoQ. Leonardo é advogado por formação (Universidade Presbiteriana Mackenzie).
LinkedIn
@leonardocampos

8 comments

  1. Nana

    Acredito que o papel do BA é ajudar o PO nesta tarefa, muitas vezes puxando a prática, já que o PO pode ser uma pessoa de negócio sem conhecimentos de projetos ágeis.

    Posted on abril 23, 2015
    • Leonardo Campos

      Olá, Nana,

      Acho que você tem razão.

      O Scrum, naturalmente não prevê nenhum papel além dos 3 básicos. Desenvolvedor, Scrum Master e Product Owner (PO).

      Isso não significa que o PO, por exemplo, seja obrigado a fazer tudo sozinho. Como entendo que qualquer função contida em um papel possa ser delegada para outra(a) pessoa(s), vejo que um papel que surge naturalmente em muitos ambientes é o do Analista de Negócios (BA).
      Ele acaba recebendo do PO várias de suas funções, podendo ser uma delas a de fazer o Grooming do produto ou só de auxiliá-lo nesse trabalho.

      O receio que tenho, apenas, é o grau de afastamento do Product Owner se ele delegar completamente essa função (Vc já viu os “quadros de delegação” do livro do Jurgen Appelo — Gestão 3.0 Workout?).

      Posted on abril 23, 2015
      • Armando Mancilla

        Acredito que o BA possa ser fundamental especialmente na interpretação dos itens de backlog e também priorização.

        Muitas vezes o PO foca muito na produtividade do desenvolvimento e cumprimento de prazos, não tendo oportunidade de se aprofundar nos requisitos de negócio.

        O BA vem para suprir esta lacuna, suportando o PO para ajudá-lo a priorizar os itens do backlog com base nas necessidades de negócio e até mesmo auxiliando na interpretação dos requisitos, para que não se perca tempo desenvolvendo algo que foi mal interpretado no início.

        É a prova de que BA e analista de requisitos ou PO podem conviver em perfeita harmonia, e mais, se bem organizado, podem se complementar de uma forma extremamente benéfica para a empresa, que poderá ter muito mais qualidade e assertividade no desenvolvimento de seus produtos.

        Posted on março 21, 2016
        • Leonardo Campos

          Armando, vc tem razão em tudo que falou.
          Só deixo uma pergunta:
          Vc não acha problemático que o PO, justamente quem deveria estar preocupado com o Produto, esteja mais focado na produtividade e cumprimento dos prazos?

          Posted on março 22, 2016
          • Diana Fournier

            Não deveria né? AFinal o PO é o responsável pelo ROI do produto, ou seja, a entrega de valor daquilo. E isso nem sempre tem a ver com produtividade. Muitas vezes produzir muito não quer dizer qualidade.

            Posted on maio 3, 2016
          • Alan Silva

            Além de problemático, acredito que seja um erro. Produtividade e cumprimento dos prazos não seria tarefa do Scrum Master?

            Posted on agosto 19, 2016
  2. Pingback: Os top 10 artigos no Kudoos em 2015 | Kudoos

  3. Pingback: 3 equívocos sobre Agile que ainda estão entre nós | Kudoos

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top