Scrum Checklist

1. Sprint

1.1. Equipe entrega algo após cada sprint

1.2. Equipe segue as prioridades do PO

1.3. Equipes normalmente entrega o que ela se compromete

1.4. Equipe age quando está atrasada no prazo

1.5. Equipe alerta o PO quando existem problemas

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

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

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

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

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

1.11. Máximo de 1 dia entre Sprints

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

1.13. Algumas vezes se comprometendo demais, outras de menos

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

2. Equipe

2.1. Equipe senta-se junta

2.2. Equipes colaboram para finalizar as stories

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

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

2.5. Membros da equipe admitem problemas e pedem ajuda

2.6. Membros da equipe se ajudam

2.7. Membros da equipe possuem responsabilidade uns com os outros

3. Daily Scrum

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

3.2. Inicia e termina no horário

3.3. Todos os membros da equipe presentes

3.4. Todos respondem às três perguntas

3.5. Sem interrupções

3.6. PO visita as reuniões regularmente

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

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

4. Scrum Master (SM)

4.1. Equipe possui um Scrum Master

4.2. SM senta-se junto da equipe

4.3. SM foca-se em remover impedimentos

5. Sprint Demo

5.1. Demo é feito após cada Sprint

5.2. Demo mostra código funcionando

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

5.4. Feedback recebido pelos stakeholders durante o demo

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

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

6. Product Owner (PO)

6.1. A equipe possui UM Product Owner

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

6.3. PO entende o produto para priorizar corretamente

6.4. PO possui ao menos uma equipe dedicada

7. Product Backlog (PBL)

7.1. PO é dono do PBL

7.2. PBL está visível

7.3. PBL é atualizado antes do planejamento do Sprint

7.4. PO entende todas as stories

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

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

8. Retrospectiva

8.1. São Realizadas retrospectivas

8.2. Todos os membros da equipe + PO participam

8.3. Resulta em sugestões concretas de melhorias

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

8.5. Todos falam

8.6. Sem pessoas não convidadas

9. Definição de Finalizado (DoD)

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

9.2. A equipe respeita uma DoD

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

9.4. DoD inclui testes

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

10. Backlog de Impedimentos

10.1. Equipe possui um Backlog de Impedimentos

10.2. Backlog de impedimentos está visível

10.3. Backlog de impedimentos é atual e atualizados

10.4. Backlog de impedimentos é priorizado

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

11. Estimation

11.1. PO pode receber as estimativas da equipe

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

11.3. Apenas a equipe escreve as estimativas

11.4. Todos na equipe participam na estimativa

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

11.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)

12. Reunião de planejamento de Sprint

12.1. PO participa

12.2. Todos os membros participam

12.3. Resulta num planejamento de Sprint

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

12.5. PO está satisfeito com as prioridades

12.6. Todas as stories no sprint possuem uma estimativa

12.7. Inicia e finaliza no prazo

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