O Product Backlog é a única fonte de tarefas realizadas pela Scrum Team. É uma lista de funcionalidades e melhorias planejadas do Produto. Sua forma é mutável e nem todas as tarefas incluídas no Product Backlog serão concluídas. Ele evolui durante discussões com as partes interessadas. Também é constantemente aprimorado. Isso significa que, quanto mais próximo do prazo, mais detalhada uma tarefa se torna.
O Product Backlog é o maior dos Artefatos Scrum. Ele reflete o status do trabalho em um Produto em relação ao Objetivo do Produto. Por outro lado, quando o trabalho em um Produto é concluído, seu Backlog se torna uma lista completa das tarefas realizadas pela Scrum Team para criar o Produto. No entanto, não contém soluções técnicas detalhadas.
O Product Backlog é criado durante as reuniões do Product Owner com as partes interessadas. O Product Owner é o único proprietário e a pessoa responsável por esta fonte de tarefas.
A linguagem de negócios caracteriza as entradas no Product Backlog. Em outras palavras, elas descrevem o valor do Produto do ponto de vista das partes interessadas.
As descrições das tarefas incluídas na lista de tarefas precisam de coerência e clareza. Elas contêm funções e melhorias do Produto geralmente apresentadas na forma de User Stories, às quais dedicamos uma entrada separada. Aqui, mencionaremos apenas que estas são descrições de funcionalidades parciais do produto que respondem às perguntas sobre as seguintes questões:
A ordem das tarefas incluídas no Product Backlog muda à medida que o Produto se desenvolve. Enquanto trabalha nele, a Scrum Team molda e aprimora suas funcionalidades. Ao encontrar obstáculos, suas ações implementadas permitem que todos pensem e definam futuras soluções adequadas, e estas também mudarão de acordo com obstáculos imprevistos. Portanto, não há uma ordem clara e definida de ações, tudo é mutável. O aprimoramento do Product Backlog visa seu contínuo atualização e preparação para as próximas tarefas. Por essa razão, é contínuo.
Tarefas com um prazo distante são tipicamente grandes, genéricas. Sua descrição não contém detalhes, mas apenas um esboço da funcionalidade que deve ser realizada. Também é possível encontrar tarefas entre elas que nunca serão concluídas.
As entradas no Product Backlog podem apresentar soluções alternativas. E também as ideias do Cliente que podem se tornar obsoletas, não lucrativas ou por algum outro motivo nunca entrar na fase de implementação. É por isso que o Product Backlog às vezes é chamado de forma brincalhona de “lista de desejos do Cliente”.
Outro motivo para mudanças na forma do Product Backlog é redefinir soluções. Às vezes, acontece que um certo problema já foi resolvido ao criar outra funcionalidade do produto. Ou a funcionalidade esperada se tornou redundante devido a mudanças em outras soluções.
Uma das atividades básicas durante o aprimoramento do Product Backlog é dividir as tarefas contidas no Product Backlog em partes. Graças a isso, o esboço geral da funcionalidade é apresentado na forma de unidades menores, mais detalhadas e precisamente definidas.
Tarefas projetadas para implementação mais próxima se tornam mais detalhadas. Elas também se tornam menores, contendo detalhes das soluções. Os detalhes surgem durante o desenvolvimento do Produto. E graças ao conhecimento do estado atual do Produto e das expectativas atuais das partes interessadas, o Product Owner complementa as próximas tarefas com sua descrição, ordem e tamanho. Em seguida, seleciona as tarefas melhor descritas para o próximo Sprint Backlog.
Enquanto trabalha em um Produto, o Product Owner modifica e detalha o Product Backlog em cooperação com a Development Team. Seguindo as sugestões do Product Owner, durante o Sprint Planning a equipe seleciona funcionalidades para implementar do Product Backlog. Elas são então movidas para o Sprint Backlog e divididas em tarefas a serem concluídas. As tarefas movidas para o Sprint Backlog são descritas em linguagem técnica, que é a mais útil para os Desenvolvedores.
O tamanho da tarefa é uma métrica importante do ponto de vista da Development Team. Sua estimativa adequada se torna especialmente crítica ao selecionar User Stories do Product Backlog para o Sprint Backlog.
A Development Team aprende ao longo do tempo a estimar corretamente o tempo e o esforço necessários para concluir uma User Story específica. Isso é expresso em dias, horas-homem ou Story Points e fornece uma estimativa de um valor chamado Team Velocity.
O Product Backlog é uma lista de tarefas continuamente aprimorada que leva ao Objetivo do Produto. O conteúdo do Product Backlog é geralmente expresso na forma de User Stories. E quanto menor o tempo restante para concluir uma tarefa, mais:
A Scrum Team cuida das tarefas. O Product Owner gerencia e modifica o Product Backlog.
Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Como Gerente de Projetos, Caroline é uma especialista em encontrar novos métodos para projetar os melhores fluxos de trabalho e otimizar processos. Suas habilidades organizacionais e capacidade de trabalhar sob pressão de tempo a tornam a melhor pessoa para transformar projetos complicados em realidade.
Você é um freelancer procurando maneiras de promover seu portfólio? Hoje em dia, não apenas…
A gestão financeira digital e a contabilidade online tornaram-se cada vez mais populares nos negócios.…
Os estatutos de projeto são o pão e a manteiga da gestão de projetos. Eles…
Organizações de diversos setores constroem relacionamentos com potenciais funcionários, fornecedores e parceiros todos os dias.…
Existem muitas técnicas de gestão por aí. Algumas parecem intrincadas, enquanto outras são simples, mas…
Você sabe como começar uma ONG? Você tem pensado nisso? Você está ciente de quão…