Reflexões sobre o Scrum Parte 3 – Artefatos

Conforme o Guia do Scrum, os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. Eles são projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos. Com isso percebemos a importância dos artefatos e o motivo pelo qual eles devem estar claros e visíveis para todos.

Backlog do Produto

O backlog do produto é uma lista ordenada de tudo que já sabemos ser necessário para o produto. Ele é a única origem de requisitos, melhorias ou correções que serão implementados no produto. A responsabilidade de mantê-lo em ordem e com informações suficientes é do Product Owner. Este artefato é dinâmico e evolui junto com o produto, afim de que este se torne mais competitivo e aderente as necessidades do cliente. Isso significa colher feedbacks constantes tanto do mercado quanto dos clientes para realizar os ajustes necessários no nosso produto, além de estar atento a novas tecnologias e oportunidades de negócio que possam interferir positiva ou negativamente na estratégia de evolução do produto.

Um backlog do produto de qualidade é uma lista que está constantemente sendo revisada e refinada, sendo que o topo dessa lista deve ser composto de itens mais claros e detalhados do que os demais, pois são os itens candidatos a serem desenvolvidos. Parece simples, mas é uma tarefa árdua para o PO que, com certeza, precisará de muito apoio do time de desenvovlimento para dar conta do recado. Scrum é sobre transparênca, inspeção e adaptação, podemos ver cada um desses conceitos na prática quando o PO e os membros de um time trocam ideias e compartilham suas incertezas na busca de um produto de sucesso.

O Guia do Scrum cita que atividades de refinamento usualmente não consomem mais que 10% da capacidade do time, mas isso não significa que devemos ter reuniões de refinamento com a quantidade de horas exatas para atender a esse ponto, um processo empírico implica em uma abordagem orgânica de quanto tempo é necessário para realizar essa atividade. Trabalhei com times que faziam duas reuniões de refinamento por Sprint e com times que sequer marcavam uma reunião assim, pois atuavam, time e PO, bem próximos no dia a dia, não sendo necessário um momento formal para essa discussão. Para este e muitos outros pontos sempre recomendo fazer um experimento, inspecionar e adaptar o que for necessário para melhorar, sempre levando em consideração o momento e as características do time.

O refinamento é que garante que os itens do topo do backlog estarão preparados para entrar no planejamento da Sprint. No Guia do Scrum, temos uma definição dos atributos que os itens do backlog devem possuir, são eles: descrição, ordem, estimativa e valor, além disso, geralmente há descrições de testes que auxilirão na hora de veririfcar que o item está realmente pronto. Lembrando que as estimativas sempre devem ser realizadas pelo time de desenvovolvimento. Essa é uma questão interessante, que deixa claro que o Scrum foi concebido considerando a perspectiva do desenvolvedor que, em metodologias tradicionais de desenvolvimento de software, não tinha voz sobre esse ponto.

No encontro do grupo de estudos, fizemos uma dinâmica para exercício da priorização do backlog que incluia discutir os atributos benefício, receita, redução de risco e estimativas. Foi bem interessante, pois tivemos a oportunidade de abordar cada uma dessas informações e como elas afetam a evolução do produto. Devido ao curto tempo do nosso encontro, não exercitamos fatiar e descartar itens que são atividades indispensáveis no dia a dia do PO, mas falamos um pouco sobre a granulalidade do backlog e de como isso deve ser administrado.

Obrigada aos colegas Altamir Dias, Josiel Lilge, Liliane Soares, Cleidi Rocha, Samanta Azevedo, Julia Iense, Vanessa Paes, Alina Melo, Elza de Souza, Victor Fofonca, Cícero Vieira e Marcelo Lora por participarem dessse grupo incrível.

Backlog da Sprint

Este artefato contém um subconjunto do Backlog do Produto, indicando quais funcionalidades estarão prontas ao final do Sprint. Os critérios para selecioná-los são decididos pelo próprio time Scrum. Para ajudar na identificação dos itens que deverão fazer parte desta lista, sempre sugiro o uso de uma definição de preparado, onde constarão todos os atributos essenciais para que um item possa ser promovido do Backlog do Produto para o Backlog da Sprint.

A definição de preparado, apesar de não ter um item específico no Guia do Scrum, é uma prática que apoia na identificação e aprimoramento da qualidade das informações de cada item do backlog, aumentando a fluidez do trabalho do time de desenvolvimento. Não ter uma lista clara de critérios para seleção de itens para compor o Backlog da Sprint pode acarretar falta de entendimento do trabalho, reuniões de planejamento muito longas onde os requisitos chegam com pouca clareza ou com granularidade inadequada, além de desmotivar o time e gerar dúvidas sobre a eficicácia do processo de trabalho.

O Backlog da Sprint também contém o plano de como o time irá atingir o objetivo da Sprint, esse plano pode ser (e provavelmente será) ajustado ao longo da Sprint, pois o time vai aprendendo mais sobre o trabalho a medida que progride nas atividades. Esse é um ponto bem importante, pois vemos muitos times “Scrum” sendo obrigados a definir todas as tarefas da Sprint na reunião de planejamento como se neste momento fosse possível prever exatamente todo o trabalho que será feito. Esse tipo de situação, além de não favorecer em nada o empirismo e auto organização, ainda resulta em plannings muito longas e que não mantém a atenção dos membros do time.

Abaixo, o trecho do Guia do Scrum que menciona claramente esse comportamento:

“Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do trabalho
restante é atualizada. Quando elementos do plano são considerados desnecessários, eles são
removidos. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a
Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o Time de Desenvolvimento planeja completar durante a Sprint, e que pertence exclusivamente ao Time de Desenvolvimento.”

Vale destacar que é fortemente recomendado que no mínimo um item de melhoria do processo priorizado na retrospectiva seja incluído no Backlog da Sprint. A falta deste item implica em estagnação do time e inutilidade da reunião de retrospectiva, onde as ações são parte essencial para garantir a melhoria continua como já foi citado no artigo Dicas para Retrospectivas Eficazes.

Incremento

O incremento é a soma do itens que foram completados na Sprint, ou seja, que estão prontos. Pronto é uma definição que pode ser diferente de time para time, porém deve ser clara para todos os interessados. Um incremento pronto não precisa necessariamente ser liberado para uso, mas o Guia do Scrum deixa bem claro que ele deve estar nessa condição, ficando a critério do Product Owner decidir a estratégia para liberação do uso dos incrementos.

A definição de pronto garante a qualidade da saída dos itens da Sprint e o alinhamento do trabalho necessário para concluir uma funcionalidade. A falta de uma definição de pronto clara e visível para todos implica em entregas incompletas ou de baixa qualidade, formação de silos, desmotivação e descrédito do processo de trabalho. Tudo isso ocorre porque num grupo existiem diferentes pontos de vista e, a menos que haja um acordo explícito, a conceito de pronto pode ser interpretado de maneiras diferentes.

Reparem que a desmotivação e a desconfiança sobre a eficácia do processo se repentem na falta de uma definição de pronto assim como na falta de uma definição de preparado, pois em ambos os casos falta um vocabulário único que promova o alinhamento e este é justamento um dos pontos mais importantes para promover a motivação e a confiança.

Transparência, inspeção e adaptação são os pilares que sustentam o Scrum e todos os seus eventos e artefatos. Pratique-os, não só nos times Scrum, mas também em outros aspectos da vida.

Publicado por

Camila Capellão

Entusiasta em agilidade, participo ativamente da comunidade ágil, acredito no poder das ações coletivas e do trabalho voluntário. Tenho mais de 13 anos de experiência na área de TI em diferentes projetos e papéis. Atualmente atuo como Agile Coach no Núcleo de Engenharia CWI, inspirando e motivando pessoas a buscarem seu propósito e a darem o melhor de si.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s