Artefatos do Scrum: Product Backlog

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). Certificações que possuo: EC-Council CEH, CompTIA (Security+, CySA+ e Pentest+), EXIN (EHF e ISO 27001), MCSO, MCRM, ITIL v3. Tenho interesse por todas as áreas da informática, mas em especial em Gestão e Governança de TI, Segurança da Informação e Ethical Hacking.

Deixe um comentário

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