Este documento descreve o framework Scrum, incluindo seus papéis, artefatos e eventos. Ele destaca que Scrum valoriza indivíduos, software funcionando e colaboração com clientes mais do que processos, documentação e contratos. O documento explica os papéis de Product Owner, Scrum Master e Dev Team, assim como os artefatos de Product Backlog, Sprint Backlog e eventos como Sprint Planning Meeting e Sprint Retrospective.

1. Framework Scrum
Leonardo José Bim Rosine, CSM
http://br.linkedin.com/in/leonardobim

2. Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós
mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à
esquerda.
Manifesto ágil

3. Escopo
Product
Backlog
Visão
Visão
Plano
Tradicional
Ágil
Fator
de
Sucesso
Escopo
Fechado
Fator
de
Sucesso
Visão
Fechada
Sprint 1
Sprint 2
Sprint 3
Projeto tradicional x ágil

4. Processo

5. Product
Owner
Clientes e
Usuários
Fornecedores
Governança
Sponsor
Time Dev
Visão
Product
Backlog
Status
projeto
Gerencia
fornecedores
Alinhamento
organização
Acorda a
meta do
Sprint
Esclarece
requisitos
Sprint
BacklogValida
entrega
Negocia
priorização
técnica
Scrum Master
Papéis

6. Time Scrum – Equipe de gestão de projetos
Macrogestão
Negócio
Liderança servidora
Processos/pessoas
Microgestão
Tecnologia
3 – 9 Pessoasarquitetura
codificador
teste
UX
documentação
deploy
Papéis

7. Dev Team
Ser multi-disciplinar (codificação, arquitetura, deploy, QA)
Faz sua própria micro-gestão do trabalho (cobrança interna, quadro, gráfico burndown)
Trabalha junto na mesma US (a velocidade real é do elo mais fraco, aumenta comprometimento
com a entrega)
Estuda práticas ágeis de Engenharia de Software
Negocia priorização técnica com PO
PO
Gerencia fornecedores (em conjunto com SM)
Negocia o Product Backlog com cliente
Prioriza e detalha o Product Backlog
Garante que os primeiros itens do Product Backlog estejam ok com o Definition of Ready (em
conjunto com Dev Team)
Negocia Sprint Backlog com o Dev Team
Esclarece requisitos com o Dev Team (o tempo todo)
Valida a entrega do Sprint
SM
Garante que todos os pontos do processo estejam OK
Altera o processo de acordo com a necessidade
Remove impedimentos para o Dev Team
Desenvolve habilidades do Dev Team
Facilita a comunicação (Dev Team – PO, PO – Cliente, PO – Fornecedor)
Papéis

8. Product Backlog Item
Escrito em formato de US ou BUG
BUG só existe depois da US ser entregue e aceita
Todo item deve ser estimado em Story Points
Product Backlog
Deve estar sempre priorizado
Os primeiros itens devem ter mais valor de negócio,
mais granularidade e mais detalhes
Os primeiros devem também atender a Definition of
Ready
Definition of Ready
Itens de negócio escritos em formato de US
Aderente a gramática de US
Design e HTML prontos
Definition of Done
Code review
Teste Unitário
Validação QA
Disponível em Homologação
Artefatos

9. S
P
R
I
N
T
2
S
E
M
A
N
A
S
Sprint Planning Meeting (<= 4 horas)
1ª parte – Estratégica
Definição da Meta do Sprint
Estimativa das US’s (Dev Team)
Negociação Sprint Backlog (Dev Team e PO)
Dev Team deve negar US’s sem Definition of Ready
2ª parte – Tática
Definição das tarefas com base na Definition of Done
Daily Scrum (<= 15 min)
Dev Team não tira dúvidas de negócio nem
validar entrega com PO
Dev Team não fornece status para PO e SM
Dev Team não comunica impedimentos ao
SM e sim ao próprio Dev Team, o SM deve
ser avisado no momento em que o
impedimento acontece
Dev Team não discute soluções técnicas
Dev Team se cobra, atualiza quadro e gráfico
burndownSprint Review (<= 2 horas)
Inspeção e adaptação do produto
Sem PPT e print, apresentar funcionalidades
Dev Team deve fazer a entrega ao PO
PO deve aceitar ou não os Sprint Backlog Itens(US ou
BUG), se não forem aceitos, devem voltar para o Product
Backlog
Sprint Retrospective (<= 2 horas)
Inspeção e adaptação do processo
Usar dinâmicas diferentes de acordo com o
resultado da entrega
Definir plano de ação e responsáveis
Eventos

10. • https://www.scrumalliance.org/
• http://www.scrumguides.org/
• http://www.manifestoagil.com.br/
• http://www.manifestoagil.com.br/principios.html
• Imagens
– Capa http://www.therugbyblog.com
– Processo http://www.agileforall.com
Fontes