Scrum - Complementando!

PRODUCT BACKLOG (complementar)

Lista de necessidades que devem ser produzidas para o sistema. “Lista de requisitos ou atividades”.

Deve existir apenas um Product Backlog refletindo todas as necessidades do cliente e deve ser mantido pelo PO refletindo todas as mudanças do negócio (estratégias, tecnologias, novas ideias, etc).

O PO (Cliente) deve priorizar conforme suas necessidades.

Estória – pequena, fácil de concluir, é fácil prever o esforço, tem poucas dúvidas, desta forma possuo poucas incertezas facilitando o cumprimento dos objetivos do sprint. Recomenda-se ter no máximo 7 critérios de aceite por estória. Se for mais de 7 recomenda-se criar 2 estórias. É um exemplo de Caso de Uso, porém mais simples.

Exemplo: Uma tela pode se tornar várias estórias. Um gráfico dentro de um dashboard pode ser uma estória.

As demandas devem ser objetivas. Ex.: O meu site tem que ser rápido. Cada um tem um conceito de rápido por isto precisa ser medido. Ex.: Cada operação de venda por cartão de crédito deve levar no máximo 2 segundos.

Épico – estória grande, é muito complexa, existem dúvidas (vai na parte de baixo do iceberg), difícil estimar o esforço,

Ex.: Um dashboard com diversos gráficos. Um único gráfico do dashboard pode ser uma estória.

Definition of Read – as caracteristicas que uma estória necessita para que possa entrar no Sprint backlog. Deve estar bem escritas, com critérios de aceite claros e testáveis e a equipe se sente segura em realizá-la.

Backlog Grooming – Forma para manter o backlog atualizado e torna as reuniões mais produtivas.

Atividades: criar e refinar itens, estimar itens e priorizar itens do Product Backlog.

Participantes: Product Owner (lidera o grooming), Stakeholders (se necessário), Scrum Master, Time Scrum

Atividades / Fases:

Planning – Planejamento do sprint. Alinhamento com o time de negócio para definição de todas as atividades a serem desenvolvidas dentro do Sprint (é essencial a participação do PO).

Daily Meeting – Reuniões de acompanhamento diário

Review – Como se fosse uma homologação e o cliente da um feedback que deve ser usado para melhoria dos próximos sprints. É extremamente importante a participação das partes interessadas.

Retrospectiva – o time inspeciona e melhora o trabalho realizado.

Planning

O time escolhe as estórias de que é capaz de realizar dentro do sprint conforme prioridades estabelecidas pelo PO no Product backlog.

O time analisa a forma de entregar as estórias (Como)

Tira dúvidas com o PO sobre estórias.

Cria o Sprint backlog (itens a serem desenvolvidos) que será realizado dentro do Sprint (período utilizado).

Eventuais ausências de membros do time são apontadas

O time quebra as estórias em tarefas e são definidas em pontos (horas).

Estórias são dividas em pontos e tarefas em horas

Daily Meeting

Acontece diariamente para obter informações das evoluções em relação a ultima reunião, expor o planejamento até a próxima reunião e para expor os impedimentos.

Duração de 15 minutos

De pé – tem como objetivo ficar em pé para se cumprir os 15 minutos

Tem como objetivo expor problemas ou impedimentos

Se o problema tomar muito tempo para ser discutido, marca-se outra reunião.

Discussões que surgirem que não podem ser resolvidos de imediao e de forma rápida, deve-se agendar uma reunião somente com os envolvidos no problema fora do Daily Meeting.

Impedimentos que surgem são resolvidos pelo Scrum Master. A equipe foca no desenvolvimento do trabalho.

Review

É uma atividade de inspeção e adaptação focada no produto

Acontece após a execução do sprint e antes da Sprint Retrospective

Nessa cerimônia apresentada o que foi desenvolvido no Sprint. São apresentadas somente estórias que atingiram o Definition of Done (finalizados / pronto conforme conceito)

O Time Scrum colhe o feedback do que foi produzido

Retrospectiva

Processo de inspeção e adaptação focada no processo. Acontece no final do Sprint.

O Time Scrum examina o processo utilizado para o construir o produto visando melhora dos próximos Sprints. O Time avalia o que deu certo e o que deu errado e toma as ações necessárias para melhor os erros ocorridos e desta forma se tornar mais produtivo.

A participação do PO é opcional (depende do clima), porém se participa é valido.

Cria-se em um quadro branco duas lista. “O que foi bom ? “ e “O que deve melhorar ?”.

Caracaterísticas:

Facil de Planejar

Rápido feedback

Limita o erro

Melhora o retorno do investimento

Rejuvenesce o entusiasmos

Checkpoints frequentes (ou Milestones)

Velocity

Capacidade de entrega do time dentro do Sprint

Definition of Ready

Estórias prontas para sair do Product Backlog e entrar no Sprint

Definition of Done

Quando o conceito de pronto esta aplicado.

Fim da série de artigos de autoria de Everton Amorim, PMP e edição de Renato Mendes, seguidores e agora colaborados do blog.