Scrum Checklist

1. Equipe

1.1. Equipe senta-se junta

1.2. Equipes colaboram para finalizar as stories

1.3. Membros da equipe não estão trancados em papéis específicos

1.4. Membros da equipe colaboram para completar primeiro as stories de maior prioridade

1.5. Membros da equipe admitem problemas e pedem ajuda

1.6. Membros da equipe se ajudam

1.7. Membros da equipe possuem responsabilidade uns com os outros

2. Scrum Master (SM)

2.1. Equipe possui um Scrum Master

2.2. SM senta-se junto da equipe

2.3. SM foca-se em remover impedimentos

3. Product Owner (PO)

3.1. A equipe possui UM Product Owner

3.2. PO tem o poder de priorizar o que a equipe produz

3.3. PO entende o produto para priorizar corretamente

3.4. PO possui ao menos uma equipe dedicada

4. Product Backlog (PBL)

4.1. PO é dono do PBL

4.2. PBL está visível

4.3. PBL é atualizado antes do planejamento do Sprint

4.4. PO entende todas as stories

4.5. "Condições de satisfação" / "Como apresentar" está claro para cara story

4.6. PB contém stories (não tarefas)

5. Definição de Finalizado (DoD)

5.1. Cada story possui uma DoD (ou herda uma definição

5.2. A equipe respeita uma DoD

5.3. PO + Todos os membros da equipe "vivem" a DoD

5.4. DoD inclui testes

5.5. Equipe não depende de outros para alcançar DoD

6. Estimation

6.1. PO pode receber as estimativas da equipe

6.2. PO está disponível quando a equipe está estimando

6.3. Apenas a equipe escreve as estimativas

6.4. Todos na equipe participam na estimativa

6.5. Stories mais prioritárias são pequenas o suficiente para que várias possam cabem numa sprint

6.6. Item mais prioritários no PBL são estimados antes da Reunião de planejamento de Sprint (ao menos suficiente para cobrir 1 sprint)

7. Reunião de planejamento de Sprint

7.1. PO participa

7.2. Todos os membros participam

7.3. Resulta num planejamento de Sprint

7.4. Todos da equipe concordam que o plano seja realista, e se comprometem a isso

7.5. PO está satisfeito com as prioridades

7.6. Todas as stories no sprint possuem uma estimativa

7.7. Inicia e finaliza no prazo

8. Sprint

8.1. Equipe entrega algo após cada sprint

8.2. Equipe segue as prioridades do PO

8.3. Equipes normalmente entrega o que ela se compromete

8.4. Equipe age quando está atrasada no prazo

8.5. Equipe alerta o PO quando existem problemas

8.6. Para cada story, equipe sabe onde encontrar mais informações

8.7. Problemas são detectados & discutidos quando ocorrem, não mais tarde

8.8. Principais itens não planejados são logados

8.9. A duração de cada Sprint não se altera

8.10. Equipe está trabalhando além do tempo consistentimente

8.11. Máximo de 1 dia entre Sprints

8.12. Outras equipes & resto da empresa sabem sobre o sprint

8.13. Algumas vezes se comprometendo demais, outras de menos

8.14. Stories iniciadas normalmente são finalizadas no mesmo Sprint

9. Daily Scrum

9.1. Mesmo horário e mesmo local todos os dias

9.2. Inicia e termina no horário

9.3. Todos os membros da equipe presentes

9.4. Todos respondem às três perguntas

9.5. Sem interrupções

9.6. PO visita as reuniões regularmente

9.7. Equipe está sempre pegando atividades, ao invés do SM delegando tarefas

9.8. Membros da equipe respondem aos demais, não ao SM

10. Sprint Demo

10.1. Demo é feito após cada Sprint

10.2. Demo mostra código funcionando

10.3. Apenas stories que são FINALIZADAS são apresentadas

10.4. Feedback recebido pelos stakeholders durante o demo

10.5. O planejamento original do sprint é apresentado no início do demo

10.6. Todos os stakeholders são convidados para o demo

11. Retrospectiva

11.1. São Realizadas retrospectivas

11.2. Todos os membros da equipe + PO participam

11.3. Resulta em sugestões concretas de melhorias

11.4. Algumas sugestões de melhorias realmente são implementadas

11.5. Todos falam

11.6. Sem pessoas não convidadas

12. Backlog de Impedimentos

12.1. Equipe possui um Backlog de Impedimentos

12.2. Backlog de impedimentos está visível

12.3. Backlog de impedimentos é atual e atualizados

12.4. Backlog de impedimentos é priorizado

12.5. Impedimentos que não podem ser resolvidos são escalados ao PO ou gerente

13. Velocity

13.1. Velocity é atualizada após cada sprint

13.2. Velocity é utilizada para o Planejamento de Release

14. Gráfico Burndown

14.1. Equipe possui um Burndown

14.2. Gráfico Burndown altamente visível

14.3. Gráfico atualizado diariamente

14.4. Velocity somente inclui stories que estão finalizadas de acordo com DoD

14.5. Equipe toma ações quando o burndown está muito acima/abaixo

15. sprint Backlog (SBL)

15.1. A equipe tem um SBL

15.2. SBL é altamente visível

15.3. SBL é atualizado diariamente

15.4. Estimativas de atividades atualizadas diariamente

15.5. Atividades e Stories são claramente diferenciáveis

15.6. Está claro que atividade faz parte de qual story

15.7. Membros da equipe atualizam o SBL (Não apenas o SM)

15.8. Equipe possui acesso fácil para atualizar o SBL