PRODUCT BACKLOG

Resumo

           O Product Backlog faz parte do framework de desenvolvimento Scrum, estando ligando diretamente ao PO (Product Owner) que é responsável por sua criação, por seu conteúdo, por sua disponibilidade e por sua priorização. O Product Backlog esta ligado a todo ciclo de vida de um projeto Scrum.

Visão do Product Backlog

           O Product Backlog é uma lista de prioridades de tudo que pode ser necessário para o desenvolvimento de um produto sendo a mesma feita pelo PO (Product Owner) no inicio do projeto sendo não necessário a lista estar completa logo de inicio.

           O Product Owner tem que manter o Product Backlog regularmente atualizado para refletir todas e as mudanças e necessidades feitas pelo cliente. A lista deve conter todas as características, funções, tecnologias, melhorias e correções e defeitos que constituem as mudanças que serão efetuadas no produto para futuras releases.

           Um Product Backlog é composto por diversas estórias e cada estória tem diversos campos podemos considerar os seguintes abaixo:

• ID
• Nome
• Importância
• Estimativa Inicial
• Como demonstrar
• Notas

ID

           Cada item deve conter uma identificação com auto incremento, caso seja alterado seu nome, evita a perda de controle de itens.

Nome

            O nome de cada estória deve ser curto e sugestivo a demonstração e ser devidamente claro para o time. Podemos citar como exemplo “Criar Cadastro”. O nome normalmente possui de 2 a 10 palavras.

Importância

           Costuma ser usado o método de pontuação de cada item, o Product Owner é o responsável por pontuar cada item, o método de pontuação pode ser usado para o nível de prioridade, quanto maior sua pontuação  mais importante o item  será para o projeto.

Estimativa Inicial

            A importância de uma estória é definida pelo PO (Product Owner) com auxilio do Scrum Master. Pode citar como exemplo “21”, quanto maior o numero maior será a importância da estória para o projeto, existem diversas técnicas para definir as prioridades umas delas o Planning Poker o mais popular entre elas, que utiliza cartas com numeração seguindo a tabela Fibonacci. O Product Backlog é dinâmico, podendo estar constantemente mudando para identificar o produto de maior necessidade.

Como demonstrar

           Em uma descrição de alto nível de como o item deve ser demonstrado na apresentação do Sprint e especificar de uma maneira simples como deve ser feito o teste.

Notas

           Normalmente breve e deve incluir esclarecimentos, referencias de outras fontes ou  qualquer outro tipo de informações.

Exemplo de Product Backlog           

Como implementar o Product Backlog

           Normalmente é utilizado o Excel com o compartilhamento habilitado, aonde o Product Owner é o dono oficial do documento. O time muitas vezes irá abrir o arquivo para esclarecer dúvidas ou alterar a estimativa do projeto.

•            Em um Product Backlog pode haver vários itens mais apenas um deve existir para definir uma visão de tudo que é feito.

SPRINT BACKLOG

           O Sprint Backlog é uma sub lista de tarefas, que surge a partir do que foi levantado e listado no gerenciamento de visão de projeto junto ao Product Owner, o Product Backlog. Após este, é gerenciada a Sprint de Desenvolvimento durante uma Reunião de Planejamento, o Sprint Planning Meeting.

           Nas Reuniões de Planejamento, estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, nessa reunião itens são priorizados pelo Product Owner que são questionados de forma que possam ser selecionados e subdivididos pelo time, normalmente na forma de User Stories, em uma espécie de “decomposição” de tarefas, que basea-se nas funcionalidades de maior importância para o Product Owner e na percepção do time com relação ao Sprint e suas Metas (ou seja, o que ele espera que o produto seja capaz de fazer quando chegar o fim daquele ciclo de desenvolvimento), identificando o que é necessário para completar cada um deles. Costuma-se armazenar as informações do Sprint Backlog em tabelas ou planilhas, contendo nas colunas a User Story, tarefas e os dias para aquela Sprint.

           É fundamental o envolvimento e comprometimento constante do time na seleção dos itens e dimensionamento do Sprint Backlog, já que são eles que desenvolverão e completarão as tarefas definidas, identificando assim os impedimentos e estimativas de prazos. Devido aos esforços dentro da faixa de tempo do Sprint, o Scrum Master é responsável por manter os Sprints Backlogs atualizados, sendo assim ele e todos os integrantes informados sobre as atualizações realizadas, pelo menos uma vez por dia, prioritariamente nas Reuniões de Planejamento assim acompanhando as atividades completas e estimando o prazo das pendentes, será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer. Aconselha-se que nem todos os itens do Sprint Backlog estejam diretamente relacionados às metas e que não sejam feitas Sprints muito longas. Isso porque, caso não seja possível concluir um deles, a meta estará comprometida e, assim, a Sprint não terá sucesso.

           Não menos importante, o Sprint Backlog não deve ser mudado porque a meta da Sprint não pode ser mudada. Além disso, incluir um novo item ao Sprint Backlog pode ocasionar na não conclusão de outro item. Por isso, itens novos só podem entrar no Sprint Backlog se estiverem relacionados à Meta e se forem cumpri-la de uma forma que os itens já presentes não cumprirão.

Ana Paula Gregório dos Reis

Anderson Gazote

Lucas Samudio

Willian Raphael Faria Matos