Conheça o Processo Demonstrar e Validar o Sprint SBOK SCRUMstudy

Conheça o Processo Demonstrar e Validar a Sprint no Gerenciamento Ágil de Projetos

demonstrar-sprint

Neste artigo, apresentaremos o processo Demonstrar e Validar Sprint, da fase Revisão e Retrospectiva do Scrum de acordo com o Scrum Body of Knowledge, da SCRUMstudy. A fase Revisão e Retrospectiva é composta por 3 processos. Além da fase Revisão e Retrospectiva, existem ainda outras 4 fases: Iniciar, Planejar e Estimar, Implementar e Release.

frederico-scrumPreparamos uma série de artigos sobre as fases e os processos do Scrum da SCRUMstudy. Em comparação ao Scrum original, a abordagem da SCRUMstudy é metodológica, enquanto o original é um framework. Criamos um curso também sobre o Scrum de Ken Schwaber e Jeff Sutherland, clique aqui para conhecer o curso Scrum 100 Lero Lero. Apesar de existirem conflitos e polêmicas entre ambas as correntes, acreditamos que todas são interessantes para o gerente de projetos profissional. Leia mais artigos em nosso blog para entender as polêmicas e debates em relação as diferentes abordagens frente ao Scrum.

Propósito do Processo Demonstrar e Validar Sprint

Também conhecido como a revisão da Sprint, este processo tem por objetivo apresentar ao Dono do Produto aquilo que foi desenvolvido na Sprint passada, terminada antes da revisão em si. Demonstrar e validar o Sprint é essencialmente validar o produto ou o incremento de produto criado a partir do backlog do produto. Este entregável tem de ter valor para o cliente, independente de atender critérios de aceitação e definições de pronto. Pode ser aceito pelo Dono do Produto formalmente e a reunião de demonstração pode ser feita apenas com o Dono do Produto, mas é preciso ter consciência de que quando chegar ao cliente, tem de funcionar e tem de servir para algum propósito. Sprints precisam sempre criar valor por meio de seus entregáveis. Pense nisso!

demonstrar-sprint

Entradas

Time Central do Scrum*

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.


Entrada obrigatória neste processo!

Entregáveis do Sprint*

Já descrito no artigo sobre o processo Criar os Entregáveis, clique aqui para conferir.

Entrada obrigatória neste processo!

Backlog do Sprint*

Já descrito no artigo sobre o processo Criar o Backlog Priorizado do Produto, clique aqui para conferir.

Entrada obrigatória neste processo!

Critérios de Aceitação das Histórias de Usuário*

Já descrito no artigo sobre o processo Criar Histórias de Usuário, clique aqui para conferir.

Entrada obrigatória neste processo!

Stakeholders

Já descrito no artigo sobre o processo Criar a Visão do Projeto, clique aqui para conferir.

Cronograma de Planejamento da Release

Já descrito no artigo sobre o processo Conduzir o Planejamento da Release, clique aqui para conferir.

Riscos Identificados

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Dependências 

Já descrito no artigo sobre o processo Criar as Tarefas, clique aqui para conferir.

Recomendações do Scrum Guidance Body

Já descrito no artigo sobre o processo Criar a Visão do Projeto, clique aqui para conferir.

Ferramentas

Reuniões de Revisão do Sprint*

Apesar de não estar detalhado no SBOK, tradicionalmente reuniões de revisão tem um time-box de 4 horas para Sprints de 4 semanas – utilizando este número de horas como parâmetro ajustável para Sprints de tamanhos menores ou maiores.

Estas reuniões devem contar com as seguintes partes interessadas:

  • Equipe de Desenvolvimento
  • Scrum Master
  • Dono do Produto
  • Cliente

Nesta reunião o produto, ou incremento de produto, será demonstrado e validado pelo cliente. Uma vez incorporado ao dia-a-dia do cliente, ele ainda terá de receber melhorias ou correções. Muitas vezes é na utilização de um incremento ou de um entregável que se manifesta a dívida técnica, falhas decorrentes de atividades e de características deixadas de lado pela priorização do que era mais importante para o cliente. Nestes casos, o time tem de acomodar atividades de manutenção em seus Sprints e o Dono de Produto deve atualizar seu backlog de produto com estas atividades – quando possível.

De acordo com o SBOK:

Os membros do Time Central do Scrum e o(s) Stakeholder(s) relevantes(s) participam das Reuniões de Revisão do Sprint, para aceitar os entregáveis que satisfaçam os Critérios de Aceitação da História de Usuário, e para rejeitar os entregáveis inaceitáveis. Essas reuniões são convocadas no final de cada Sprint. O Time Scrum demonstra as conquistas do Sprint, incluindo as novas funcionalidades ou produtos criados. Isso fornece uma oportunidade ao Dono do Produto e Stakeholder(s), para inspecionar o que foi concluído até o momento, e para determinar se as modificações devem ser feitas no projeto ou em processos de Sprints subsequentes.

Ferramenta obrigatória neste processo!

Análise de Valor Agregado

Confira este artigo super completo sobre controle de custos e gerenciamento de valor agregado, incluindo exercícios práticos: http://sitecampus.com.br/vamos-planejar-controlando-os-custos/

Expertise do Scrum Guidance Body

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Saídas

Entregáveis Aceitos*

Para um entregável ser aceito, ele precisa atender aos seguintes pontos:

  • Estar dentro dos critérios de aceitação, ou atender a estes critérios integralmente
  • Estar pronto dentro da definição de pronto para as entregas, histórias de usuário e tarefas daquele Sprint ou do projeto como um todo
  • Ser aceito pelo Dono do Produto
  • Ser aceito pelo cliente

Um produto deve ser bom, utilizável, ter valor, para um cliente. Mesmo que este cliente especifique critérios de aceitação, ele pode ainda rejeitar uma entrega. Podemos atribuir a culpa ao Dono do Produto, se quisermos pensar em termos de “culpados” e “inocentes”. Contudo, esta não é uma abordagem matura. Necessidades mudam e por mais que o Scrum ofereça uma forma de lidar com incertezas e mudanças, o próprio cliente pode não saber o que quer e solicitar algo que para si não tenha tanta utilidade no fim das contas.

Entregáveis aceitos devem compro uma lista específica, a ser mantenida pelo Dono do Produto e serem removidos dos Backlog do Produto. Em Sprints posteriores, é possível que estes itens gerem pontos de manutenção e precisem ser tratados fora do quadro Scrum, em um quadro paralelo.

Saídas obrigatória neste processo!

Entregáveis Rejeitados

De acordo com o SBOK:

Se os Entregáveis não atenderem aos Critérios de Aceitação, os mesmos serão rejeitados. As Histórias de Usuário associadas a estes entregáveis serão adicionadas ao Backlog Priorizado do Produto, de modo que tais entregáveis possam ser considerados como parte de um Sprint posterior.

Riscos Atualizados

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Resultado da Análise de Valor Agregado

Novamente, confira o artigo já recomendado escrito e publicado aqui no Site Campus sobre controle dos custos e do gerenciamento do valor agregado: http://sitecampus.com.br/vamos-planejar-controlando-os-custos/

Cronograma de Planejamento da Release Atualizada

Já descrito no artigo sobre o processo Criar o Backlog da Sprint, clique aqui para conferir.

Dependências Atualizadas

Já descrito no artigo sobre o processo Criar as Tarefas, clique aqui para conferir.

Deixe seus comentários!

Tags: , , , ,

Mostrar botões
Esconder botões