1. Mapa desenvolvido pela TIEXAMES
1.1. www.tiexames.com.br
1.2. Não divulgue este material
1.3. Somente alunos matriculados no curso devem usá-lo
1.4. Incluímos o essencial para o exame
1.5. Não há garantia de aprovação no examep apenas decorando este mapa
2. Gerenciamento de Produto
2.1. Produto
2.1.1. É qualquer coisa que pode ser oferecida ao mercado que pode satisfazer uma necessidade ou um desejo
2.2. Gerenciamento de Produto
2.2.1. Atua nos 3 Vs: Visão, Valor e Validação
2.2.2. É um trabalho que PO vai ter que fazer e não está descrito dentro do Framework Scrum
2.3. Visão do Produto
2.3.1. Fornece um motivo claro para qual o produto está sendo criado e quais são as necessidades do clienbte
2.3.2. Precisa ser inspiradora, estratégica, documentada e comunicada
2.3.3. Não é mandatório como parte do Framework Scrum, mas é um orientador importante
2.3.4. PO é responsável por essa definição
2.3.5. Serve também para PO e o Time Scrum a comparar o valor e relevância de um Item do Backlog do Produto
2.3.6. Onde a Visão do Produto é observada no Scrum
2.3.6.1. Planejamento de Sprint
2.3.6.1.1. Momento de relembrar a visão do produto e como o Backlog do Produto se encaixa nisso
2.3.6.1.2. Ajuda a criar uma Meta de Sprint mais Efetiva
2.3.6.2. Revisão da Sprint
2.3.6.2.1. Oportunidade de reforçar a visão com o time e stakeholders
2.3.6.3. Retrospectiva da Sprint
2.3.6.3.1. Oportunidade de rever sobre a efetividade das comunicações da visão
2.4. Roadmap do produto
2.4.1. Prática externa ao Scrum Guide
2.4.2. O Product Owner utiliza o Roadmap para descrever as funcionalidades futuras do produto e quando novos recursos serão lançados
3. Maximização de valor
3.1. O PO é accountable por maximizar o valor do produto entregue assim como do trabalho do time
3.2. O Time Scrum Inteiro se responsabiliza por produzir um incremento de valor
3.3. Definição de valor
3.3.1. Depende do contexto
3.3.2. Valor somente é entregue a partir de liberações (releases)
3.4. A medição do valor do que é entregue envolve obter mais ROI e menos TCO
3.4.1. Return on Investment (ROI)
3.4.1.1. Representa os benefícios obtidos com o investimento versus os custos despendidos
3.4.1.2. Priorizar os itens que serão mais usados pelos usuários tem a chance de criar valor e também aumentar o ROI
3.4.2. Total Cost of Ownership (TCO)
3.4.2.1. Inclui não apenas o custo de desenvolvimento, mas também de manutenção e operação do produto ao longo da sua vida
3.4.2.2. Um produto com qualidade técnica reduz o seu custo de manutenção, logo gera um TCO menor para a organização
3.4.2.3. O PO é responsável por maximizar o valor do Produto e do trabalho dos Desenvolvedores, assegurando que o resultado tenha mais ROI e menos TCO
3.5. Redução do Débito Técnico
3.5.1. Refere-e ao trabalho não feito que deveria ter sido feito
3.5.2. Decisões ruins sobre o design ou uma Definição de "Pronto" não adequada pode levar a lacunas de qualidade e essas lacunas criam débito técnico e reduzem o valor do produto
3.5.3. TCO pode ser reduzido com a redução do Débito Técnico
3.5.4. É importante que o PO junto com o Time revise a Definição de Pronto para reduzir esse débito
3.6. Evidence Based Management
3.6.1. Framework para medir o valor de um produto
3.6.2. Lista várias métricas que o PO pode usar para medir continuamente o valor e sucesso do produto
3.6.3. Áreas-chave de medição
3.6.3.1. Current Value
3.6.3.1.1. Mede o valor entregue ao cliente ou usuário hoje
3.6.3.1.2. Medição de satisfação do cliente é uma métrica importante aqui
3.6.3.1.3. Net Promoter Score (NPS)
3.6.3.2. Unrealized Value
3.6.3.2.1. Mede o valor que pode ser realizado atendendo a todas as necessidades potenciais do cliente ou usuário
3.6.3.3. Ability to Innovate
3.6.3.3.1. Mede a capacidade de fornecer um novo recurso que pode atender melhor às necessidades de um cliente ou usuário
3.6.3.4. Time to Market
3.6.3.4.1. Mede a capacidade de entregar rapidamente novos recursos, serviços ou produtos
3.6.3.4.2. Frequência de liberações é uma métrica importante
3.7. Sucesso do produto
3.7.1. Medido primariamente pela satisfação do cliente, em seguida pode ser combinado com o impacto na receita de vendas e nos custos (menor TCO)
4. Gerenciamento de Liberação
4.1. Liberar algo produção é a única forma de criar valor e validar suposições
4.2. Os incrementos estarão "prontos" ao final de cada Sprint, mas só o PO decide liberar ou não
4.3. Existem muitas razões para fazer uma liberação, como solicitação de um cliente e correção de defeitos
4.4. A velocidade do time pode ser usada como base para estimar quantos itens pode ser entregues a cada Sprint
4.5. Cone da incerteza
4.5.1. Qando um projeto está em seu início, é impossível saber com precisão como o trabalho vai progredir pois o mesmo depende de uma série de coisas: habilidade do time, expectativa do cliente (será que ele realmente sabe o que quer e precisa?), alterações de escopo.
4.5.2. A medida em que o projeto se desenvolve, o conhecimento aumenta em várias áreas e mais detalhes podem ser obtidos permitindo que os envolvidos tenha mais informações e certezas.
5. Definição de Pronto e Preparado
5.1. Definição de "Pronto/Done"
5.1.1. Usada para definir quando o trabalho está completado no incremento do produto
5.1.2. Orienta os desenvolvedores sobre quantos itens do backlog do produto podem ser selecionados durante a reunião de planejamento da Sprint
5.1.3. Pode fazer parte de convenções, padrões ou diretrizes de desenvolvimento da organizaçã
5.1.4. Se não fizer parte dos padrões da organização, o Time Scrum cria uma
5.1.4.1. Envolve o PO em conjunto com o Time
5.1.5. Pode conter requisitos/condições de acordo com o contexto
5.1.5.1. Unidade testada
5.1.5.2. Código revisado
5.1.5.3. Sem defeitos conhecidos
5.1.5.4. Testes de aceitação realizados com sucesso
5.1.5.5. Aprovado pelo PO
5.1.5.6. Testes de regressão realizados com sucesso
5.1.5.7. Guia de usuário atualizada
5.1.5.8. Testes de Segurança realizados com sucesso
5.1.5.9. Etc.
5.2. Definição de "Preparado/Ready"
5.2.1. O Scrum Guide não define esse conceito, logo ele não é mandatório
5.2.2. Orienta o processo de Refinamento do Backlog do Produto
5.2.3. Os itens do Backlog do Produto precisam estar "Ready" para entrar nas próximas Sprints
5.2.4. Significa ter Itens de Blacklog de Produto no tamanho adequado, estimados, com critérios de aceite claros
6. Fundamentos do Scrum
6.1. Scrum é um framework e não uma metodologia
6.1.1. Indicado para gerenciar desenvolvimento de produtos complexos
6.1.2. Você pode empregar vários processos ou técnicas dentro deste framework
6.2. Adota o desenvolvimento iterativo e incremental
6.2.1. Entregas pequenas e parciais a cada mês, pelo menos
6.2.2. Entrega do maior valor agregado mais cedo
6.2.3. Redução das incertezas por meio de entregas menores e rápidas
6.2.4. Permite a rápida e contínua inspeção
6.3. Entrega de valor
6.3.1. As necessidades do negócio determinam as prioridades do desenvolvimento
6.3.2. O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team
6.4. Foco mais nas pessoas e menos no processo
6.5. Processo empírico
6.5.1. Aceita que um problema não pode ser completamente entendido ou definido
6.5.2. Foca na maximização da habilidade do time de responder de forma ágil aos desafios emergentes
6.5.3. O time adapta os processos rapidamente para atingir melhores resultados
6.6. Não é recomendado fazer alterações no vocabulário ao implantar na organização
6.7. Times devem ser autogerenciados
6.7.1. Os membros são multifuncionais - podem atuar em todas as atividades da sprint
6.7.2. Não precisam de um gerente de projeto (o Scrum master é um líder-servo e o PO se responsabiliza pelo produto)
6.7.3. Compostas por pessoas comprometidas
6.7.4. Determinam as tarefas necessárias para os itens selecionados para a Sprint
6.7.5. As tarefas são dos Desenvolvedores e todos são responsáveis; ninguém individualmente se apropria de uma tarefa
6.7.6. Não há líderes funcionais dentro do time
6.7.7. O Scrum Master e Product Owner não são chefes do Time Scrum
6.7.8. Se for necessário mais de um time para o mesmo produto, permitir que os membros se dividam em grupos
6.8. Pilares do Scrum
6.8.1. Transparência
6.8.1.1. Informações devem ser visíveis para todos
6.8.1.2. Informações são entendidas por todos da mesma maneira
6.8.1.3. Estimativas são dadas de acordo com o que cada desenvolvedor realmente acredita
6.8.1.4. Problemas não podem ser escondidos
6.8.1.5. Comprometer-se somente com aquilo que se acredita
6.8.2. Inspeção
6.8.2.1. Os artefatos do Scrum e o progresso em direção às metas acordadas devem ser inspecionados com frequência.
6.8.2.2. A inspeção é a base para a adaptação
6.8.3. Adaptação
6.8.3.1. Alterações são feitas no processo para evitar erros e problemas
6.8.3.2. Feita pelo Time Scrum
6.8.3.3. As diversas reuniões do Scrum são aproveitadas para realizar inspeção e adaptação
6.8.3.4. O ajuste deve ser feito o mais rápido possível para minimizar novos desvios.
6.8.3.5. Espera-se que um Time Scrum se adapte no momento em que aprende algo novo por meio da inspeção
6.9. Valores do Scrum
6.9.1. Compromisso
6.9.1.1. O Time Scrum se compromete a atingir seus objetivos e suportar uns aos outros
6.9.2. Foco
6.9.2.1. O foco principal do Time Scrum é o trabalho da Sprint para fazer o melhor progresso possível em direção às metas.
6.9.3. Abertura
6.9.3.1. O Time Scrum e seus stakeholders são abertos quanto ao trabalho e os desafios
6.9.4. Respeito
6.9.4.1. Os membros do Time Scrum se respeitam quanto a serem pessoas capazes e independentes, e são respeitados como tal pelas pessoas com quem trabalham.
6.9.5. Coragem
6.9.5.1. Os membros do Time Scrum têm a coragem de, fazer a coisa certa e trabalhar em problemas difíceis
7. Papeis no Scrum
7.1. Há um Time Scrum
7.1.1. Responsável por todas as atividades relacionadas ao produto
7.1.2. São multifuncionais
7.1.2.1. Os membros possuem todas as habilidades necessárias para criar valor/incremento a cada Sprint
7.1.2.2. Geralmente se opta em ter times que possam atuar em todas as camadas técnicas em vez de ter um time para cada camada (Banco de Dados, Infra, Código,Front-end, etc).
7.1.3. São autogerenciáveis
7.1.3.1. Os membros decidem internamente quem faz o quê, quando e como
7.1.4. Tamanho: 10 ou menos pessoas
7.1.5. Trabalham em ritmo sustentável
7.1.5.1. Horas extras não é uma boa prática
7.1.6. O time inteiro é responsável por criar um Incremento valioso e útil a cada Sprint
7.1.7. 3 únicos papéis no Scrum
7.1.7.1. Developers
7.1.7.1.1. Pessoas comprometidas em criar qualquer aspecto de um Incremento utilizável a cada Sprint.
7.1.7.1.2. Todos os membros são DESENVOLVEDORES
7.1.7.1.3. Somente eles determinam com o trabalho deve ser executado
7.1.7.1.4. Alterar o quadro de desenvolvedores pode diminuir a produtividade
7.1.7.1.5. Principais responsabilidades
7.1.7.2. Product Owner
7.1.7.2.1. Representa clientes, usuários e stakeholders
7.1.7.2.2. É o único dono do backlog do produto
7.1.7.2.3. É esperado que seja quem dê a última palavra em relação ao produto
7.1.7.2.4. Deve existir um para cada produto
7.1.7.2.5. Principais responsabilidades
7.1.7.2.6. Aspectos importantes do seu papel
7.1.7.2.7. Assume somente algumas responsabilidades do Gerente de Projetos tradicional, como a parte de lidar com partes interessadas e orçamentação
7.1.7.3. Scrum master
7.1.7.3.1. Estabelece o Scrum conforme definido no Scrum Guide
7.1.7.3.2. Responsável pela eficácia do Scrum Team
7.1.7.3.3. São verdadeiros líderes que servem ao Scrum Team
7.1.7.3.4. Deve existir um para cada time Scrum
7.1.7.3.5. É uma posição de gestão
7.1.7.3.6. Principais responsabilidades
8. Eventos no Scrum
8.1. Importante saber
8.1.1. Todos os eventos no Scrum são time-boxed
8.1.2. Todos os eventos são uma oportunidade para inspecionar e adaptar os artefatos do Scrum
8.1.3. O ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade
8.2. Sprint
8.2.1. É o momento em que é feito o trabalho para transformar os itens do backlog do produto selecionados em incremento de produto funcionando
8.2.2. Duração máxima de um mês
8.2.2.1. A duração pode ser baseada em diversos fatores
8.2.2.1.1. Nível de incerteza da tecnologia a ser usada
8.2.2.1.2. Frequência de alterações no Time Scrum
8.2.2.1.3. Nível de risco aceitável
8.2.2.1.4. Alinhamento com eventos do negócio (releases, por exemplo)
8.2.2.1.5. Isso é definido pelo Time Scrum inteiro
8.2.3. Composição
8.2.3.1. A Sprint é um contêiner para todos os outros eventos
8.2.3.2. Dentro de uma sprint ocorrem a reunião de planejamento da sprint, as reuniões diárias, o trabalho de desenvolvimento, uma revisão da sprint e a retrospectiva da sprint
8.2.4. Toda Sprint deve gerar no final um incremento de produto utilizável de acordo com a Definição de Pronto
8.2.4.1. Não existe sprint 0 no Scrum Guide para planejamento de infraestrutura/arquitetura (isto deve ser feito ao longo das Sprints)
8.2.4.2. Não existe Sprint de Release
8.2.4.3. Não existe Sprint de Testes
8.2.4.4. Toda Sprint tem que procurar entregar alguma funcionalidade de produto
8.2.5. Inicia-se junto com a reunião de planejamento da sprint e termina junto com a reunião de retrospectiva
8.2.6. Termina quando sua time-box termina
8.2.6.1. Se sobrar tempo, novos itens do backlog do produto podem ser selecionados e desenvolvidos
8.2.6.2. Os itens que não forem completados podem voltar para o backlog do produto e serão repriorizados pelo dono do produto
8.2.6.3. Uma vez que termina uma sprint, uma nova sprint já é iniciada imediatamente
8.2.7. Mudanças devem ser evitadas quando a Sprint está em execução
8.2.8. Somente o Product Owner tem autoridade para cancelar uma Sprint antes do seu término
8.2.8.1. Isso pode acontecer se a Meta da Sprint se tornar obsoleta
8.2.8.2. Parte do trabalho terminado pode ser aceito pelo PO e liberado (se fizer sentido)
8.2.8.3. Todo o trabalho incompleto é reestimado e volta para o Backlog de Produto
8.2.9. Durante a sprint, novas tarefas podem ser identificadas pelos Desenvolvedores para os itens do backlog do produto já selecionados
8.2.9.1. Importante que PO esteja disponível para esclarecimentos, quando necessário
8.2.10. Itens do Backlog da Sprint podem ser removidos ou alterados se os Desenvolvedores perceberem que não darão conta de fazer tudo
8.2.10.1. Há necessidade de acordar com o Product Owner o que vai ser removido
8.2.11. Durante a Sprint, podem ser implementadas melhorias no processo sempre que for necessário
8.3. Planejamento da Sprint
8.3.1. Primeiro evento que ocorre na sprint
8.3.2. Serve para definir O QUE precisa ser feito e COMO deve ser feito
8.3.3. Todos do Time Scrum participam
8.3.4. Time-box de 8 horas para uma sprint de um mês
8.3.4.1. Proporcionalmente menor para sprints menores
8.3.4.2. 2 horas para cada semana de duração da sprint
8.3.5. A Meta do Produto é uma entrada
8.3.6. Trata de 3 tópicos
8.3.6.1. Tópico 1
8.3.6.1.1. Por que esta Sprint é valiosa?
8.3.6.1.2. Define a Meta da Sprint
8.3.6.2. Tópico 2
8.3.6.2.1. O que pode ser feito nesta Sprint?
8.3.6.2.2. Por meio de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir na Sprint atual. O
8.3.6.2.3. Participação do Product Owner é fundamental para definir O QUE fazer
8.3.6.2.4. Somente os Desenvolvedores podem dizer quantos itens são capazes de entregar no final da sprint
8.3.6.3. Tópico 3
8.3.6.3.1. Como o trabalho escolhido será realizado?
8.3.6.3.2. Os Desenvolvedores identificam as tarefas necessárias para os itens do backlog selecionados para a sprint (de acordo com a Definição de Pronto)
8.3.6.3.3. Cabe somente aos Desenvolvedores decompor os itens do Backlog do Produto em trabalhos menores
8.3.6.3.4. É criado o backlog da sprint (uma saída principal da reunião de planejamento)
8.4. Reunião diária
8.4.1. Seu propósito é inspecionar o progresso em direção a Meta da Sprint e adaptar o Backlog da Sprint conforme necessário, ajustando o próximo trabalho planejado.
8.4.2. É uma reunião dedicada aos Desenvolvedores
8.4.2.1. A participação de todos os desenvolvedores é obrigatória
8.4.2.2. Desenvolvedores atualizam status das suas atividades antes da reunião
8.4.3. A presença do Scrum master e Product Onwer não é obrigatória
8.4.3.1. Eles não participam (se não forem desenvolvedores), mas podem ser ouvintes
8.4.3.2. O Scrum master apenas deve garantir/facilitar a sua realização
8.4.3.3. A condução da reunião é feita pelos Desenvolvedores
8.4.4. Sempre uma time-box de 15 minutos
8.4.4.1. Independente da duração da sprint
8.4.5. Ocorre todos os dias, exceto quando há reuniões de planejamento, revisão e retrospectiva da sprint
8.4.6. É mantida no mesmo horário e local todos os dias para reduzir a complexidade
8.5. Revisão da Sprint
8.5.1. Seu propósito é inspecionar o resultado da Sprint e determinar as adaptações futuras.
8.5.2. Ocorre ao final de cada Sprint
8.5.3. Maior foco no produto e não no processo
8.5.3.1. O Scrum Team apresenta os resultados de seu trabalho para os principais stakeholders e o progresso em direção a Meta do Produto é discutido.
8.5.4. Todos do Time Scrum participam
8.5.5. O Product Owner pode convidar stakeholders-chave para ajudar na validação do incremento
8.5.5.1. Considerar que Stakeholders podem ser envolvidos em outros momentos da Sprint, se o Time precisar
8.5.6. Time-box de 4 horas para sprint de um mês
8.5.6.1. Proporcionalmente menor para Sprints menores
8.5.6.2. É uma hora para cada semana de duração da Sprint
8.5.7. Como resultado, o Product Backlog pode ser ajustado para atender a novas oportunidades
8.6. Retrospectiva da Sprint
8.6.1. Serve para planejar maneiras de aumentar a qualidade e a eficácia.
8.6.2. Ocorre logo após a Revisão de cada Sprint
8.6.3. Time-box de 3 horas para uma Sprint de um mês
8.6.3.1. Proporcionalmente menor para sprints menores
8.6.4. Todos do Time Scrum participam
8.6.4.1. O Scrum master também é um membro desta reunião devido a ele ser responsável pelo processo Scrum, o qual também é objeto de melhoria
8.6.5. Maior foco na melhoria do processo e não no produto
8.6.5.1. O Scrum Team inspeciona como foi a última Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definição de Pronto.
8.6.5.2. O Scrum Team discute o que deu certo durante a Sprint, quais problemas encontraram e como esses problemas foram (ou não) resolvido
8.6.6. Cada membro do Time Scrum deve falar abertamente sobre o que considera que foi bem e o que deve ser melhorado
8.6.7. O Time Scrum identifica as mudanças mais úteis para melhorar sua eficácia
8.6.7.1. As melhorias mais impactantes são endereçadas o mais rápido possível
8.6.7.2. Essas podem ser adicionadas ao Sprint Backlog da próxima Sprint.
9. Artefatos no Scrum
9.1. Importante saber
9.1.1. Os artefatos no Scrum são projetados para maximizar a transparência das principais informações
9.1.2. Cada artefato contém um compromisso para garantir que ele forneça informações que aumentem a transparência e o foco contra o qual o progresso pode ser medido
9.1.2.1. Para o Product Backlog, é a Meta do produto.
9.1.2.2. Para o Sprint Backlog, é a Meta da Sprint.
9.1.2.3. Para o incremento, é a Definição de Pronto
9.2. Backlog do produto
9.2.1. Lista ordenada de tudo aquilo que pode ser necessário no produto
9.2.1.1. Se espera que aquilo que tenha maior valor tenha uma prioridade maior.
9.2.2. Itens do Backlog do Produto podem ser
9.2.2.1. Solicitações de funcionalidades
9.2.2.2. Requisitos não funcionais
9.2.2.3. Histórias de usuário
9.2.2.4. Casos de uso
9.2.2.5. Bugs/defeitos a resolver
9.2.2.6. Novas funcionalidades técnicas (apis)
9.2.3. O Product Owner é o "dono" do Backlog do Produto
9.2.3.1. Isso significa que cabe a ele decidir o que entra ou sai desse Backlog
9.2.4. O progresso é medido pela Meta do produto
9.2.4.1. Essa meta é objetivo de longo prazo para o Scrum Team
9.2.4.2. Dá uma direção geral para todas as Sprints.
9.2.4.3. Facilita a inspeção do progresso incremental do produto.
9.2.4.4. Isso ajuda a equipe a manter o foco e a tomar melhores decisões.
9.2.5. O Backlog do Produto não estará completo na primeira Sprint e estará em constante evolução
9.2.5.1. Deve refletir as mudanças no negócio
9.2.5.2. O projeto não começa com um Backclog de Produto exaustivo, isso evolui com o andar do projeto
9.2.6. Disponível para todos visualizarem (transparência)
9.2.7. Recomenda-se apenas um Backlog do Produto, mesmo que haja vários Times trabalhando no mesmo produto
9.2.8. As estimativas dos itens devem ser feitas por quem vai realizar o trabalho (no caso, os Desenvolvedores)
9.2.9. Ordenação pode ser feita combinando fatores como
9.2.9.1. Valor para o negócio
9.2.9.1.1. Fator primário
9.2.9.2. Vínculo com a estratégia de negócio
9.2.9.3. Risco
9.2.9.4. Custo/esforço
9.2.9.5. Dependências entre os itens
9.2.10. Refinamento do Backlog do Produto
9.2.10.1. Esta é uma atividade contínua
9.2.10.1.1. Acontece durante as Sprints
9.2.10.2. Realizado pelo Product Owner com apoio dos Desenvolvedores
9.2.10.3. Ideal que os itens esteja preparados (ready) para seleção na próxima Reunião de Planejamento da Sprint
9.2.10.4. Cabe aos desenvolvedores o dimensionamento dos itens do Backlog do Produto
9.2.10.5. Os itens com prioridade maior terão maior detalhamento para estarem preparados para entrar na próxima sprint
9.2.10.5.1. Evitar preparação muito antecipada
9.3. Backlog da Sprint
9.3.1. Saída principal gerada na reunião planejamento da Sprint
9.3.2. Inclui Meta da sprint + itens selecionados do Backlog do Produto + Tarefas necessárias
9.3.2.1. Pode conter
9.3.2.1.1. Tarefas
9.3.2.1.2. Testes a executar
9.3.2.1.3. Casos de uso
9.3.2.1.4. História de usuário
9.3.3. Todo os itens derivam de alguma forma do Backlog do Produto
9.3.4. Novas tarefas podem ser adicionadas durante a Sprint
9.3.4.1. Lembre que o detalhamento das tarefas pode continuar durante a sprint
9.3.5. Somente os desenvolvedores podem alterar esse backlog durante a sprint
9.3.5.1. Se o trabalho for diferente do esperado, eles colaboram com o Product Owner para negociar o escopo do Sprint Backlog dentro do Sprint sem afetar a Meta da Sprint.
9.3.6. Vísivel para todos
9.3.6.1. Pode ser apresentado em um quadro para ser visível para todos
9.3.7. Todas os itens são de responsabilidade de todos desenvolvedores, ninguém é dono individual
9.3.7.1. Um membro pode voluntariamente assumir uma tarefa para fazer, mas todos são donos de todas as tarefas
9.3.8. Meta da Sprint
9.3.8.1. É o único objetivo do Sprint.
9.3.8.2. Criada durante o evento Sprint Planning e, em seguida, adicionado ao Sprint Backlog.
9.3.8.2.1. O PO vai para reunião de planejamento da Sprint com uma ideia de meta e depois acorda com o Time Scrum
9.3.8.3. Embora o Sprint Goal seja um compromisso dos Desenvolvedores, ele oferece flexibilidade em termos do trabalho exato necessário para alcançá-lo.
9.3.8.4. À medida que os Desenvolvedores trabalham durante o Sprint, eles mantêm o Objetivo do Sprint em mente.
9.4. Incremento
9.4.1. É a soma de todos os itens do backlog do produto completados durante a sprint e o valor dos incrementos de todas as sprints anteriores
9.4.2. Ao final de cada Sprint um incremento deve estar “Pronto”
9.4.3. Deve estar na condição liberarável e atender à definição de “Pronto” do time Scrum
9.4.4. Quando julgar que faz sentido, o Dono do Produto decidirá a sua liberação no ambiente de produção