Trabalhando com Scrum - Artefatos

Nos três primeiros posts da série, falei a respeito de diversos tópicos do Scrum com alguns termos que foram citados, mas não foram explicados de forma aprofundada. Essa ordenação nos posts seguiu a mesma ordenação do Scrum Guide e, sendo assim, deixei para este texto a explicação de todos os artefatos que fazem parte do framework. Minha recomendação é que se você nunca ouviu falar do Scrum e está usando essa série como fonte principal, leia este artigo e retorne para os anteriores. Provavelmente tudo o que não ficou claro parecerá bem mais simples.

Posts da série:

• Trabalhando com o Scrum - Introdução
• Trabalhando com o Scrum - Papéis
• Trabalhando com o Scrum - Cerimônias
• Trabalhando com o Scrum - Artefatos
• Trabalhando com o Scrum - Exemplo de uma Sprint

Artefatos do Scrum

Segundo o Scrum Guide, os artefatos do Scrum são projetados para maximizar a transparência de informações chave, de forma que todos tenham o mesmo entendimento do processo de desenvolvimento do produto. Temos a definição de 3 artefatos: Product Backlog, Backlog da Sprint e o incremento de produto.

Product Backlog

O Product Backlog é uma lista ordenada de tudo que se pretende desenvolver para o produto, sendo assim a única fonte de requisitos. Cada item do Product Backlog deve ter atributos com a descrição, prioridade, estimativa e valor. Geralmente também incluem descrições de testes que vão provar que o item está atendendo à definição de “Done”.

Como já havia comentado na seção sobre as responsabilidades do Product Owner, o PO é o responsável pela manutenção, ordenação e disponibilidade do Product Backlog. Os itens prioritários formarão o Backlog da próxima Sprint, o que significa que devem estar mais claros e detalhados do que os itens menos prioritários. Para isso, o trabalho do PO deve ser organizado de forma que estes itens estejam prontos para que o time possa entendê-los e debatê-los na Planning.

Enquanto o time de desenvolvimento está trabalhando nos itens da Sprint atual, o PO deve estar trabalhando para que o Product Backlog se mantenha com o máximo de valor. Ele deve possuir todos os recursos, funções, requisitos, melhorias e correções que devem ser desenvolvidos para o produto. Para trazer o maior valor possível para a organização e dar a visibilidade do roadmap do produto para todos os interessados, o Product Backlog deve estar sempre disponível na sua versão mais atualizada.

Cada item que está planejado pelo PO para ser trabalhado na próxima Sprint deve estar detalhado e refinado o suficiente para que possa ser transformado em “Done” no período de uma Sprint. Se o time identificar durante a Planning que o item não está atendendo aos critérios para ser considerado “Ready”, ele pode indicar que o item não será incluído no Backlog da Sprint.

O Scrum prevê mudanças, então precisa-se ter em mente que o Product Backlog não é um artefato fixo. A cada mudança no mercado ou no roadmap do produto, a cada feedback direto de clientes ou resultados de pesquisas de UX, podemos ter uma alteração nos itens. Todas essas mudanças devem influenciar o PO, que pode adicionar, remover ou alterar itens do Product Backlog para que o mesmo evolua junto com o produto.

Backlog da Sprint

Todos os itens que foram selecionados do Product Backlog durante a Planning, formam o Backlog da Sprint. Além do plano para transformar estes itens em um incremento de produto, que expliquei como sendo as tarefas mapeadas e estimadas durante a cerimônia.

O Backlog da Sprint é uma previsão das funcionalidades que serão desenvolvidas pelo time para o próximo incremento de produto, no período de uma Sprint, e o trabalho necessário para atingir o objetivo da Sprint. Ele pode mudar se necessário e essa necessidade surge conforme o time vai trabalhando nos itens e aprende com o trabalho que está sendo feito. A Daily é a cerimônia que apoia nessa mudança, pois conforme o time vai inspecionando o trabalho, ele pode entender que as tarefas mapeadas na Planning devem ser alteradas ou removidas, ou até mesmo que novas tarefas devem ser criadas.

Apenas o time de desenvolvimento pode alterar o Backlog da Sprint e o PO deve ficar disponível para tirar possíveis dúvidas a respeito dos itens.

Aqui é importante entender a diferença entre os dois Backlogs no que diz respeito ao papel do PO. Enquanto o Product Backlog pode ser alterado somente pelo PO, o Backlog da Sprint pode ser alterado somente pelo time de desenvolvimento, que tem o conhecimento necessário para saber como aqueles itens prioritários devem ser transformados em um incremento de produto.

Incremento de produto

É a soma de todos os itens do Product Backlog que foram entregues durante uma Sprint, somados ao valor de todos os incrementos das Sprints anteriores. Ao entregar um incremento, o time entrega uma funcionalidade utilizável do produto, que o PO pode decidir liberar a partir do momento que ficar disponível. Para isso, o incremento deve estar de acordo com a definição de “Done” estipulada pelo time.

Liberar o incremento: incorporar ao produto a funcionalidade utilizável.

Transparência dos artefatos

As decisões para otimizar o valor e controlar riscos são baseadas nas informações contidas nos artefatos, ou seja, são tomadas de decisões empíricas. Quanto maior a transparência dos artefatos, mais acertadas são as decisões tomadas com base neles.

O SM deve incluir no seu trabalho a inspeção dos artefatos, para detectar se estão completamente transparentes. Isso pode ser feito pela observação da diferença entre os resultados esperados e os resultados obtidos, na validação dos artefatos quanto ao seu conteúdo e através da observação das discussões que surgem durante as cerimônias. Garantir a transparência dos artefatos é um trabalho contínuo e que deve ser feito junto ao time.

Uma disfunção que já vi acontecer várias vezes é ter um item do Product Backlog com uma descrição totalmente diferente do que está sendo debatido na Planning. O SM deve ficar atento à essas situações e entender junto com o PO se a descrição do item está sem o detalhamento necessário ou se o time de desenvolvimento se desviou da definição durante o debate.

Definição de “Ready”

Quando um item do Product Backlog é descrito como “Ready”, significa que ele está com a descrição suficiente para que o time entenda o que deve ser entregue e como será desenvolvido para ser considerado “Done”.

Em outras palavras, os itens em “Ready” são aqueles que estão bem detalhados e que possuem todas as informações necessárias para que o time possa desenvolver o incremento esperado.

Definição de “Done”

Quando um item do Product Backlog ou um incremento é descrito como “Done”, isso significa que o item está pronto para ser liberado e utilizado.

Quando descrevemos um item como “Done”, todos devem entender o que “Done” significa e não estou falando do significado da frase anterior. A definição varia para cada time: um time de marketing entende um item como “Done” de forma diferente de um time de contabilidade, por exemplo. Mas os integrantes de cada um desses times deve ter o mesmo entendimento de “Done” dentro do seu contexto.

Cada time pode ter a sua própria definição de “Done”, mas também pode haver uma definição de “Done” base da organização, que pode influenciar a definição do time. E, conforme o time amadurece, é esperado que a definição de “Done” expanda para incluir critérios mais rigorosos, a fim de aumentar a qualidade.

Aqui eu fecho as definições do Scrum Guide. Para o próximo post, pretendo mostrar um exemplo de como as coisas acontecem na Sprint, para apoiar quem nunca viu uma na prática. Talvez assim fique mais fácil entender como tudo se encaixa.

No aguardo dos comentários, até a próxima!

Copiar link