Artefatos do Scrum: Product Backlog

image_pdfimage_print

As regras dos Scrum são simples, porém difíceis de aplicar, os artefatos não são muitos, na verdade palpável mesmo apenas o Product Backlog, e é dele que irei falar hoje.

“O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação.”  (Scrum Guide, pág. 13)

Como vimos no Scrum Guide, o Backlog do produto representa tudo aquilo que o Product Owner deseja par ao produto, e pode ser mantido de várias formas: lista de cartões, planilha Excel, softwares para gestão de Backlog. Fato mesmo é que sem ele não há produto, pois o time de desenvolvimento precisa saber o que deve ter no produto.

Os itens de Backlog devem ser simples e pequenos o suficiente para caber em uma Sprint, comumente diz que eles devem respeitar a fórmula do INVEST (Independent, Negotiable, Valuable, Estimable, Small e Testable), o que significa dizer que é necessário esclarecer os itens do Backlog antes de leva-los para uma Sprint, por isso se faz necessário discutir com o time antes estes itens.

A ordem dos itens de Backlog é definida pelo Product Owner, já que ele é a autoridade máxima sobre esta questão, mas vale ressaltar que o time pode sugerir melhorias no Backlog, de acordo com sua complexidade.

O Backlog deve ser público e de conhecimento de todos no projeto, mesmo porque o time deve saber o que vem pela frente, para ter a visão do que será o produto e também alinhar as expectativas do cliente e também seguindo a visão do produto.

Os itens do Backlog normalmente são ordenados por valor de negócio, o que significa dizer que eles idealmente devem seguir uma ordem lógica que traga mais valor agregado. Esta ordenação é necessária para que o refinamento seja realizado paulatinamente, ou seja, os níveis de detalhe são maiores conforme a proximidade do “topo da lista” dos PBIs. Os itens de Backlog no topo da lista devem conter um nível de detalhe que traduza a necessidade e deixe claro para o time de desenvolvimento o que deve ser feito, mas não como deve ser feito, isso compete ao time decidir.

É necessário entender que os requisitos nunca param de evoluir, conforme são utilizados os itens de Backlog produzidos, os feedbacks são coletados e refinados podendo tornar-se mais complexos de acordo com as necessidades do Negócio. Mudanças nos rumos do Negócio, tecnologia ou novos requisitos de mercado podem e possivelmente irão afetar e refletir no Product Backlog, por este motivo chamamos o Backlog de artefato vivo.

Múltiplos times podem trabalhar no mesmo Backlog se estiverem trabalhando no mesmo produto, e é vital que seja o mesmo Backlog para que a integração seja contínua e o produto final seja um produto acabado e potencialmente pronto para o uso.

Os critérios de aceitação devem ser claros e estar presentes nos itens do Backlog, pois são eles que dão ao PO a certeza que em termos de negócio, a funcionalidade que foi desenvolvida está coerente com o que foi solicitado.

Preparar o Backlog é uma atividade de tempo parcial, ocorre durante a Sprint atual e devem participar o PO e o time de desenvolvimento, normalmente chamado de Grooming, não deve consumir mais que 10% do tempo de uma Sprint, mas normalmente separamos 4 horas por semana. O time de desenvolvimento é responsável por todas as estimativas enquanto o PO é responsável por todos os esclarecimentos necessário para que o time tenha plena capacidade para estimar com mais precisão, lembrando aqui que é apenas uma estimativa e não aferição métrica de esforço de trabalho.

O Backlog alimenta os gráficos de burndown e burnup e é através dele que é medido o progresso tanto de uma Sprint quanto de um Release até chegar ao produto “final”.

Backlog da Sprint

É o conjunto de itens de Backlog separados para uma Sprint, e deve seguir a meta da Sprint visando à entrega de software ao final da iteração. É através dele que a equipe define qual é o trabalho a ser realizado e mira o plano de entrega da funcionalidade “pronta”.

As tarefas de uma Sprint são criadas a partir dos itens de Backlog selecionados, porém sempre que um novo trabalho precisa ser feito é criada uma nova task dentro de um item de Backlog selecionado. Por este motivo dizemos que o Sprint Backlog é volátil, mas sempre deve seguir a em rumo à meta selecionada, PBIs só podem ser adicionados ou removidos quando houver consenso entre time e PO.

Conforme o trabalho é realizado as estimativas do restante são atualizadas e alimentam o Sprint burndown, assim o time sabe se está ou não no rumo dos seus objetivos, ou seja, atingindo a sua meta. Mesmo assim vale lembrar que software funcionando é medida primária para o sucesso.

Fonte: Projetos de TI

Sou bacharel em Sistemas de Informação pela Estácio de Sá (Alagoas), especialista em Gestão Estratégica da Tecnologia da Informação pela Univ. Gama Filho (UGF) e pós-graduando em Gestão da Segurança da Informação pela Univ. do Sul de Santa Catarina (UNISUL). Tenho interesse por todas as áreas da informática, mas em especial em Gestão, Segurança da Informação, Ethical Hacking e Perícia Forense. Sempre disposto a receber sugestões de assuntos para criar uma postagem.

Deixe uma resposta

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

Quer ficar atualizado?

Inscreva-se em minha newsletter e seja notificado quando eu publicar novos artigos de graça!