Get Started. It's Free
or sign up with your email address
Rocket clouds
Scrum Guide by Mind Map: Scrum Guide

1. Papéis

1.1. Time Scrum

1.1.1. Auto-Organizáveis

1.1.1.1. Times auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora do Time

1.1.2. Multifuncionais

1.1.2.1. Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe.

1.2. Product Owner

1.2.1. O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto.

1.2.1.1. Expressar claramente os itens do Backlog do Produto;

1.2.1.2. Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;

1.2.1.3. Otimizar o valor do trabalho que o Time de Desenvolvimento realiza,

1.2.1.4. Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir;

1.2.1.5. Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

1.3. Time de Desenvolviemnto

1.3.1. Definição

1.3.1.1. O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de cada Sprint. Um incremento “Pronto” é requerido na Revisão da Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.

1.3.1.2. Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de Desenvolvimento como um todo.

1.3.2. Características

1.3.2.1. Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente liberável;

1.3.2.2. Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.

1.3.2.3. O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento, independentemente do trabalho que está sendo realizado pela pessoa;

1.3.2.4. O Scrum não reconhece sub-times no Time de Desenvolvimento, independente dos domínios de conhecimento que precisam ser abordados, tais como teste, arquitetura, operação ou análise de negócios

1.3.2.5. Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo;

1.3.3. Tamano do Time

1.3.3.1. é pequeno o suficiente para se manter ágil e grande o suficiente para completar um trabalho significativo dentro da Sprint

1.3.3.2. Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade

1.4. Scrum Master

1.4.1. Definição

1.4.1.1. O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia Scrum.

1.4.2. Características

1.4.2.1. O Scrum Master ajuda todos a entenderem a teoria, as práticas, as regras e os valores do Scrum.

1.4.2.2. O Scrum Master é um líder-servidor para o Time Scrum.

1.4.2.3. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são.

1.4.2.4. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum.

1.4.3. SM Trabalhando para:

1.4.3.1. Product Owner

1.4.3.1.1. Garantindo que objetivos, escopo e domínio do produto sejam entendidos o melhor possível por todos do Time Scrum

1.4.3.1.2. Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto.

1.4.3.1.3. Ajudando o Time Scrum a entender as necessidades para ter items de Backlog do Produto claros e concisos.

1.4.3.1.4. Compreendendo o planejamento do Produto em um ambiente empírico;

1.4.3.1.5. Garantindo que o Product Owner saiba como organizar o Backlog do Produto para maximar valor;

1.4.3.1.6. Compreender e praticar a agilidade e Facilitar os eventos Scrum conforme exigidos ou necessários

1.4.3.2. Time de Desenvolvimento

1.4.3.2.1. Treinando o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade

1.4.3.2.2. Ajudando o Time de Desenvolvimento na criação de produtos de alto valor;

1.4.3.2.3. Removendo impedimentos para o progresso do Time de Desenvolvimento;

1.4.3.2.4. Facilitando os eventos Scrum conforme exigidos ou necessários;

1.4.3.2.5. Treinando o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

1.4.3.3. Orgainização

1.4.3.3.1. Liderando e treinando a organização na adoção do Scrum;

1.4.3.3.2. Planejando implementações Scrum dentro da organização;

1.4.3.3.3. Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico;

1.4.3.3.4. Causando mudanças que aumentam a produtividade do Time Scrum;

1.4.3.3.5. Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na organização

2. Artefatos

2.1. Backlog do Produto

2.1.1. O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto.

2.1.2. É a única origem dos requisitos para qualquer mudança a ser feita no produto

2.1.3. Um Backlog do Produto nunca está completo

2.1.4. O Backlog do Produto é dinâmico.

2.1.5. O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões.

2.1.6. Múltiplos Times Scrum frequentemente trabalham juntos no mesmo produto

2.1.7. O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto.

2.1.7.1. Este é um processo contínuo no qual o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos itens do Backlog do Produto

2.1.7.2. Durante o refinamento do Backlog do Produto, os itens são inspecionados e revisados.

2.1.7.3. O Time de Scrum decide como e quando o refinamento está “Pronto”

2.1.7.4. Este refinamento usualmente não consome mais de 10% da capacidade do Time de Desenvolvimento.

2.1.8. Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa.

2.1.9. Estimativas mais precisas são feitas baseadas em maior clareza e maior detalhamento

2.1.10. O Time de Desenvolvimento é responsável por todas as estimativas.

2.2. Backlog da Sprint

2.2.1. O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint

2.2.2. O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto”.

2.2.3. O Backlog da Sprint é um plano com detalhes suficientes que as mudanças no progresso sejam entendidas durante a Reunião Diária.

2.2.4. Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao Backlog da Sprint.

2.2.5. Conforme o trabalho é realizado ou completado, a estimativa do trabalho restante é atualizada

2.2.6. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint

2.2.7. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o Time de Desenvolvimento planeja completar durante a Sprint, e que pertence exclusivamente ao Time de Desenvolvimento.

2.3. Incremento

2.3.1. O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores.

2.3.2. Um incremento é uma parte principal inspecionável de trabalho pronto que suporta empirismo no final da sprint.

2.3.3. O incremento deve estar na condição de ser utilizado independente do Product Owner decidir por liberá-lo ou não.

3. História

3.1. 1986 - Artigo “The New New Product Development Game”, publicado por Takeuchi e Nonaka.

3.2. 1995 - Apresentação na Conferência em Austin, Texas o artigo "Scrum Software Development Process" por Jeff Sutherland e Ken Schwaber.

3.3. 2010 - Primeira Versão do "Scrum Guide" Versões subsequentes / 2011 / 2013 / 2016 / 2017

4. Definição do Scrum

4.1. Scrum é um framework para desenvolver, entregar e manter Produtos Complexos

4.2. Scrum é fundamentado nas teorias empíricas de controle de processo, ou empirismo.

4.3. O Scrum entrega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.

4.4. Pilares

4.4.1. Transparência

4.4.2. Inspeção

4.4.3. Adaptação

4.5. Valores

4.5.1. Comprometimentos

4.5.2. Coragem

4.5.3. Foco

4.5.4. Transparência

4.5.5. Respeito

4.6. Definição de “Pronto”

4.6.1. Quando um item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa.

4.6.2. Entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparência

4.6.3. Se “Pronto” para um incremento não é uma convenção de desenvolvimento da organização, o Time de Desenvolvimento do Time Scrum deve definir uma definição de “pronto” apropriada para o produto.

4.6.4. Se há múltiplos Times Scrum trabalhando no sistema ou versão do produto, os Times de Desenvolvimento de todos os Times Scrum devem mutuamente definir uma definição de “Pronto”.

5. Eventos

5.1. Sprint

5.1.1. Time-Box: Até 1 mês

5.1.2. Sempre é gerado um incremento de produto potencialmente liberável.

5.1.3. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.

5.1.4. As Sprints contém e consistem de um planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e uma retrospectiva da Sprint.

5.1.5. Durante A Sprint

5.1.5.1. Não são feitas mudanças que possam por em perigo o objetivo da Sprint

5.1.5.2. As metas de qualidade não diminuem

5.1.5.3. O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido

5.1.6. Cancelamento da Sprint

5.1.6.1. Somente o Product Owner tem a autoridade para cancelar a Sprint

5.1.6.2. A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto

5.1.6.3. Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é revisado. Se uma parte do trabalho estiver potencialmente liberável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto.

5.2. Planejamento da Sprint

5.2.1. Time-Box: De 8h para um sprint de 1 mês

5.2.2. O trabalho a ser realizado na Sprint é planejado durante o planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum.

5.2.3. A Meta da Sprint

5.2.3.1. A meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da implementação do Backlog do Produto. Este fornece uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento.

5.2.4. O planejamento da Sprint responde as seguintes questões:

5.2.4.1. O que pode ser entregue como resultado do incremento da próxima Sprint?

5.2.4.1.1. O Time de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidas durante a Sprint.

5.2.4.1.2. A entrada desta reunião é o Backlog do Produto.

5.2.4.1.3. O número de itens selecionados do Backlog do Produto para a Sprint é o único trabalho do Time de Desenvolvimento.

5.2.4.1.4. Somente o Time de Desenvolvimento pode avaliar o que pode ser completado ao longo da próxima Sprint.

5.2.4.2. Como o trabalho necessário para entregar o incremento será realizado?

5.2.4.2.1. Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o Time de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”.

5.2.4.2.2. O Time de Desenvolvimento frequentemente inicia o desenho do sistema e do trabalho necessário para converter o Backlog do Produto em um incremento funcional do produto.

5.2.4.2.3. O Time de Desenvolvimento se auto-organiza para realizar todo o trabalho do Backlog da Sprint, tanto durante o planejamento da Sprint quanto no que for necessário durante a Sprint.

5.2.4.2.4. O Product Owner pode ajudar a clarificar os itens de Backlog do Produto selecionados e nas decisões conflituosas de troca.

5.2.4.2.5. No final do planejamento da Sprint, o Time de Desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe auto-organizada para completar o objetivo da Sprint e criar o incremento previsto.

5.3. Reunião Diária

5.3.1. Time-Box: 15 Min

5.3.2. A Reunião Diária é realizada em todos os dias da Sprint

5.3.3. A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade.

5.3.4. O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao objetivo da Sprint e para inspecionar se o progresso tende na direção de completar o trabalho do Backlog da Sprint.

5.3.5. A estrutura da reunião é definida pelo Time de Desenvolvimento e pode ser conduzida de diferentes formas desde que estas foquem no progresso em direção à Meta da Sprint. Alguns Times de Desenvolvimento utilizarão perguntas, outros se basearão em discussões.

5.3.5.1. O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da Sprint?

5.3.5.2. O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da Sprint?

5.3.5.3. Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta da Sprint?

5.3.6. A Reunião Diária é uma reunião interna do Time de Desenvolvimento. Se outros estiverem presentes, o Scrum Master deve garantir que eles não perturbem a reunião.

5.3.7. Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento do Time de Desenvolvimento. Esta é uma reunião chave para inspeção e adaptação.

5.4. Revisão da Sprint

5.4.1. Time-Box: 4 Horas para um sprint de um mês.

5.4.2. A Revisão da Sprint é realizada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário.

5.4.3. Durante a Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint

5.4.4. Elementos da Reunião de Revisão

5.4.4.1. Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner;

5.4.4.2. O Product Owner esclarece quais itens do Backlog do Produto foram “Prontos” e quais não foram “Prontos”;

5.4.4.3. O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento;

5.5. Retrospectiva da Sprint

5.5.1. Time-box: 3h para um sprint de um mês.

5.5.2. A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint.

5.5.3. A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes do planejamento da próxima Sprint.

5.5.4. Propósito da Retrospectiva

5.5.4.1. Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos processos e às ferramentas;

5.5.4.2. Identificar e ordenar os principais itens que foram bem e as potenciais melhorias

5.5.4.3. Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho