Framework ágil para gestão de projetos, criado no início de 1990, seguindo regras do Manifesto Ágil, a fim de gerar valor por meio de soluções adaptativas. Possui os elementos: papéis, eventos e artefatos (papéis executam eventos e produzem artefatos). Baseado no empirismo, afirma que o conhecimento vem da experiência e tomada de decisões através de observação, e no lean thinking, concentrando-se apenas no essencial, reduzindo desperdício. Possui abordagem iterativa e incremental. Envolve coletivo, onde todos possuem conhecimentos de trabalho para compartilhar, conforme necessário. Combina quatro eventos formais para inspeção e adaptação, contidos no evento Sprint. Os 12 princípios ágeis são valor, flexibilidade, frequência, união, motivação, comunicação, funcionalidade, sustentabilidade, revisão, simplicidade, organização e autoavaliação.

• Site Manifesto Ágil
• Site Oficial Scrum
• Guia Oficial Scrum
• Glossário ágil 1
• Glossário ágil 2
• Certificação Scrum grátis (SFPC)
• Certificação Scrum grátis (SFC)

Pilares (TIA)

1. Transparência: Visibilidade das rotinas tanto para quem as executa, quanto para quem as recebe, através dos 3 artefatos;
2. Inspeção: Artefatos e progresso às metas (goal) devem ser inspecionados com frequência e diligência, para detectar variações e problemas indesejáveis. Para isso, Scrum possui cadência através dos 5 eventos;
3. Adaptação: Adaptação dos processos e materiais, caso os mesmos estejam fora dos aceites, o mais rápido possível, para minimizar novos desvios. Scrum Team com profissionais empoderados e auto-gerenciados devem adaptar-se no momento de aprendizado por meio da inspeção.

Valores

Orientam Scrum Team em trabalho, ações e comportamento, onde tais valores são aprimorados no cotidiano dos eventos e artefatos produzidos.

1. Compromisso: Scrum Team compromete-se a atingir objetivos e convivência;
2. Foco: Tarefas da Sprint, objetivando melhor progresso possível em direção às metas (Sprint goal);
3. Abertura: Transparência de informações entre Scrum Team e seus stakeholders;
4. Respeito: Ambiente de trabalho respeitado entre Scrum Team;
5. Coragem: Scrum Team com coragem para resolver problemas difíceis.

Scrum Team (papéis)

Composto de 3 a 9 Developers, além de Product Owner (PO) e Scrum Master. Não possui sub-times ou hierarquias. Focado em um objetivo de cada vez, a Meta do Produto (Product goal). Profissionais multifuncionais e autogerenciáveis (decidem internamente cada tarefa e função). Scrum Teams com integrantes além da quantidade suportada, devem ser reorganizados em vários Scrum Teams coesos, focados no mesmo Product goal, Product Backlog e PO. Scrum Team é responsável por todas atividades relacionadas ao produto, desde colaboração com stakeholder, pesquisas, manutenções, qualquer coisa que seja necessária. Todo Scrum Team é responsável por criar um Incremento valioso a cada Sprint.

• Developers: Profissionais comprometidos a criar Incremento valioso a cada Sprint, responsáveis por:
  • Criar plano para Sprint, o Sprint Backlog;
  • Introduzir gradualmente qualidade aderindo a uma Definição de Pronto;
  • Adaptar seu plano a cada dia em direção à meta da Sprint;
  • Responsabilizar-se mutuamente como profissionais.
• Product Owner (PO): Profissional responsável por maximizar o valor do produto, advindo do gerenciamento eficaz do Product Backlog realizado pelo mesmo, resultante do trabalho do Scrum Team. PO realiza comunicação direta com o cliente. Tem poder de delegar responsabilidade a outros (independentemente disso, PO ainda é o responsável). As decisões do PO são visíveis no conteúdo e ordem do Product Backlog, através do incremento inspecionável na Sprint Review. Alterações no Product Backlog precisam ser direcionadas ao, e realizadas, pelo PO. Responsável por:
  • Desenvolver e comunicar explicitamente a meta do produto;
  • Criar, ordenar e comunicar claramente os itens do Product Backlog;
  • Garantir que o Product Backlog seja transparente, visível e compreensível, representando as necessidades dos stakeholders.
• Scrum Master: Profissional líder responsável por estabelecer e produzir Scrum (conforme Scrum Guide) ao Team e organização, sendo responsável pela eficácia do Scrum Team em tal. Responsável por:
  • Treinar membros do time em autogerenciamento e cross-funcionalidade;
  • Ajudar Scrum Team a se concentrar na criação de incrementos de alto valor que atendem à Definição de Pronto, provocando remoção de impedimentos ao progresso do Scrum Team;
  • Garantir que todos eventos Scrum ocorram e sejam produtivos/mantidos dentro do Timebox.
  O Scrum Master serve o PO de várias maneiras, incluindo:
  • Ajudar encontrar técnicas para definição eficaz de meta do Produto e gerenciamento do Product Backlog;
  • Ajudar Scrum Team entender a necessidade de itens do Product Backlog claros e concisos;
  • Ajudar estabelecer planejamento empírico do produto para um ambiente complexo;
  • Facilitar colaboração dos stakeholders.
  O Scrum Master serve a organização de várias maneiras, incluindo:
  • Liderar, treinar e orientar a organização na adoção do Scrum;
  • Planejar e aconselhar implementações de Scrum na organização;
  • Ajudar funcionários e stakeholders compreender e aplicar abordagem empírica para trabalhos complexos;
  • Remover barreiras entre stakeholders e Scrum Teams.

Eventos (Events)

A Sprint é um contêiner para todos demais eventos. Cada evento é uma oportunidade formal para inspecionar e adaptar artefatos. Os eventos são usados no Scrum para criar regularidade e minimizar a necessidade de reuniões não definidas no Scrum. O ideal é que todos eventos sejam realizados no mesmo horário e local, para reduzir a complexidade.

1. Sprint: Eventos de duração fixa de 1 mês ou menos, onde ideias são transformadas em valor. Uma nova Sprint começa imediatamente após a conclusão da anterior (loop). Todo o trabalho necessário para atingir a meta do Produto, incluindo Sprint Planning, Daily Scrums, Sprint Review e Sprint Retrospective, acontece dentro de Sprints. Durante a Sprint:
   • Nenhuma mudança é feita que coloque em risco a meta da Sprint;
   • A qualidade não diminui;
   • O Product Backlog é refinado conforme necessário;
   • O escopo pode ser esclarecido e renegociado com o PO, conforme andamento do mesmo.
   Permitem previsibilidade, garantindo inspeção e adaptação do progresso em direção a Meta do Produto ao menos uma vez por mês. Quando a meta da Sprint é muito longa, a mesma pode tornar-se inválida. Sprints mais curtas podem ser empregados para gerar mais ciclos de aprendizagem e limitar riscos de custo e esforço a um período de tempo menor. Cada Sprint pode ser considerado um projeto curto. Há várias práticas para prever progresso, como burn-downs, burn-ups ou cumulative flows. Uma Sprint pode ser cancelada se a Meta da Sprint (Sprint goal) tornar-se obsoleta (apenas PO tem autoridade para tal);
2. Sprint Planning: Antecede o início da Sprint, ao definir o trabalho a ser realizado na mesma (Sprint Backlog). Este plano resultante é criado pelo trabalho colaborativo de todo Scrum Team. PO garante que participantes estejam preparados para discutir os itens mais importantes do Product Backlog e como eles são mapeados para a Meta do Produto. O Scrum Team também pode convidar outras pessoas para participar da Sprint Planning para fornecer conselhos. Tópicos abordados na Sprint Planning:
   • Por que essa Sprint é valiosa? PO propõe como o produto pode aumentar seu valor na Sprint atual. Todo Scrum Team então colabora para definir uma Meta da Sprint, que comunica porque a Sprint é valiosa para os stakeholders. A meta da Sprint deve ser finalizada antes do final da Sprint Planning;
   • O que pode ser feito nessa Sprint? Via discussão com PO, os Developers selecionam itens do Product Backlog para incluir na Sprint atual. O Scrum Team pode refinar esses itens durante este processo;
   • Como o trabalho escolhido será realizado? Para cada item do Product Backlog selecionado, os Developers planejam, somente entre si, o trabalho necessário para criar um Incremento que atenda à Definição de Pronto. Isso geralmente é feito decompondo itens do Product Backlog em itens menores, de 1 dia ou menos.
   A Meta da Sprint, os itens do Product Backlog selecionados para a Sprint, mais o plano para entregá-los, são chamados juntos de Sprint Backlog e são criados na Sprint Planning. Sprint Planning tem Timebox de no máximo 8 horas para uma Sprint de 1 mês. Em Sprints mais curtas, o evento geralmente é mais curto (geralmente 2 horas de Sprint Planning para cada semana de Sprint).
3. Daily Scrum: Reunião diária de 15 minutos (realizado no mesmo horário e local, todos dias úteis da Sprint) entre os Developers, com propósito de inspecionar o progresso em direção a Meta da Sprint e adaptar o Sprint Backlog conforme necessário, criando plano de ação para o próximo trabalho planejado. Se o PO ou Scrum Master estão trabalhando ativamente nos itens do Sprint Backlog, eles participam como Developers. Daily Scrum não é o único momento em que os Developers podem ajustar seu plano. Eles costumam reunir-se ao longo do dia para discussões mais detalhadas sobre adaptação ou replanejamento do resto do trabalho da Sprint. Daily Scrums melhoram comunicações, identificam impedimentos, promovem rápida tomada de decisões e consequentemente, eliminando necessidade de outras reuniões.
4. Sprint Review: Sessão de trabalho para apresentação do Scrum Team, com propósito de inspecionar o resultado da Sprint e determinar adaptações futuras. O Scrum Team apresenta os resultados de seu trabalho para os principais stakeholders e o progresso em direção a Meta do Produto é discutido. Durante o evento, Scrum Team e stakeholders revisam o que foi realizado na Sprint e o que mudou em seu ambiente. O Product Backlog também pode ser ajustado para atender novas oportunidades. É o penúltimo evento da Sprint, com Timebox de no máximo 4 horas para Sprint de 1 mês. Para Sprints mais curtas, o evento geralmente é mais curto.
5. Sprint Retrospective: Reunião que conclui a Sprint. Nela, Scrum Team inspeciona como foi a última Sprint em relação a indivíduos, interações, processos, ferramentas e Definição de Pronto. As suposições que os desviaram são identificadas e suas origens exploradas. Scrum Team discute o que deu certo durante a Sprint, quais problemas encontraram e como esses problemas foram (ou não) resolvidos. Scrum Team identifica mudanças mais úteis para melhorar sua eficácia e qualidade. As melhorias mais impactantes são endereçadas o mais rápido possível. Essas podem até ser adicionadas ao Sprint Backlog para próxima Sprint. Timebox de no máximo 3 horas para uma Sprint de 1 mês. Para Sprints mais curtas, o evento geralmente é mais curto.

Artefatos (Artifacts)

Representam trabalho ou valor. Projetados para maximizar transparência, para que todos que os inspecionam tenham mesma base para adaptação. Cada artefato contém um compromisso para garantir que ele forneça informações que aumentem transparência e foco contra qual o progresso pode ser medido:

• Para o Product Backlog, é a Meta do Produto (Product goal);
• Para o Sprint Backlog, é a Meta da Sprint (Sprint goal);
• Para o incremento, é a Definição de Pronto (Done).

Tais compromissos reforçam empirismo e valores para o Scrum Team e stakeholders.

1. Product Backlog: Lista ordenada e emergente do que é necessário para melhorar o produto. Única fonte de trabalho realizada pelo Scrum Team. Os itens do Product Backlog aptos a ser realizados pelo Scrum Team na Sprint são considerados preparados para seleção no evento Sprint Planning. Eles geralmente adquirem esse grau de transparência após atividades de refinamento. O Product Backlog refinement é o ato de quebrar e incluir definição adicional aos itens do Product Backlog para ter itens menores e mais precisos. Esta é uma atividade contínua para adicionar detalhes e ordem. Os Developers que farão o trabalho são responsáveis pelo dimensionamento. O PO pode influenciar os Developers, ajudando-os a entender e selecionar trade-offs (trocas de itens).
   Compromisso: Meta do Produto descreve estado futuro do produto, foco para Scrum Team planejar. A Meta do produto está no Product Backlog. O restante do Product Backlog define "o que" cumprirá tal Meta do Produto. Um produto é um veículo para entregar valor. Tem limite claro, stakeholders conhecidos, usuários/clientes bem definidos. Um produto pode ser um serviço, um produto físico ou algo abstrato. A Meta do Produto é o objetivo de longo prazo para Scrum Team. Eles devem cumprir (ou abandonar) um objetivo antes de assumir o próximo;
2. Sprint Backlog: Plano feito por, e para, Developers, composto pela Meta da Sprint (por que), conjunto de itens do Product Backlog selecionados para Sprint (o que), além de plano de ação para entregar o Incremento (como). É uma imagem visível, em tempo real, do trabalho que os Developers planejam realizar durante a Sprint para atingir a Meta da Sprint. Consequentemente, o Sprint Backlog é atualizado ao longo da Sprint conforme necessário. Deve ter detalhes suficientes para que eles possam inspecionar seu progresso na Daily Scrum.
   Compromisso: Meta da Sprint é o único objetivo da Sprint. Embora essa seja um compromisso dos Developers, a mesma fornece flexibilidade em termos do trabalho exato necessário para alcançá-la. A Meta da Sprint é criada durante Sprint Planning e então adicionada ao Sprint Backlog. Conforme Developers trabalham durante a Sprint, eles mantêm a Meta da Sprint em mente. Se o resultado for diferente do esperado, eles colaboram com o PO para negociar o escopo do Sprint Backlog dentro da Sprint, sem afetar a Meta da Sprint;
3. Incremento: Resultado concreto em direção a Meta do produto, fornecendo valor. Cada incremento é adicionado a todos demais anteriores e completamente verificado, garantindo que todos funcionem juntos. Vários incrementos podem ser criados em uma Sprint. A soma dos incrementos é apresentada na Sprint Review. Contudo, um incremento pode ser entregue aos stakeholders antes do final da Sprint. A Sprint Review nunca deve ser considerada um marco para liberar valor. O trabalho não pode ser considerado parte de um incremento, a menos que atenda a Definição de Pronto.
   Compromisso: Definição de Pronto é descrição formal do estado do Incremento quando ela atende às medidas de qualidade exigidas ao produto. No momento em que um item do Product Backlog atende a Definição de Pronto, um incremento nasce. Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou apresentado na Sprint Review. Em vez disso, ele retorna ao Product Backlog para consideração futura. Se a Definição de Pronto para um incremento faz parte dos padrões da organização, todos os Scrum Teams devem segui-la como mínimo. Se não for um padrão organizacional, o Scrum Team deve criar uma Definição de Pronto apropriada para o produto. Os Developers devem estar em conformidade com a Definição de Pronto. Se houver vários Scrum Teams trabalhando juntos em um produto, eles devem definir e cumprir mutuamente a mesma Definição de Pronto.

Scrum em projetos de larga escala

Em grandes projetos, usa-se técnica "Scrum de Scrum", onde elege-se 1 Scrum Master chefe, geralmente externo, entre os vários Scrum Teams, para que o mesmo possa centralizar, na Daily Scrum, comunicação entre Scrum Masters que representarão, respectivamente, seus Scrum Teams. Esses Scrum Masters, orientados pelo Scrum Master chefe, possuirão intensa comunicação com o PO que, por sua vez, se comunicará com os clientes, otimizando Product Backlog.

Experiência prática com Scrum

1. Visão, organização e Product Backlog

Semana 1 (visão geral e organização):
Nesta etapa o Scrum Team, em especial o PO, juntamente com o cliente, deverá concatenar todas as ideias com relação ao produto que será desenvolvido, que apresentará o Estudo de Caso de sua necessidade, sendo este de forma macro. É nesta etapa que todo o planejamento macro do futuro trabalho será criado, assim como a organização do Scrum Team como um todo. Portanto, o Estudo de Caso precisa ser minucioso e objetivo, a fim de elaborar o MVP do projeto que será trabalhado. Nesta etapa o PO, juntamente com ideias internas dos membros da equipe e stakeholders (Convenciona-se chamar de 'stakeholders' os representantes do cliente que se envolvem direta ou indiretamente com a equipe), desenvolverá a visão geral do produto, representado em artefatos como o quadro 'É / Não É / Faz / Não Faz', além do documento 'Declaração de Visão do Projeto' (onde será descrito objetivo do projeto, descrição, mapeamento, stakeholders, etc), assim como seus objetivos, representado em artefatos como o quadro 'Elevator Pitch'. De forma macro, serão organizados os objetivos gerais do produto em questão. Além disso, serão levantadas possíveis dados e ideias para uma elaboração mais detalhada da visão do produto, que será aprimorada em breve a este evento.

Semana 2 (visão consolidada e estruturada):
Neste próximo evento será elaborada a visão consolidada do produto e outros aspectos mais detalhados, relacionados ao mesmo. O PO elaborará a visão consolidada do produto, sendo esta representada por artefatos com o quadro 'Canvas do Produto', especificando todas as características que o mesmo possuirá e seus arredores, relacionando a visão do negócio com a visão do produto. A visão consolidada do produto deverá ser resultante da organização e elaboração, de forma detalhada e precisa, dos Épicos (Epics) desenvolvidos, Funcionalidades e User Stories / Use Cases. Após isso, PO elaborará a estrutura analítica do produto (EAS), detalhando, de forma mais organizada, as características desenvolvidas no quadro Canvas do Produto, sendo esta etapa representada por artefatos como diagramas de árvore, informando entradas, processamentos, saídas e outras demais características concatenadas na ideia Canvas do Produto. Após construídos tais artefatos, é desenvolvido o Product Backlog, pelo PO em conjunto com demais componentes da equipe, elencando, em listagem detalhada e caraterizada, das funções que o produto possuirá. Neste mesmo artefato, geralmente desenvolvido em planilha, será elencada a prioridade das tarefas, utilizando métricas como Priorização Valor Moscow. É fundamental compartilhar tais priorizações das funções com o cliente, pois o mesmo elencará, de acordo com sua necessidade, o que é, de fato, mais importante, para que o foco das Sprints futuras possa ser organizado, de forma macro. Após construído o Product Backlog, o PO, também em conjunto com a equipe em geral, deverá construir o Roadmap, um cronograma, elencando, de forma macro, as funções, e seus atores, dentre outras características, a serem desenvolvidas em cada Sprint futura, de acordo com suas priorizações definidas, assim como o objetivo de cada Sprint, de forma detalhada, em cronograma das semanas, para o desenvolvimento do projeto até sua possível entrega final. Tanto o Product Backlog, quanto o Roadmap, são artefatos mutáveis, que serão atualizados conforme necessidades do andamento do desenvolvimento do projeto.

2. Sprint (loop, de acordo com quantidades de Sprints do projeto)

Semana 1 (início da Sprint):
Nesta etapa a equipe se reúne, na Sprint Planning, com o PO para que o mesmo possa desenvolver o Sprint Backlog, artefato, geralmente em planilha, que pode ser modificado com o tempo, de acordo com necessidades (Implementações, atrasos, bugs...), onde é definida a meta da Sprint, com a listagem das funções prioritárias para o desenvolvimento ao longo da Sprint, que possui duração de aproximadamente 2 a 4 semanas. Desta mesma forma, a equipe de desenvolvimento precisará elencar, após definido com toda a equipe do projeto, documento com as especificações técnicas do projeto, elencando suas características técnicas, assim como tecnologias e ferramentas utilizadas ao longo do processo. Com tais artefatos prontos, o PO realizará a criação e ampliação das User Stories das funções do Sprint Backlog, para então desenvolver o quadro 7 Dimensões do Produto para cada funcionalidade definida do Sprint Backlog, especificando as características de cada, de forma mais organizada. Com isso, poderão ser definidos, também pelo PO, os critérios, de forma macro, de Ready e Done. Ambos os critérios de Ready e Done classificam itens do backlog da sprint (podem ser tratados como checklists), porém, um item Ready significa que ele está "pronto" para iniciar o desenvolvimento dentro da sprint (por exemplo, está com a user story escrita, os critérios de aceite foram elaborados, o refinamento do item tem a aprovação do PO, etc.), enquanto um item Done significa que ele está concluído de fato nos aspectos que tangem a implementação (por exemplo, codificação, execução dos testes, etc.) e já pode ser apresentado ao cliente. Neste passo o Scrum Master definirá os Critérios de Aceite, de forma detalhada, de cada funcionalidade do Sprint Backlog, baseando-se também no quadro 7 Dimensões do Produto, elencando todas as possibilidades de cenários de sucesso/erro no sistema, detalhando também como o sistema deverá se comportar perante tais cenários. Os Critérios de Aceite também podem ser escritos em formato de requisitos, assim como também com detalhes adicionais, seguindo um padrão geral. De forma geral, Critérios de Aceite são critérios de validação das funcionalidades, de acordo com a necessidade imposta pelo cliente, durante suas reuniões e Estudo de Caso, que também pode ser modificado com o andamento do projeto, de acordo com as necessidades envolvidas. Com os critérios de Aceite finalizados, documento que também será modificável de acordo com o andamento da Sprint, incluído e modificando funcionalidades no mesmo, o Scrum Master prepara o quadro Kanban para a Sprint, definindo cada atividade, juntamente com seus respectivos User Stories e Cenários de Aceites, para que a Equipe Dev possa desenvolvê-las. O Scrum Master incluirá cada atividade a 1 membro específico da Equipe Dev, assim como detalhes e prazos, de forma bem detalhada. O quadro Kanban é representado por post its (cards), em que cada card representa uma atividade, onde a categorização dos mesmos geralmente é definida, de forma macro, entre itens de backlog (Ideias dos componentes do time para possível implementação no projeto), cards do backlog da Sprint (Stories), cards do andamento da Sprint, sendo este subdividido na categorias Fazer (To Do), Fazendo (Doing), Feito (Ready), Testado (Test), especificando neste, de forma detalhada, os testes realizados, e Pronto / Entregue (Done / Deployment), sendo este testado e aprovado conforme Critérios de Aceite. Cada Sprint possuirá seus respectivos cards do andamento da Sprint. Caberá à Equipe Dev realizar a movimentação dos cards, de acordo com o andamento do projeto. Ao longo da Sprints, também de forma macro ao projeto, será interessante a utilização de gráficos públicos para acompanhamento do andamento das etapas, como gráficos BurnUp e BurnDown.

Semanas 2 e 3 (andamento da Sprint):
Neste período o projeto estará em andamento, onde no final de cada dia a equipe se reúne para tratar o Daily Scrum (Daily Standup), uma reunião diária, com aproximadamente 8 minutos (Dependerá do tamanho da equipe, de 2 à 15 minutos), para discutir o andamento de toda equipe ao longo do dia, especificar conclusões do dia, ideias, dificuldades, prazos, entre outros pontos. É neste momento que os gráficos públicos são atualizados e acompanhados, assim como a apresentação das modificações dos documentos vinculados, como Sprint Backlog, Roadmap, 7 Dimensões, Aceites e Kanban, se as mesmas houveram. É importante, pelo menos uma vez por semana, a equipe reunir-se com o cliente, para apresentar possíveis evoluções e acompanhamento do andamento do projeto. Entretanto, cabe ao PO manter constante comunicação com o cliente, para possíveis eventuais mudanças de escopo no Estudo de Caso e implementações, conforme necessidades dos stakeholders.

Semana 4 (fechamento da Sprint):
A última semana é marcada pelos mesmos fatos das semanas de andamento do projeto, com exceção do momento da entrega das funcionalidades do novo incremento do sistema proposto pelo Sprint Backlog ao cliente. É neste dia que uma apresentação, bem elaborada e prática, deverá ser realizada ao cliente (Sprint Review), explicando-o cada funcionalidade Done entregue ao mesmo, de acordo com Cenários de Aceites. Nem sempre todas as funcionalidades conseguirão ser entregues, entretanto podem haver momentos onde que serão entregues mais funcionalidades do que as básicas previstas no início da Sprint. Todas as 'modificações de percurso' deverão ser documentadas nos artefatos vinculados e apresentadas ao cliente, para ciência e aprovação do mesmo. Após a finalização das funcionalidades de backlog trabalhadas, finaliza-se então a Sprint, e a equipe, juntamente com o cliente, se reúne para a Sprint Review, onde serão apresentadas todas as ideias e funcionalidades entregues ao longo da Sprint, assim como seu andamento e pontos que podem ser aprimorados e modificados para a próxima Sprint, considerando as funcionalidades de Backlog. A Sprint Review durará o tempo que for necessário para elaboração das conclusões a apontamentos vinculados. Por fim, na Sprint Retrospective o time se reúne, internamente, por no máximo 3 horas, para alinhar seu comportamento do Scrum para a próxima Sprint, buscando melhorias e alinhamentos com a metodologia e rotinas, assim como finalização dos artefatos e documentos envolvidos, a fim de apresentar, de forma geral, o andamento do projeto, equipe e relação dos mesmos no envolvimento com o Scrum, e buscar qualidade e eficácia no projeto e processos. Ao final de cada Sprint Retrospective, o PO anexa suas documentações desenvolvidas, assim como artefatos utilizados e documentações de testes desenvolvidos até então, e o Scrum Master desenvolve o Relatório da Reunião da Sprint Retrospective, informando, detalhadamente, o andamento da Sprint, assim como dos stakeholders, levando em conta o Scrum e seus bastidores nas rotinas de trabalhos de cada envolvido. É no final de cada Sprint que os componentes da equipe do projeto serão avaliados separadamente. Vale lembrar que o Scrum repudia a programação Go Horse, onde programa-se deliberadamente, sem a necessidade de documentação, ou com documentação precoce, ou seja, após a feature desenvolvida. 1º documenta-se, de forma ágil, para após desenvolver, de acordo com todos os cenários descritos na documentação e suas respectivas regras de negócio.

3. Final do projeto, fechamento

Caso o projeto apresente um final de fechamento, com relação ao desenvolvimento, o que é raro, pois as manutenções fazem parte do Scrum, assim como a necessidade de melhora no projeto a cada novo dia, é realizado o Project Retrospective, uma reunião envolvendo toda a equipe que desenvolvera o produto, para apontamentos de ideias, sugestões de melhorias no processo Scrum, técnicas e práticas de convívio da equipe. Além disso, faz-se também a avaliação da equipe, de forma macro e de cada membro, além do projeto e suas etapas, de forma 'fechamento'. Além disso, os artefatos, como documentações e gráficos públicos dão-se por finalizados, onde resultarão, a partir destes, dados estatísticos do andamento do projeto como um todo e, com isso, possíveis ideias de melhorias para projetos futuros.

Manifesto Ágil

Implica em valorizar:
• Indivíduos e interações 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.

Glossário ágil

Em construção
• Acceptance Test Driven Development (ATDD): Desenvolvimento Orientado a Testes de Aceitação envolve stakeholders, colaborando para escrever testes de aceitação antes da implementação da funcionalidade correspondente;
• Acceptance Testing: Teste de aceitação é descrição formal do comportamento de produto de software, geralmente via exemplo ou cenário de uso, através de série de notações e abordagens diferentes propostas para tais;
• AntiPattern: Antipadrões são soluções comuns para problemas em que a solução é ineficaz e pode resultar em consequências indesejáveis;
• Automated Build: Build refere-se ao processo que converte arquivos e outros ativos sob responsabilidade dos desenvolvedores em produto de software em sua forma final/consumível. A construção é automatizada quando essas etapas são repetíveis, não requerem intervenção humana direta e podem ser executadas a qualquer momento, sem nenhuma informação, além daquela armazenada no repositório de controle do código-fonte;
• Backlog Refinement: Preparação do backlog ocorre quando o proprietário do produto e equipe refinam o backlog regularmente, para garantir que o backlog contenha os itens apropriados e priorizados, e que os itens no topo do backlog estão prontos para entrega;
• Behavior Driven Development (BDD): Prática onde os membros da equipe discutem comportamento esperado de um sistema, a fim de construir entendimento compartilhado da funcionalidade esperada;
• Burndown Chart: Gráficos de burndown e de burnup rastreiam quantidade de resultados (em horas, pontos da história ou itens do backlog) que uma equipe concluiu em uma iteração ou projeto;
• Business Agility: Agilidade nos negócios é a capacidade de uma organização de sentir mudanças internas/externas e responder de acordo, a fim de agregar valor aos clientes;
• Collective Ownership: Propriedade coletiva do código é convenção explícita de que cada membro da equipe pode fazer alterações em qualquer arquivo de código conforme necessário: seja para completar uma tarefa de desenvolvimento, para reparar um defeito ou para melhorar a estrutura geral do código;
• Continuous Deployment (CD): Implantação contínua visa reduzir tempo decorrido entre escrita de linha de código e disponibilização desse código aos usuários em produção. Para alcançar a implantação contínua, a equipe conta com uma infraestrutura que automatiza e instrumenta diversas etapas que levam à implantação, para que, após cada integração que atenda com sucesso a esses critérios de lançamento, o aplicativo ativo seja atualizado com o novo código;
• Continuous Integration (CI): Integração Contínua é prática de mesclar alterações de código em repositório compartilhado várias vezes ao dia, para lançar uma versão do produto a qualquer momento. Isto requer procedimento de integração que seja reproduzível e automatizado;
• CRC Cards: Cartões Class Responsibility Collaborator são técnica de design orientada a objetos, que as equipes podem usar para discutir o que uma classe deve saber e fazer, e com quais outras classes ela interage;
• Customer Development: Desenvolvimento do cliente é estrutura de 4 etapas, originalmente identificada por Steve Blank, para descobrir e validar que você identificou uma(s) necessidade(s) que os clientes criaram o produto certo para satisfazer [...];
• Daily Meeting: Reunião diária é técnica Agile mai praticada, apresentando oportunidade para equipe se reunir regularmente para coordenar suas atividades;
• Definition of Done: Definição de concluído é lista acordada das atividades consideradas necessárias para levar um incremento de produto, geralmente representado por uma história de usuário, a estado concluído ao final de um sprint;
• Definition of Ready: Definição de pronto envolve criação de critérios claros que uma história de usuário deve atender antes de ser aceita em uma próxima iteração. Isso normalmente é baseado na matriz INVEST;
• Epic: (Em breve);
• Timebox: Período de tempo para cada processo e atividade em projeto Scrum;
• Ubiquitous Language: Equipes usam linguagem onipresente para vocabulário de empresa nos requisitos, discussões de design e código-fonte de um produto de software;
• Unit Testing: Teste de unidade é pequeno fragmento de programa que exercita parte restrita do código-fonte do produto e verifica os resultados;
• Usability Testing: Teste de usabilidade é técnica empírica e exploratória para responder perguntas como "como um usuário final responderia ao nosso software em condições realistas?";
• User Stories: Em consulta com cliente ou proprietário do produto, equipe divide trabalho a ser realizado em incrementos funcionais chamados, "histórias de usuários";
• User Story Template: O modelo "função-recurso-motivo" é uma das ajudas mais comumente recomendadas para escrever histórias de usuários: "como... eu quero... para que...";
• Velocity: Velocidade são estimativas de esforço total associadas às histórias de usuários que foram concluídas durante iteração;
• Version Control: Controle de versão é facilitador de série de práticas agile, como integração contínua (CI).