1. A linha mostra o desempenho atual e cada barra o volume de histórias restantes
2. Monitorando projetos com Scrum
2.1. Monitoramento do projeto
2.1.1. Pode ser acompanhado por um gráfico burn-down
2.1.2. É responsabilidade do Dono do Produto monitorar o projeto em direção ao seu objetivo
2.1.3. O Dono do Produto determina a quantidade de trabalho restante e faz previsões para a data de finalização do projeto
2.2. Radiadores de informação
2.2.1. Podem ser qualquer display de informação grande e altamente visível
2.2.2. Servem para acompanhar o status do projeto ou qualquer outro tipo de informação
2.2.3. É necessário que o espaço de trabalho tenha lugar (paredes) para expor radiadores de informação
2.2.4. Todos na organização podem ter acesso
2.2.5. Diagramas comuns
2.2.5.1. Gráfico Burn-Down
2.2.5.1.1. Mostra a quantidade de trabalho restante em vez do trabalho completado
2.2.5.1.2. Pode mostrar trabalho restante da Sprint ou do Projeto
2.2.5.1.3. Eixo vertical mostra o total de trabalho e o eixo horizontal o tempo que se passou
2.2.5.1.4. Linha do desempenho atual acima da linha do planejado mostra que o time está atrasado
2.2.5.1.5. Linha do desempenho atual abaixo da linha do planejado mostra que o time está adiantado
2.2.5.2. Burn-down com barras
2.2.5.2.1. Serve para visualizar as mudanças no Backlog
2.2.5.2.2. Se forem adicionadas novas histórias no backlog, a parte inferior da barra vai descer. Se remover histórias, então a barra vai ficar menor.
2.2.5.3. Gráfico Burn-up
2.2.5.3.1. Mostra o volume de histórias "Prontas" em vez de histórias restantes
2.2.5.3.2. A linha azul mostra o volume total de histórias no backlog e a linha preta o volume de histórias "Prontas"
2.2.5.4. Calendário niko-niko
2.2.5.4.1. Mostra o humor e moral dos membros do time através de emoticons
2.3. Monitorando o progresso das Sprints
2.3.1. É de responsabilidade do Time de Desenvolvimento
2.3.2. A reunião Diária do Scrum facilita isto
2.3.3. O progresso pode ser representado por um gráfico burn-down e este pode fazer parte do quadro da Sprint
2.4. Velocidade
2.4.1. É o número de pontos de história completados em um certo intervalo
2.4.2. É calculado a partir da média de pontos de histórias prontas em Sprints anteriores
2.4.3. Exemplo: Sprint 1: 80 pontos Sprint 2: 70 pontos Sprint 3: 90 pontos Velocidade: (80 + 70 + 90)/3= 80 pontos
2.5. Quadros Kanban
2.5.1. Quadro visual para acompanhar o progresso das atividades
2.5.2. Ajuda a criar transparência e controle
3. Conceitos avançados no Scrum
3.1. Escalando o Scrum
3.1.1. Necessário escalar o Scrum quando o projeto necessita de mais de 9 desenvolvedores
3.1.2. Cada time de desenvolvimento deve ficar com 3 a 9 pessoas
3.1.3. Escalação de Papéis
3.1.3.1. Scrum Master
3.1.3.1.1. Cada Time de Desenvolvimento deve contar com um Scrum Master
3.1.3.1.2. Uma única pessoa pode ser Scrum Master local de vários times ao mesmo tempo
3.1.3.1.3. Quando existir diferentes Scrum Masters locais, recomenda-se existir um Scrum Master Chefe para a coordenação deles
3.1.3.2. Product Owner
3.1.3.2.1. Cada Time de Desenvolvimento deve contar com um Dono de Produto
3.1.3.2.2. Uma única pessoa pode ser Dono de Produto local de vários times ao mesmo, embora na prática dificilmente conseguirá ser Dono de Produto de mais de 2 ou 3 times
3.1.3.2.3. Quando existir diferentes Donos de Produtos locais, recomenda-se existir um Dono de Produto Chefe para a coordenação deles
3.1.4. Propriedade do Produto
3.1.4.1. Deve haver um único Backlog de produto independente da quantidade de times que estão trabalhando no projeto
3.1.4.2. Os times de desenvolvimento geralmente são distribuídos de acordo com o grupo de funcionalidades
3.1.4.3. Recomenda-se que todos os times adotem a mesma definição de "pronto" ou pelo menos compatível já que os incrementos precisam ser integrados
3.1.5. Scrum of Scrums
3.1.5.1. Reunião diária com um representante de cada time para coordenação do trabalho entre eles
3.1.5.2. Perguntas respondidas nesta reunião
3.1.5.2.1. No que o meu time tem trabalhado desde a última reunião?
3.1.5.2.2. O que o meu time vai fazer até a próxima reunião?
3.1.5.2.3. O que os outros times estavam esperando o nosso time concluir que ainda não foi feito?
3.1.5.2.4. O que o nosso time está planejando fazer que poderá afetar os outros times?
3.1.6. Sincronização de eventos
3.1.6.1. Recomenda-se sincronizar os eventos do Scrum entre os times
3.1.6.1.1. Por exemplo, iniciar suas Sprints ao mesmo tempo
3.1.7. Estratégias de Divisão de Times
3.1.7.1. Formar times completamente novos
3.1.7.2. Dividir os times
3.1.7.2.1. Split-and-Seed
3.1.7.2.2. Grow-and-Split
3.2. Tipos de contratos no Scrum
3.2.1. Tempo & meios ou unidade fixa
3.2.1.1. É o tipo preferido de contrato no ambiente ágil
3.2.1.2. Mais compatível com a natureza adaptativa do projeto
3.2.1.3. O cliente é cobrado por horas trabalhadas ou por Sprint
3.2.2. Preço fixo
3.2.2.1. Não é indicado para o ambiente ágil
3.2.2.2. O preço fixo é baseado na definição inicial do escopo que tende a ser fixa
3.2.2.3. Oferece menos risco para o cliente
3.3. Pré-requisitos para adotar o Scrum
3.3.1. Um time Ágil
3.3.1.1. Scrum Master experiente
3.3.1.2. Dono do Produto experiente
3.3.1.3. Time de Desenvolvimento experiente, multifuncional e auto-organziado
3.3.2. Um produto capaz de ser produzido incrementalmente e interativamente
3.3.3. Uma empresa Ágil
3.3.3.1. A organização também deve entender e respeitar os princípios do Ágil
3.3.4. Um cliente Ágil
3.3.4.1. Deve estar disponível para colaboração com o time
3.3.4.2. Deve entender as diferenças entre o ambiente Ágil e o tradicional
3.3.4.3. Deve estar pronto para adoção de contratos de tempo & meios em vez de contratos de preço fixo
4. Papéis no Scrum
4.1. Time Scrum
4.1.1. Refere-se a todos os membros do projeto incluindo o Scrum Master, Time de Desenvolvimento e Dono do Produto
4.1.2. Faz parte da organização executora do projeto
4.1.3. Principais características
4.1.3.1. Auto-organizado
4.1.3.1.1. Gerencia seu esforços em vez de ser gerenciado por outros
4.1.3.2. Multifuncional
4.1.3.2.1. Tem todas as competências necessárias para fazer seu trabalho sem depender de ninguém de fora do time
4.2. Product Owner
4.2.1. Responsável pelo Backlog do Produto
4.2.2. Tem mais conhecimento nos aspectos do negócio que conhecimentos técnicos
4.2.3. Preocupado em maximizar o valor do produto e do trabalho do Time De Desenvolvimento
4.2.4. Prioriza os itens do Backlog do Produto com base no retorno sobre o investimento, mas pode utilizar outros critérios de priorização também
4.2.5. É sempre uma pessoa e não um comitê
4.2.5.1. Pode representar um comitê, mas será uma única pessoa a interagir com o Time de Desenvolvimento
4.2.6. Assume todas as comunicações sobre o conteúdo do projeto com partes internas e externas
4.2.7. Tem que assegurar que cada item do backlog do produto é entendido pelo Time Scrum e outras partes interassadas
4.2.8. Deve se comunicar de forma eficiente com o cliente e com o Time de Desenvolvimento
4.2.9. Deve medir o desempenho do projeto, fazer previsões de data finalização do projeto e comunicar isto para todas as partes interessadas
4.2.10. Pode ser influenciado pelos outros, mas a decisão final é sempre dele
4.2.11. Pode delegar algumas de suas atividades, mas ele continua sendo o prestador de contas delas (por exemplo, escrever os itens do Backlog do Produto)
4.3. Scrum Master
4.3.1. É quem mais entende de Scrum e ajuda o Time Scrum no uso de suas práticas
4.3.2. É uma posição gerencial
4.3.2.1. Gerencia o processo Scrum em vez do Time Scrum
4.3.2.2. É um líder-servo
4.3.3. Resolve impedimentos (questões) do Time de Desenvolvimento, facilita seus eventos e atua como um coach (treinador)
4.3.4. Ajudar o Product Owner no uso de técnicas e facilita eventos relacionados a ele
4.3.5. Pode ajudar pessoas de fora do Time Scrum a interagirem com este time
4.3.6. Ajuda a adotar o Scrum na organização
4.3.7. É possível que a mesma pessoa seja Scrum Master e também membro do Time de Desenvolvimento, mas isto não é recomendado
4.3.8. Não se envolve com o conteúdo da Sprint (estimativas, valor de negócio, histórias, incrementos)
4.3.9. Assume todas as comunicações no que se refere ao Processo Scrum
4.3.10. Pode assumir temporariamente a posição do Product Owner em situações específicas (por exemplo, férias)
4.4. Time de Desenvolvimento
4.4.1. Inclui os desenvolvedores responsáveis por entregar os itens do Backlog e gerenciar seus próprios esforços
4.4.2. Tamanho ideal de 3 a 9 membros
4.4.2.1. Mais do que isto tem que usar um modelo escalado
4.4.3. É recomendado que os membros trabalhem em tempo integral em um único projeto
4.4.4. É recomendado não alterar a sua composição frequentemente porque isto diminui sua produtividade
4.4.5. Os membros devem ser capazes de fazer tudo que estiver envolvido em cada item do Backlog do Produto
4.5. Gerente de projetos tradicional
4.5.1. Não existe este papel no Scrum
4.5.2. A gestão do projeto é distribuída entre o Product Owner e o Scrum Master
5. Informações sobre este mapa
5.1. Este mapa resume os principais tópicos para o exame EXIN Agile Scrum Foundation usando como referência o livro EXIN Agile Scrum Foundation Workbook
5.2. Os tópicos não estão na sequência do conteúdo do curso, mas sim na sequência do currículo do exame
5.3. Entendendo o conteúdo deste mapa provavelmente você conseguirá responder a maior parte das questões do exame
6. Mentalidade Ágil
6.1. Conceitos de Ágil e Scrum
6.1.1. Agile/Ágil
6.1.1.1. Refere-se a vários frameworks usados para o desenvolvimento e gerenciamento de iniciativas (projetos ou programas)
6.1.1.2. Principal objetivo desses frameworks é o desenvolvimento rápido e suave para criar uma entrega que satisfaça o cliente
6.1.1.3. Usa ciclos de vida adaptativos em vez de preditivos
6.1.1.3.1. É diferente do modelo Cascata no qual tudo precisa ser definido antecipadamente e os estágios de desenvolvimento são executados sequencialmente
6.1.1.3.2. A característica principal do ciclo de vida adaptativo é o desenvolvimento incremental e iterativo
6.1.1.3.3. Os frameworks ágeis somente podem ser aplicados no desenvolvimento de produtos que podem ser construídos de maneira interativa e incremental
6.1.2. Principais frameworks ágeis
6.1.2.1. Scrum
6.1.2.1.1. Nome tem como origem o Rugby
6.1.2.1.2. Vantagem principal é que o time irá demonstrar software funcionando a cada poucas semanas
6.1.2.1.3. Para adotá-lo é importante que o cliente aceite o seu "valor"
6.1.2.1.4. O comprometimento da gerência sênior ajuda na transformação cultural necessária para a sua adoção
6.1.2.2. XP
6.1.2.3. DSDM Atern
6.1.2.4. Crystal
6.1.3. 4 Valores do Manifesto Ágil
6.1.3.1. Indivíduos e interações mais que processos e ferramentas
6.1.3.2. Software em funcionamento mais que documentação abrangente
6.1.3.3. Colaboração com o cliente mais que negociação de contratos
6.1.3.4. Responder a mudanças mais que seguir um plano
6.1.4. 12 Princípios do Ágil
6.1.4.1. Nossa maior prioridade é satisfazer o cliente por meio da entrega adiantada e contínua de software de valor.
6.1.4.2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
6.1.4.3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
6.1.4.4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
6.1.4.5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
6.1.4.6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.
6.1.4.7. Software funcionando é a medida primária de progresso.
6.1.4.8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
6.1.4.9. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
6.1.4.10. Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é essencial.
6.1.4.11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
6.1.4.12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.
6.1.5. Escopo do produto em ambientes ágeis
6.1.5.1. Não forçamos o cliente a especificar tudo antecipadamente, ele pode decidir as coisas ao longo do projeto
6.1.5.2. Ajudamos o cliente e entender o valor de negócio de cada funcionalidade para evitar desenvolver algo que não seja útil
6.1.5.3. Em projetos ágeis geralmente o tempo, custo e qualidade são fixos e o escopo (funcionalidades) é variável. Desta forma serão desenvolvidas somente as funcionalidades realmente úteis dentro do custo e tempo e sem comprometer a qualidade.
7. Práticas do Scrum
7.1. Eventos no Scrum
7.1.1. Timebox
7.1.1.1. Significa duração de tempo máxima predefinida
7.1.1.1.1. Nunca devemos estender a duração de uma timebox porque não terminamos algo
7.1.1.2. Todos os eventos no Scrum são timeboxed
7.1.1.3. Ajuda a criar regularidade e disciplina
7.1.2. Sprint
7.1.2.1. É uma iteração que ocorre no projeto com Scrum
7.1.2.2. É um evento time-boxed
7.1.2.3. É um contêiner dentro do qual ocorrem os outros quatro eventos do Scrum
7.1.2.4. São gerados incrementos ao seu final
7.1.2.4.1. São soma de todos os itens do Backlog do Produto no final de uma Sprint
7.1.2.4.2. Cada incremento precisa estar "Ponto" e precisa ser potencialmente liberável no final da Sprint, embora a liberação só vai ocorrer com a decisão do Dono de Produto
7.1.2.5. Não existe Sprint 0, toda Sprint deve ter entrega de incrementos potencialmente liberáveis
7.1.2.6. Só finaliza quando o seu time-box termina
7.1.2.7. Cancelamento da Sprint
7.1.2.7.1. Somente o Dono de Produto tem autoridade para isto
7.1.2.7.2. Pode ocorrer porque o objetivo da Sprint se tornou obsoleto devido a mudanças no Backlog do Produto, estratégias, etc.
7.1.2.7.3. Quando ocorre, o que estiver "Pronto" será revisado e aceito e o resto volta para o Backlog do Produto
7.1.2.8. Duração da Sprint
7.1.2.8.1. Não pode ter duração maior que um mês
7.1.2.8.2. Recomenda-se não fazer alterações nas durações das Sprints frequentemente
7.1.2.8.3. A duração pode ser ajustada se identificado que ela não é apropriada para o projeto
7.1.3. Planejamento da Sprint
7.1.3.1. É o primeiro evento dentro da Sprint
7.1.3.2. Serve para definir o objetivo da Sprint e selecionar itens para desenvolver a partir do topo do Backlog de Produto
7.1.3.3. Resulta no Backlog da Sprint que é um comprometimento do que o Time de Desenvolvimento irá entregar ao final
7.1.3.4. É uma time-box de 8 horas para uma Sprint de um mês
7.1.3.5. Todos os integrantes do Time Scrum participam
7.1.4. Scrum Diário
7.1.4.1. Vai ocorrer diariamente durante a Sprint, exceto quando ocorrem outros eventos do Scrum
7.1.4.2. Sempre uma time-box de 15 minutos
7.1.4.3. Serve para o Time de Desenvolvimento inspecionar o trabalho feito deste a última reunião e sincronizar seu plano para as próximas 24 horas
7.1.4.4. Membros respondem a 3 perguntas
7.1.4.4.1. O que foi feito deste da última reunião?
7.1.4.4.2. O que será feito antes da próxima reunião?
7.1.4.4.3. Quais são os obstáculos no caminho?
7.1.4.5. Recomenda-se que seja sempre no mesmo local e horário para minimizar sua complexidade
7.1.4.6. Não é recomendado a participação de outras pessoas que não fazem parte do Time de Desenvolvimento
7.1.4.6.1. Se outras pessoas participarem, será apenas como ouvintes
7.1.4.7. Não deve ser vista como uma reunião de status para as partes interessadas
7.1.5. Revisão da Sprint
7.1.5.1. Ocorre antes do final da Sprint
7.1.5.2. Serve para demonstrar o incremento "Pronto" da Sprint para o cliente e outra partes interessadas e para receber o feedback
7.1.5.3. Tem 4 horas de duração para uma Sprint de um mês
7.1.5.4. Todos os integrantes do Time Scrum participam
7.1.5.5. Somente devem ser apresentados itens 100% completos de acordo com a definição de "Pronto"
7.1.5.6. Itens que não estiverem "Prontos" devem voltar para o Backlog do Produto e o Product Owner irá definir uma prioridade novamente
7.1.6. Retrospectiva da Sprint
7.1.6.1. Ocorre depois da Revisão da Sprint
7.1.6.2. Serve para fazer melhorias no processo de desenvolvimento e coletar lições aprendidas
7.1.6.3. O Time Scrum inspeciona o que foi feito na Sprint em relação a pessoas, relações, processos e ferramentas, e identifica formas de melhorar para a próxima Sprint
7.1.6.4. Reunião de 3 horas para uma Sprint de um mês
7.1.6.5. Todos os integrantes do Time Scrum participam
7.2. Backlogs
7.2.1. Backlog do Produto
7.2.1.1. Características
7.2.1.1.1. É uma lista ordenada de tudo que é necessário no produto final do projeto
7.2.1.1.2. Todos os itens são descritos de maneira simples, de preferência em linguagem não técnica
7.2.1.1.3. Inclui todos os requisitos do cliente
7.2.1.1.4. É dinâmico, pode mudar e nunca estará completo
7.2.1.1.5. O Dono do Produto é o responsável por mantê-lo
7.2.1.1.6. Deve haver apenas um único Backlog de Produto para o projeto, independente do número de times envolvidos
7.2.1.2. Ordenação dos itens
7.2.1.2.1. Feita pelo Dono de Produto
7.2.1.2.2. Principais critérios
7.2.1.2.3. Técnica MoSCoW
7.2.1.3. Grooming/Refinamento
7.2.1.3.1. É o ato de revisão dos itens, o que tipicamente envolve adicionar detalhes, estimativas e prioridades
7.2.1.3.2. Não deve consumir mais de 10% do tempo do Time de Desenvolvimento
7.2.1.3.3. É uma atividade contínua durante a Sprint, não é uma time-box
7.2.1.4. Itens do Backlog do Produto
7.2.1.4.1. Informações Básicas
7.2.1.4.2. Histórias de usuário
7.2.2. Backlog da Sprint
7.2.2.1. É criado durante a reunião de Planejamento da Sprint
7.2.2.2. Inclui itens selecionados do Backlog do Produto para serem entregues durante uma Sprint e o plano para transformar os itens selecionados em incrementos
7.2.2.3. Pode ser visto como um plano para a entrega dos itens e realização do Objetivo da Sprint durante a Sprint
7.2.2.4. O Time de Desenvolvimento é dono deste Backlog e somente ele pode fazer atualizações
7.2.2.5. O Time de Desenvolvimento pode fazer atualizações ao longo da Sprint
7.2.2.6. Recomenda-se que os itens do backlog do produto que foram selecionados para a sprint fiquem congelados durante a Sprint
7.2.2.6.1. Recomenda-se não fazer inclusão ou remoção de itens durante a Sprint, mas se isto ocorrer é necessário consultar o Dono do Produto
7.2.2.7. Pode ser representado por um quadro
7.2.2.8. Spikes
7.2.2.8.1. São itens adicionados no Backlog da Sprint quando precisamos investir um tempo de estudos em algo
7.2.2.8.2. Podem ser criadas para achar uma forma de desenvolver algo ou para entender melhor uma funcionalidade requerida
7.2.2.8.3. Geralmente tem duração máxima de 1 a 2 dias
7.3. Definição de "Pronto"
7.3.1. Entendimento compartilhado do significado para um pedaço de trabalho ser considerado "pronto" ou "finalizado"
7.3.2. Se a definição de “pronto” para um incremento é parte das convenções, padrões ou diretrizes de desenvolvimento da organização, todos os Times Scrum devem segui-la como um mínimo
7.3.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
7.3.4. Se há múltiplos Times Scrum trabalhando no lançamento do sistema ou produto, os times de desenvolvimento de todos os Times Scrum devem mutuamente definir a definição de “pronto”.
7.3.5. Esta definição contém:
7.3.5.1. Processos de desenvolvimento a serem realizados para cada item do backlog (especificação, desenho, programação, teste, documentação, etc.)
7.3.5.2. Processos organizacionais necessários
7.3.5.3. Requisitos não-funcionais que precisam ser atendidos (desempenho, segurança, usabilidade, etc.), se estes forem aplicados a todas as histórias de usuário
7.3.5.3.1. Exemplo: toda pesquisa não pode demorar mais de 2 minutos
7.3.5.4. Critérios de qualidade (padrões de código, por exemplo)
7.4. Métodos e práticas associadas ao Scrum
7.4.1. Documentação
7.4.1.1. O Scrum prefere entregar software em vez de documentação
7.4.1.2. Scrum prega que a documentação seja somente do que for realmente necessário
7.4.1.3. Haverá certos documentos que continuam sendo indispensáveis, tais como manuais de operação, documentação de configurações
7.4.2. Testes ágeis
7.4.2.1. Os testes podem fazer parte dos critérios da Definição de "Pronto"
7.4.2.1.1. Exemplo: teste de aceitação
7.4.2.2. No ambiente ágil, geralmente os testes são mais frequentes
7.4.2.3. Sempre que possível, buscar a automação dos testes
7.4.3. Programação em pares
7.4.3.1. Consiste em ter dois desenvolvedores trabalhando no mesmo computador
7.4.3.1.1. Um é chamado de Driver (escreve o código)
7.4.3.1.2. E outro de navegador (observa e fornece comentários)
7.4.4. Desenvolvimento orientado a testes (TDD)
7.4.4.1. Prática na qual os cenários de teste são preparados antes de escrever o programa, assim o programador sabe o que os outros esperam dele
7.4.5. Refatatoração contínua
7.4.5.1. Processo de modificar um sistema de software para melhorar a estrutura interna do código sem mudar suas funções externas
7.4.6. Interação contínua
7.4.6.1. O desenvolvedor integra o código alterado e/ou desenvolvido ao projeto principal na mesma frequência com que as funcionalidades são desenvolvidas, sendo feito muitas vezes ao dia ao invés de apenas uma vez
7.4.7. Propriedade coletiva do código
7.4.7.1. Ninguém em um time ágil é dono de um código, todos são responsáveis por tudo e todos podem mudar qualquer parte do código
7.4.8. Comunicação osmótica
7.4.8.1. Os membros do time são colocados para trabalhar na mesma sala, o que favorece ouvir o que se fala e colaborar com a discussão
7.4.9. Times colocalizados
7.4.9.1. Sempre que possível colocar os times trabalhando na mesma sala
7.4.10. Espaço de trabalho adequado
7.4.10.1. Importante ter espaço adequado para os eventos do Scrum
7.4.10.2. Melhor ter um time colocalizado em vez de ter membros espalhados pelos departamentos
7.4.11. Ambiente sustentável
7.4.11.1. Evitar exigir horas extras do time
7.4.11.2. Criar um ambiente alegre
7.4.12. Lidando com bugs
7.4.12.1. Bugs podem ser identificados durante a demonstração na reunião de Revisão da Sprint ou após a liberação do produto para o cliente
7.4.12.2. Podem ser criadas histórias para os bugs e adicionar ao Backlog o Produto e então o Dono de Produto define em que Sprint os bugs serão corrigidos
7.4.12.3. Defeito escapado
7.4.12.3.1. Defeito que foi descoberto pelo cliente
8. Planejamento e Estimativas Scrum
8.1. Planejamento no Scrum
8.1.1. Cebola do planejamento (Planning Onion)
8.1.1.1. Parecido com os anéis de uma cebola
8.1.1.2. Os níveis são os momentos que devemos realizar os planejamentos
8.1.1.3. Em um projeto Ágil há quatro níveis
8.1.1.3.1. Planejamento de produto
8.1.1.3.2. Planejamento de release(versão)
8.1.1.3.3. Planejamento de iteração
8.1.1.3.4. Planejamento diário
8.1.2. Planejamento de Release
8.1.2.1. Produz um plano de quando serão liberadas as funcionalidades (histórias) para os clientes
8.1.2.2. Realizado pelo Dono do Produto em colaboração com o cliente e outras partes interassadas
8.1.2.3. A priorização do que deve ser liberado fica por conta do Dono do Produto
8.1.2.4. Não existe um artefato ou um evento formal no Scrum Guide para isto
8.2. Estimativas no Scrum
8.2.1. São fornecida somente pelo Time de Desenvolvimento
8.2.2. Pontos por história
8.2.2.1. Unidades de esforço que mostram a quantidade de trabalho requerido para uma história comparada com outras ou com uma simples história de referência
8.2.3. Planning Poker
8.2.3.1. Primeiro, o Dono do Produto explica a história de usuário. Então, o time discute a abordagem de desenvolvimento. E, finalmente, cada membro vota aprentando um cartão com a sua estimativa
8.2.3.2. Favorece discussão útil no time
8.2.3.3. Usa a sequência de Fibonacci nas cartas para apresentar as estimativas
8.2.4. Triangulação
8.2.4.1. Envolve comparar um história com várias outras para aumentar a confiança das estimativas
8.2.4.2. As histórias podem ser agrupadas por pontos por história para facilitar a comparação (igual a estimativa por afinidade)
8.2.5. Estimativa por afinidade
8.2.5.1. Agrupam-se as histórias por pontos
8.2.5.2. Utilizada quando há um grande número de histórias para serem estimadas
8.2.6. Horas ideais / dias ideais
8.2.6.1. Alguns times ágeis usam esta forma de estimativa porque ela é mais fácil de entender e explicar
8.2.6.2. Consiste em estimar o esforço de desenvolvimento de uma história em horas / dias úteis de trabalho, descontando horas não produtivas, como tempo para o café, responder e-mails, reuniões administrativas, etc.