scrum artifacts product backlog
Introdução aos artefatos Scrum:
Nos artigos anteriores desta série, fomos apresentados a ágil e as diferentes metodologias ágeis . Também aprendemos como as várias metodologias são diferentes em sua própria maneira.
Em nosso último tutorial, entramos nos detalhes do Scrum, onde discutimos o Funções Scrum como Product Owner, Scrum Master e a equipe scrum e viu quais eram suas responsabilidades individuais.
Neste tutorial, continuamos com o Scrum e avançamos nos detalhes sobre os diferentes artefatos do Scrum.
O que você aprenderá:
- Diferentes artefatos de Scrum
- Backlog do produto
- Sprint Backlog
- Incrementos de produto
- Conclusão
- Leitura recomendada
Diferentes artefatos de Scrum
3 tipos de artefatos scrum incluem:
- Backlog do produto
- Sprint backlog e
- Incrementos de produto
Agora veremos o que esses termos significam e como criar esses artefatos.
Backlog do produto
Em termos simples, um product backlog é uma lista de todas as coisas que são necessárias no produto. É o documento final a ser consultado pela equipe scrum para qualquer coisa relacionada ao produto. É uma lista ordenada de itens que pertence ao Product Owner (PO).
O PO é responsável por criar, manter e priorizar essa lista. Os POs usam este backlog do produto para explicar os principais requisitos que precisam ser cumpridos durante o sprint para as equipes scrum.
Os itens desta lista podem ou não estar em uma linguagem técnica. Pode até ser uma linguagem leiga, mas deve conter todos os requisitos do produto e as alterações que o acompanham. Além disso, ter um product backlog não significa que a equipe scrum terá apenas este artefato para seguir.
Eles podem criar seus próprios artefatos detalhados, mas eles não irão contradizer ou substituir o backlog do produto. Eles estarão em alinhamento com os requisitos do backlog do produto.
Abaixo está um exemplo de como uma lista de pendências de produto típica pode ser:
História | Estimativa | Prioridade |
---|---|---|
Eu quero entrar | 4 | 1 |
Eu quero sair | dois | dois |
Eu quero mudar a senha | 1 | 3 |
Quero atualizar o endereço | 3 | 4 |
Eu quero adicionar um novo número de telefone residencial | 1 | 5 |
Isso nos leva à questão, como criar uma boa carteira de produtos?
Idealmente, o backlog de um produto deve seguir as regras abaixo:
(i) Deve ser priorizado - Os itens na carteira de produtos devem ser ordenados de acordo com sua prioridade. Essa prioridade pode ser decidida pelo PO e pela equipe scrum juntos. Os fatores de priorização podem ser qualquer benefício do ponto da história, o esforço envolvido na criação, complexidade, prioridade do cliente, etc.
Ajuda a equipe a entender o que precisa ser entregue primeiro.
(ii) Deve ser estimado - As histórias devem ser estimadas sempre de acordo com a definição acordada, seja ela qual for. Isso também pode ser usado para priorização.
(iii) Deve ser de alto nível - As histórias no backlog do produto devem ser de alto nível e não devem entrar em detalhes. A criação de histórias de usuário detalhadas de acordo com o requisito depende da equipe scrum e não do PO.
(iv) Deve ser dinâmico - O backlog do produto não é um documento estático final. Ele deve ser revisado conforme o PO recebe entradas da equipe scrum e os requisitos do cliente se tornam cada vez mais claros. Assim, os requisitos do documento não são congelados no início porque há adições / exclusões / modificações esperadas à medida que o projeto avança.
O último ponto é o mais relevante. O objetivo de um backlog do produto é ser uma fonte de requisitos ativa. Não deve ser criado no início e depois guardado em um local de armazenamento.
Em vez disso, ele deve ser compartilhado repetidamente à medida que as mudanças surgem. Novos requisitos podem surgir à medida que o progresso é feito e isso também pode alterar a prioridade dos itens do backlog. Haverá situações em que um novo requisito depende de outro item na lista de pendências, então a prioridade do item pode precisar ser reorganizada.
Ou pode haver uma história de usuário crítica que deve ser implementada primeiro porque o cliente deseja vê-la antes dos outros, mesmo que não seja de alta prioridade de acordo com os fatores decididos pelo PO e pela equipe scrum.
Portanto, a lista de pendências do produto é uma lista ordenada de requisitos de negócios pertencentes ao PO e visitada continuamente conforme o projeto avança.
Sprint Backlog
Você deve se lembrar que as equipes scrum trabalham em iterações curtas de 2 a 4 semanas, chamadas de sprint. Durante esses sprints, a equipe scrum identifica os itens do backlog do produto criado pelo PO, que eles planejam entregar como parte da próxima iteração. Os itens que a equipe scrum seleciona para trabalhar tornam-se parte do backlog do sprint.
Assim, eles decidem quais funcionalidades estarão lá na próxima iteração do produto. A equipe scrum é quem decide o que vai para o backlog do sprint, já que são eles que vão trabalhar nisso.
Portanto, são eles que devem estimar o esforço envolvido na implementação dessas histórias e decidir o quanto elas podem entregar.
A equipe não apenas seleciona os itens do backlog do produto para trabalhar, mas também faz uma estimativa de quanto tempo levará para desenvolver essa funcionalidade. Eles também aumentam as histórias do usuário de alto nível, criando tarefas detalhadas necessárias para atingir o objetivo do sprint.
site para assistir anime online gratuitamente
A equipe scrum também pode continuar atualizando o backlog do sprint como e quando necessário durante o sprint, mas é apenas a equipe scrum que pode fazer alterações no backlog do sprint.
Um típico Sprint Backlog será semelhante ao mostrado abaixo.
Idealmente, a equipe pode atualizar isso uma vez por dia e o scrum master pode usar essas informações para criar um gráfico de burndown do sprint. Este gráfico de burndown ajudará a equipe a ver quanto trabalho ainda resta para o sprint e a equipe pode planejar seu trabalho de acordo. Eles podem até adicionar ou remover tarefas, se necessário.
Algumas práticas recomendadas ao criar um backlog de sprint podem ser:
# 1) Tomar decisões em grupo - Não deve ser o mestre do scrum ou qualquer outro membro da equipe do scrum decidindo o backlog. Em vez disso, deve ser toda a equipe decidindo quais itens incluir no backlog do sprint e como planejá-los.
Cada membro desta equipe multifuncional traz suas próprias habilidades e é essencial que utilizemos sua experiência para criar o melhor backlog possível.
# 2) Não atribua tarefas - Como já foi repetido várias vezes na literatura ágil, nunca atribua tarefas aos membros da equipe. Uma equipe scrum deve ser autossuficiente e deve saber como organizar seu trabalho por conta própria.
Portanto, em vez de atribuir trabalho, devemos deixar a equipe escolher o trabalho por si mesma e decidir entre si sobre como deseja proceder.
# 3) Definição de pronto - Não deve ser apenas acordado pelas partes interessadas, mas também deve ser claramente visível para a equipe em todos os momentos, sempre que tiver que tomar qualquer decisão em relação aos objetivos do sprint. Isso servirá como um lembrete do que exatamente precisa ser feito antes que eles possam entregar um produto pronto para entrega.
# 4) Continue atualizando o backlog - É imperativo que, à medida que o sprint evolui, a equipe obtenha um maior entendimento e, portanto, eles devem atualizar o backlog do sprint para refletir esse maior entendimento também. Não deve se tornar um documento estático em nenhum momento.
# 5) Adicionar qualquer tarefa - A tarefa não precisa estar apenas relacionada à codificação, mas pode ser essencial para entregar um produto entregável. Portanto, mencione essas tarefas também no backlog.
Incrementos de produto
Isso nos leva ao último artefato scrum que são os incrementos do produto. Conforme definido pelo guia scrum, um incremento é a soma de todos os Itens do backlog do produto completado durante um corrida e o valor dos incrementos de todos os Sprints anteriores. Como sabemos bem agora, Scrum é um processo iterativo.
O resultado de cada iteração é o incremento do produto e cada incremento do produto ajuda a equipe a dar um passo mais perto da entrega do produto final.
O que isso significa é que o resultado do sprint é um incremento. Obviamente, para que o resultado seja considerado um incremento, ele deve primeiro atender à definição predefinida de pronto, ou seja, o resultado final deve ser um produto utilizável que seja capaz de 'envio'.
Ele pode ser verificado, usado e testado para garantir que está realmente 'pronto' de acordo com a definição e, se o Dono do Produto desejar, ele pode ser liberado para entrar em operação também.
O mais importante para entregar este incremento de produto é ter um entendimento compartilhado da “definição de pronto” que é compreendido por todos.
A equipe scrum nunca deve ter dúvidas se o que está fazendo será aceito ou não. Se houver alguma dúvida, a definição de pronto deve ser completa o suficiente para orientá-los sobre como prosseguir. Com base apenas nesta definição, a equipe scrum decide quantos itens do backlog do produto selecionar para o sprint.
Este é o mínimo que se espera do sprint.
Conclusão
A partir deste tutorial, entendemos quais são os 3 artefatos scrum, quem os possui junto com algumas das melhores práticas que nos ajudariam a criar artefatos de melhor qualidade. Em nossos próximos tutoriais desta série, discutiremos os eventos Scrum e veremos como executá-los.
Em nosso próximo tutorial sobre ‘Scrum Eventos , 'Estaremos discutindo cada evento Scrum em detalhes!
PREV Tutorial | PRÓXIMO Tutorial
Leitura recomendada
- Eventos Scrum: Time Boxing, Sprint Planning, Daily Stand-up e Backlog Refinamento
- Funções e responsabilidades da equipe Scrum: Scrum Master e Product Owner
- Tutorial do JIRA Scrum Board: Manuseio do Scrum com Jira para gerenciar o Sprint
- Agile Scrum Online Quiz: Teste Seu Conhecimento de Agile Scrum
- Função dos analistas de negócios no SCRUM e por que um controle de qualidade é melhor para essa função?
- Triagem de defeitos no Scrum: como é organizado em uma configuração do Scrum
- Relatórios de bug de amostra para aplicativos da web e de produtos
- Os 9 melhores softwares de PLM de 2021 para gerenciar o ciclo de vida do seu produto