International Product Owner Foundation

Steen Lerche-Jensen

15 Retrospectiva

15.1 Retrospectiva da Sprint

A Reunião de Retrospectiva da Sprint é um importante elemento do quadro de “inspecionar-adaptar” do Scrum e é o passo final numa Sprint. Todos os membros do Time Scrum participam da reunião, que é facilitada ou moderada pelo Scrum Master. É recomendada, mas não obrigatória, a participação do Product Owner. Um membro do Time será o escrivão e documentará as discussões e itens para ações futuras. É essencial tornar essa reunião um ambiente aberto e relaxado para encorajar a participação de todos os membros do Time. Debates na Reunião de Retrospectiva da Sprint englobam tanto o que deu errado quanto o que deu certo. Os objetivos primários da reunião se pautam na identificação de três itens específicos:

  1. Coisas que precisam continuar sendo feitas: Melhores práticas
  2. Coisas que precisam começar a serem feitas: melhorias no processo
  3. Coisas que o time precisa deixar de fazer: problemas no processo e gargalos de produção

Estas áreas serão debatidas e uma lista de Acordo de Melhorias de Ações é criada.

15.2 Explorador—Comprador—Turista—Prisioneiro (ESVP)

Este exercício pode ser conduzido no começo da Reunião de Retrospectiva da Sprint para entender a mentalidade dos participantes e definir o tom da reunião. Será pedido aos participantes que indiquem anonimamente qual termo melhor representa como eles se sentiram em relação à sua participação na reunião.

  • Explorador: Quer participar e aprender tudo o que for discutido na retrospectiva
  • Comprador: Quer ouvir tudo e escolher o que ele levará da retrospectiva
  • Turista: Quer relaxar e ser um turista na retrospectiva
  • Prisioneiro: Queria estar em qualquer outro lugar e está participando da reunião porque é obrigado

O Scrum Master, por sua vez, compara as respostas, as prepara e compartilha as informações com o grupo.

15.3 Lancha (speedboat)

A Lancha (Speedboat) é uma técnica que pode ser utilizada para conduzir a Reunião de Retrospectiva da Sprint. Os membros do time farão o papel da tripulação de uma lancha. A lancha deve chegar numa ilha, que, simbolicamente, se trata da visão do projeto. Os participantes usarão notas adesivas para gravar os motores e as âncoras, onde os motores os ajudam a chegar na ilha, enquanto as âncoras os impedem de chegar. Esse exercício é time-boxed para poucos minutos. Quando todos os itens estiverem documentados, a informação é comparada, discutida e priorizada por meio de um processo de votação. Motores são reconhecidos e as ações de mitigação serão planejadas para as âncoras, baseadas em prioridades.

15.4 Técnicas de Métricas e Medições

Várias métricas podem ser utilizadas para medir e contrastar a performance do time no Sprint atual para a performance em Sprints antigas. Alguns exemplos dessa métrica podem incluir:

  • Velocidade do Time – Número de pontos de story finalizados numa determinada Sprint
  • Taxa de Sucesso do “Pronto” – Porcentagem de Pontos de story que ficaram Prontos versus os comprometidos.
  • Efetividade de estimativa – Números ou porcentagem de discrepâncias entre o tempo estimado e o tempo real gasto em tarefas e User Stories.
  • Revisão de classificações de feedback — O feedback pode ser solicitado pelos Stakeholders utilizando índices quantitativos ou qualitativos, garantindo uma medida da performance do time.
  • Classificações do moral do Time — Resultados das autoavaliações do moral dos membros do Time
  • Feedback dos colegas — Mecanismos de feedback em 360 graus podem ser utilizados para solicitar críticas construtivas e discernimento para a performance do time
  • Progresso para lançamento — O valores de negócio fornecidos em cada lançamento, assim como o valor representado pelo progresso atual em torno de um lançamento. Isto contribui para a motivação do time e no aumento da satisfação no trabalho

15.5 O resultado da Reunião de Retrospectiva

  • Acordos de Ação: Melhorias: Os Acordos de Melhorias de Ação são o resultado principal do processo de Retrospectiva da Sprint. Eles estão na lista de itens úteis que a equipe traz para resolver os problemas e melhorar os processos a fim de melhorar sua performance numa Sprint futura.
  • Itens de Ação Designados e Vencimentos: Uma vez que o Acordo de Melhorias de Ação foi elaborado e refinado, os itens de ação para implementar as melhoreias devem ser considerados pelo Time Scrum. Cada item de ação deve ter um vencimento definido para que seja completo.
  • Itens não-funcionais propostos para o Backlog do Produto Priorizado: Quando o Backlog do Produto Priorizado inicial é desenvolvido, ele é baseado em User Stories e funcionalidades requeridas. Geralmente requisitos não-funcionais não podem ser totalmente definidos nos estágios iniciais do projeto e podem surgir durante a Revisão da Sprint ou nas Reuniões de Retrospectiva da Sprint. Estes itens devem ser adicionados ao Backlog do Produto Priorizado assim que são descobertos. Alguns exemplos de requisitos não-funcionais são tempos de resposta, limitações de capacidade e falhas relacionadas à segurança.
  • Retrospectiva de Histórico(s) da Sprint: A Retrospectiva de Histórico da Sprint (Sprint Log) é um registro de opiniões, discussões e itens de ação criados numa Reunião de Retrospectiva da Sprint. O Scrum Master poderá facilidar a criação deste histórico com entradas de membros do Time essencial do Scrum. A coleta de todo o histórico da Retrospectiva da Sprint torna-se um diário do projeto e detalha sucessos, falhas, problemas e resoluções. O histórico é um documento público, acessível a todos na Organização.
  • Lições Aprendidas pelo Time Scrum: Se espera do auto-organizado e capacitado Time Scrum que ele aprenda com os erros cometidos durante a Sprint. Essas lições aprendidas ajudarão o time a melhorar sua performance nas Sprints futuras. Elas podem também ser documentadas nas Recomendações do Corpo de Orientação do Scrum, para ser compartilhadas com outros Times Scrum.

Várias lições positivas podem ser aprendidas como parte de uma Sprint. Estas lições são uma parte importante da retrospectiva, e devem ser compartilhadas apropriadamente com o Time e com o Corpo de Orientação do Scrum, para que os times trabalhem para o auto-aperfeiçoamento contínuo.

  • Atualização das Recomendações do Corpo de Orientação do Scrum: Como resultado da Reunião de Retrospectiva da Sprint, sugestões podem ser dadas para revisar ou melhorar as Recomentações do Corpo de Orientação do Scrum. Se o Corpo de Orientação aceitar essas sugestões, elas serão incorporadas como atualizações em sua documentação.

15.6 Retrospectiva do Projeto

A Reunião de Retrospectiva do Projeto é um encontro para determinar maneiras as quais a colaboração e efetividade do Time podem ser melhoradas nos projetos futuros. Oportunidades de melhoria positivas, negativas e potenciais também serão debatidas. Essa reunião não é Time-boxed e pode ser conduzida pessoal ou virtualmente. Os participantes incluem o Time do Projeto, O Scrum Master Chefe, o Product Owner Chefe e os Stakeholders. Durante a reunião, as lições aprendidas são documentadas e os participantes procuram uma oportunidade para melhorar os processos e tratar as ineficiências

Algumas das ferramentas utilizadas no processo de Retrospectiva da Sprint também podem ser utilizados nesse processo. Os exemplos incluem:

  • O exercício do Explorador—Comprador—Turista—Prisioneiro (ESVP)
  • Lancha (Speed Boat)
  • Técnicas de métricas e medições

15.6.1 As saídas da Reunião de Retrospectiva

  • Acordo de Ações: Melhorias: Melhorias no Acordo de Ações são a saída principal do processo de Retrospectiva do Projeto. Ele é uma lista de itens de ação que o time deve fazer para tratar os problemas e melhorar o processo a fim de melhorar sua performance nas Sprint futuras.
  • Itens de Ação Designados e Vencimentos: Uma vez que o Acordo de Melhoria de Ações é elaborado e refinado, os itens de ação para implementar as melhorias devem ser levados em consideração pelo Time Scrum ou pelos stakeholders. Cada item de ação terá uma data de vencimento definida para ser completo.
  • Itens Propostos e Não-funcionais do Backlog do Produto do Programa e Backlog do Produto Priorizado: Quando há o desenvolvimento inicial do Backlog do Produto do Programa ou do Backlog do Produto Priorizado, ele é baseado nas User Stories e funcionalidades requeridas. Geralmente requisitos não-funcionais podem não ser totalmente definidos nos primeiros estágios do projeto e podem surgir durante a Revisão da Sprint, Retrospectiva da Sprint ou Reuniões de Retrospectiva do Projeto. Esses itens devem ser acrescentados ao Backlog do Produto do Programa (para o programa) e Backlog do Produto Priorizado (para o projeto) assim que forem descobertos. Alguns exemplos de requisitos não-funcionais são tempos de resposta, limitações de capacidade e problemas relacionados à segurança.
Previous Chapter Next Chapter

Use the promo code: pofacademy10 and get 10% discount for the International Agile Product Owner Foundation Certification