Guia do Scrum 2020 PDF

Ken Schwaber & Jeff Sutherland O Guia do Scrum O Guia Definitivo para o Scrum: As Regras do Jogo Novembro 2020 Objetivo do Guia do Scrum Desenvolvemos o Scrum no início dos anos 90. Escrevemos a primeira versão do Guia do Scrum em 2010 para ajudar pessoas em todo o mundo a compr...

Ken Schwaber & Jeff Sutherland O Guia do Scrum O Guia Definitivo para o Scrum: As Regras do Jogo Novembro 2020 Objetivo do Guia do Scrum Desenvolvemos o Scrum no início dos anos 90. Escrevemos a primeira versão do Guia do Scrum em 2010 para ajudar pessoas em todo o mundo a compreender o Scrum. Desenvolvemos o Guia desde então através de pequenas atualizações funcionais. Juntos, estamos por detrás disto. O Guia do Scrum contém a definição de Scrum. Cada elemento da estrutura serve um objetivo específico que é essencial para o valor global e para os resultados obtidos com o Scrum. Mudar o desenho do seu núcleo ou as ideias do Scrum, deixando de fora elementos ou não seguindo as regras do Scrum, encobre os problemas e limita os benefícios do Scrum, podendo mesmo torná‐lo inútil. Nós seguimos o uso crescente do Scrum num mundo cada vez mais complexo. Temos a humildade de ver o Scrum a ser adotado em muitos domínios com trabalho essencialmente complexo, para além do desenvolvimento de produtos de software, onde o Scrum tem as suas raízes. À medida que a utilização do Scrum se espalha, os criadores, investigadores, analistas, cientistas e outros especialistas fazem o seu trabalho. Usamos a palavra "criadores" no Scrum não para excluir mas para simplificar. Se obtiver valor do Scrum, considere‐se incluído. À medida que o Scrum vai sendo utilizado, podem ser encontrados, aplicados e concebidos padrões, processos e perceções que se enquadrem na estrutura do Scrum, tal como descrito neste documento. A sua descrição está para além do objetivo do Guia do Scrum porque são sensíveis ao contexto e diferem muito entre as utilizações do Scrum. Tais táticas de utilização dentro da estrutura do Scrum variam muito e são descritas noutros locais. Ken Schwaber & Jeff Sutherland Novembro 2020 © 2020 Ken Schwaber and Jeff Sutherland This publication is offered for license under the Attribution Share‐Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by‐sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share‐Alike license of Creative Commons. 1 Objetivo do Guia do Scrum........................................................................................................................... 1 Definição do Scrum....................................................................................................................................... 3 Teoria do Scrum............................................................................................................................................ 3 Transparência............................................................................................................................................ 4 Inspeção.................................................................................................................................................... 4 Adaptação................................................................................................................................................. 4 Valores do Scrum.......................................................................................................................................... 4 Scrum Team.................................................................................................................................................. 5 Developers................................................................................................................................................ 5 Product Owner.......................................................................................................................................... 6 Scrum Master............................................................................................................................................ 6 Eventos Scrum............................................................................................................................................... 7 O Sprint..................................................................................................................................................... 7 Sprint Planning.......................................................................................................................................... 8 Daily Scrum............................................................................................................................................... 9 Sprint Review.......................................................................................................................................... 10 Sprint Retrospective................................................................................................................................ 10 Artefatos do Scrum..................................................................................................................................... 10 Product Backlog...................................................................................................................................... 11 Compromisso: Product Goal............................................................................................................... 11 Sprint Backlog......................................................................................................................................... 11 Compromisso: Sprint Goal.................................................................................................................. 12 Increment................................................................................................................................................ 12 Compromisso: Definition of Done...................................................................................................... 12 Nota Final.................................................................................................................................................... 14 Agradecimentos.................................................................................................................................. 14 Pessoas................................................................................................................................................ 14 A História do Guia do Scrum............................................................................................................... 14 Tradução............................................................................................................................................. 14 Mudanças do Guia do Scrum 2017 para o Guia do Scrum 2020........................................................ 15 2 Definição do Scrum O Scrum é uma estrutura leve que ajuda as pessoas, equipas e organizações a gerar valor através de soluções adaptativas para problemas complexos. Em poucas palavras, Scrum requer um Scrum Master para promover um ambiente onde: 1. Um Product Owner ordena o trabalho para um problema complexo num Product Backlog. 2. A Scrum Team transforma uma seleção do trabalho num Increment de valor durante um Sprint. 3. A Scrum Team e os seus stakeholders inspecionam os resultados e ajustam‐se para o próximo Sprint. 4. Repete. O Scrum é simples. Experimente‐o como é e determine se a sua filosofia, teoria e estrutura ajudam a atingir objetivos e a criar valor. A estrutura do Scrum é propositadamente incompleta, definindo apenas as partes necessárias para implementar a teoria do Scrum. O Scrum é construído com base na inteligência coletiva das pessoas que o utilizam. Em vez de fornecer instruções detalhadas às pessoas, as regras do Scrum guiam as suas relações e interações. Vários processos, técnicas e métodos podem ser utilizados nesta estrutura. O Scrum envolve as práticas existentes ou torna‐as desnecessárias. O Scrum torna visível a eficácia relativa da gestão, ambiente e técnicas de trabalho atuais, de modo a que se possam fazer melhorias. Teoria do Scrum O Scrum baseia‐se no empirismo e no pensamento lean. O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com base no que é observado. O pensamento lean reduz o desperdício e concentra‐se no essencial. O Scrum emprega uma abordagem iterativa e incremental para optimizar a previsibilidade e para controlar o risco. O Scrum envolve grupos de pessoas que coletivamente têm todas as aptidões e conhecimentos para fazer o trabalho e partilhar ou adquirir tais aptidões conforme necessário. O Scrum combina quatro eventos formais para inspeção e adaptação contidos dentro de um outro evento, o Sprint. Estes eventos funcionam porque implementam os pilares empíricos Scrum de transparência, inspeção e adaptação. 3 Transparência O processo emergente e o trabalho devem ser visíveis tanto para quem executa o trabalho como para os que o recebem. Com o Scrum, as decisões importantes baseiam‐se na percepção do estado dos seus três artefatos formais. Os artefatos que têm pouca transparência podem levar a decisões que diminuem o valor e aumentam o risco. A transparência permite a inspeção. A inspeção sem transparência é enganadora e um desperdício. Inspeção Os artefatos do Scrum e o progresso rumo aos objetivos acordados, devem ser inspecionados frequente e diligentemente para detetar variâncias ou problemas potencialmente indesejáveis. Para ajudar na inspeção, o Scrum fornece cadência sob a forma dos seus cinco eventos. A inspeção permite a adaptação. A inspeção sem adaptação é considerada inútil. Os eventos do Scrum são concebidos para provocar mudanças. Adaptação Se quaisquer aspetos de um processo se desviarem para fora dos limites aceitáveis ou se o produto resultante for inaceitável, o processo a ser aplicado ou os artigos a serem produzidos devem ser ajustados. O ajustamento deve ser feito o mais rapidamente possível para minimizar novos desvios. A adaptação torna‐se mais difícil quando as pessoas envolvidas não estão capacitadas nem são autogeridas. Espera‐se que uma Scrum Team se adapte no momento em que aprende algo novo através da inspeção. Valores do Scrum A utilização bem‐sucedida do Scrum depende das pessoas se tornarem mais proficientes em viver cinco valores: Compromisso, Foco, Abertura, Respeito e Coragem A Scrum Team compromete‐se a alcançar os seus objetivos e a apoiar‐se mutuamente. O seu foco principal é o trabalho do Sprint para fazer o melhor progresso possível em direção a estes objetivos. A Scrum Team e os seus stakeholders estão abertos em relação ao trabalho e aos desafios. Os membros da Scrum Team respeitam‐se uns aos outros para serem capazes e pessoas independentes, sendo respeitados como tal pelas pessoas com quem trabalham. Os membros da Scrum Team têm a coragem de fazer o que está certo e trabalhar em problemas difíceis. 4 Estes valores dão orientação à Scrum Team no que diz respeito ao seu trabalho, ações e comportamento. As decisões que são tomadas, os passos dados e a forma como o Scrum é utilizado, devem reforçar estes valores e não reduzi‐los ou miná‐los. Os membros da Scrum Team aprendem e exploram os valores enquanto trabalham com os eventos e os artefatos do Scrum. Quando estes valores são encarnados pela Scrum Team e as pessoas com quem trabalham, os pilares empíricos Scrum da transparência, inspeção e adaptação ganham vida construindo confiança. Scrum Team A unidade fundamental do Scrum é uma pequena equipa de pessoas, uma Scrum Team. A Scrum Team é composta por um Scrum Master, um Product Owner e Developers. Dentro de uma Scrum Team, não existem subequipas ou hierarquias. É uma unidade coesa de profissionais, focada num objetivo de cada vez, o Product Goal. As Scrum Teams são multifuncionais, o que significa que os membros têm todas as competências necessárias para criar valor em cada Sprint. Também são autogeridas, o que significa que decidem internamente quem faz o quê, quando e como. A Scrum Team é suficientemente pequena para permanecer ágil e suficientemente grande para completar um trabalho significativo dentro de um Sprint, tipicamente 10 ou menos pessoas. Em geral, descobrimos que as equipas mais pequenas comunicam melhor e são mais produtivas. Se as Scrum Teams se tornarem demasiado grandes, devem considerar a reorganização em múltiplas Scrum Team coesas, focadas no mesmo produto. Por conseguinte, devem partilhar o mesmo Product Goal, Product Backlog e Product Owner. A Scrum Team é responsável por todas as atividades relacionadas com os produtos, desde a colaboração dos stakeholders, verificação, manutenção, operação, experimentação, investigação e desenvolvimento, assim como tudo o mais que possa ser necessário. São estruturadas e capacitadas pela organização para gerir o seu próprio trabalho. Trabalhar em Sprints a um ritmo sustentável melhora o foco e a consistência da Scrum Team. Toda a Scrum Team é responsável pela criação de um valioso e útil Increment em cada Sprint. O Scrum define três responsabilidades específicas dentro da Scrum Team: os Developers, o Product Owner e o Scrum Master. Developers Os Developers são as pessoas da Scrum Team que estão empenhados em criar qualquer aspeto de um Increment utilizável em cada Sprint. As competências específicas necessárias aos Developers são frequentemente amplas e variam com o domínio de trabalho. Contudo, os Developers são sempre responsáveis por: 5  Criar um plano para o Sprint, o Sprint Backlog; Incutir qualidade, aderindo a uma Definition of Done; Adaptar o seu plano todos os dias na direção do Sprint Goal; e, Responsabilizarem‐se uns aos outros como profissionais. Product Owner O Product Owner é responsável por maximizar o valor do produto resultante do trabalho da Scrum Team. A forma como isto é feito pode variar muito entre organizações, ScrumTeams e indivíduos. O Product Owner é também responsável pela gestão eficaz do Product Backlog, que inclui: Desenvolver e comunicar explicitamente o Product Goal; Criar e comunicar claramente os itens do Product Backlog; Ordenar os itens do Product Backlog; e, Assegurar que o Product Backlog é transparente, visível e compreendido. O Product Owner pode fazer o trabalho acima referido ou pode delegá‐lo a outros. Independentemente disso, o Product Owner permanece responsável. Para que o Product Owner tenha sucesso, toda a organização deve respeitar as suas decisões. Estas decisões são visíveis no conteúdo e ordenação do Product Backlog e através do Increment inspecionável na Sprint Review. O Product Owner é uma pessoa, não um comité. O Product Owner pode representar as necessidades de muitos intervenientes no Product Backlog. Aqueles que desejam alterar o Product Backlog podem fazê‐ lo, tentando convencer o Product Owner. Scrum Master O Scrum Master é responsável pela implementação do Scrum tal como definido no Guia do Scrum. Fá‐lo ajudando todos a compreender a teoria e a prática do Scrum, tanto dentro da Scrum Team como dentro da organização. O Scrum Master é responsável pela eficácia da Scrum Team. Fá‐lo permitindo à Scrum Team melhorar as suas práticas, dentro da estrutura do Scrum. Os Scrum Masters são verdadeiros líderes que servem a Scrum Team e a organização em geral. O Scrum Master serve a Scrum Team de várias formas, incluindo: 6  Treinar os membros da equipa na auto‐gestão e na multifuncionalidade; Ajudando a Scrum Team a concentrar‐se na criação de Increments de alto valor que vão ao encontro da Definition of Done; Causar a remoção de impedimentos ao progresso da Scrum Team; e, Assegurar que todos os eventos do Scrum têm lugar e são positivos, produtivos e mantidos dentro tempo previsto. O Scrum Master serve o Product Owner de várias formas, incluindo: Ajudando a encontrar técnicas para uma definição eficaz do Product Goal e para a gestão do Product Backlog; Ajudando a Scrum Team a compreender a necessidade de itens claros e concisos no Product Backlog; Ajudar a estabelecer o planeamento empírico do produto para um ambiente complexo; e, Facilitar a colaboração dos stakeholders conforme solicitado ou necessário. O Scrum Master serve a organização de várias formas, incluindo: Liderar, formar e treinar a organização na sua adopção do Scrum; Planear e aconselhar implementações de Scrum dentro da organização; Ajudar funcionários e stakeholders a compreender e adoptar uma abordagem empírica para trabalhos complexos; e, Remover barreiras entre stakeholders e Scrum Teams. Eventos Scrum O Sprint é um recipiente para todos os outros eventos. Cada evento no Scrum é uma oportunidade formal para inspecionar e adaptar os artefatos do Scrum. Estes eventos são especificamente concebidos para permitir a transparência necessária. A não realização de quaisquer eventos conforme prescrito, resulta na perda de oportunidades de inspeção e adaptação. Os eventos são utilizados no Scrum para criar regularidade e para minimizar a necessidade de reuniões não definidas no Scrum. Idealmente, todos os eventos são realizados à mesma hora e no mesmo local para reduzir a complexidade. O Sprint Os Sprints são o bater de coração do Scrum, onde as ideias são transformadas em valor. São eventos de duração fixa de um mês ou menos para criar consistência. Um novo Sprint começa imediatamente após a conclusão do Sprint anterior. 7 Todo o trabalho necessário para alcançar o Product Goal, incluindo ol Sprint Planning, as Daily Scrums, a Sprint Review e a Sprint Retrospective, acontece dentro dos Sprints. Durante o Sprint: Não são feitas alterações que possam pôr em perigo o Sprint Goal; A qualidade não diminui; O Product Backlog é refinado conforme necessário; e, O âmbito pode ser clarificado e renegociado com o Product Owner à medida que mais se for aprendendo. Os Sprints permitem a previsibilidade, assegurando a inspeção e adaptação do progresso para um Product Goal pelo menos uma vez por mês. Quando o horizonte de um Sprint é demasiado longo, o Sprint Goal pode tornar‐se inválido e a complexidade e o risco podem aumentar. Sprints mais curtos podem ser utilizados para gerar mais ciclos de aprendizagem e limitar o risco de custo e esforço num período de tempo menor. Cada Sprint pode ser considerado um projeto curto. Existem várias práticas para prever o progresso, como burn‐downs, burn‐ups ou fluxos cumulativos. Embora comprovadamente úteis, estas não substituem a importância do empirismo. Em ambientes complexos, o que irá acontecer é desconhecido. Apenas o que já aconteceu pode ser utilizado para a tomada de decisão prospetiva. Um Sprint pode ser cancelado se o Sprint Goal se tornar obsoleto. Apenas o Product Owner tem autoridade para cancelar o Sprint. Sprint Planning O Sprint Planning inicia o Sprint, determinando o trabalho a ser realizado para o mesmo. Este plano resultante é criado pelo trabalho colaborativo de toda a Scrum Team. O Product Owner garante que os participantes estão preparados para discutir os itens mais importantes do Product Backlog e a forma como eles se refletem no Product Goal. A Scrum Team pode também convidar outras pessoas a participar no Sprint Planning para darem conselhos. O Sprint Planning aborda os seguintes tópicos: Tópico Um: Porque é que este Sprint é valioso? O Product Owner propõe como o produto poderia aumentar o seu valor e utilidade no Sprint atual. Toda a Scrum Team colabora então para definir um Sprint Goal que comunica a razão pela qual o Sprint é valioso para os stakeholders. O Sprint Goal deve ser definido antes do fim do Sprint Planning. 8 Tópico Dois: O que se pode fazer neste Sprint? Através de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir no Sprint atual. A Scrum Team pode refinar estes itens durante este processo, o que aumenta a compreensão e a confiança. Selecionar quanto pode ser concluído dentro de um Sprint pode ser um desafio. Contudo, quanto mais os Developers souberem sobre o seu desempenho passado, a sua capacidade futura e a sua Definition of Done, mais confiantes estarão nas suas previsões para o Sprint. Tópico Três: Como será feito o trabalho escolhido? Para cada item de Product Backlog selecionado, os Developers planeiam o trabalho necessário para criar um Increment que corresponda à Definition of Done. Isto é frequentemente feito decompondo os itens do Product Backlog em itens de trabalho mais pequenos, de um dia ou menos. A forma como isto é feito fica ao critério exclusivo dos Developers. Ninguém lhes diz como transformar itens de Product Backlog em Increments de valor. O Sprint Goal, os itens de Product Backlog selecionados para o Sprint e o plano de entrega dos mesmos, são referidos em conjunto como o Sprint Backlog. O Sprint Planning é limitado a um máximo de oito horas para um Sprint de um mês. Para Sprints mais reduzidos, o evento é normalmente mais curto. Daily Scrum O objetivo da Daily Scrum é inspecionar o progresso rumo ao Sprint Goal e adaptar o Sprint Backlog conforme necessário, ajustando o trabalho planeado que se aproxima. A Daily Scrum é um evento de 15 minutos para os Developers da Scrum Team. Para reduzir a complexidade, é realizado à mesma hora e em todos os dias úteis do Sprint. Se o Product Owner ou o Scrum Master estiver a trabalhar ativamente nos itens do Sprint Backlog, eles participam como Developers. Os Developers podem selecionar qualquer estrutura e técnicas que desejarem, desde que a Daily Scrum se concentre no progresso rumo ao Sprint Goal e produza um plano acionável para o dia de trabalho seguinte. Isto cria foco e melhora a auto‐gestão. As Daily Scrums melhoram as comunicações, identificam impedimentos, promovem a tomada de decisões rápidas e, consequentemente, eliminam a necessidade de outras reuniões. 9 A Daily Scrum não é o único momento em que os Developers são autorizados a ajustar o seu plano. Eles reúnem‐se frequentemente ao longo do dia para discussões mais detalhadas sobre a adaptação ou reorganização do resto do trabalho do Sprint. Sprint Review O objetivo da Sprint Review é inspecionar o resultado do Sprint e determinar adaptações futuras. A Scrum Team apresenta os resultados do seu trabalho aos principais stakeholders e são discutidos os progressos rumo ao Product Goal. Durante o evento, a ScrumTeam e os stakeholders analisam o que foi realizado no Sprint e o que mudou no seu ambiente. Com base nesta informação, os participantes colaboram sobre o que fazer a seguir. O Product Backlog também pode ser ajustado para ir ao encontro de novas oportunidades. A Sprint Review é uma sessão de trabalho e a Scrum Team deve evitar limitá‐la a uma apresentação. A Sprint Review é o penúltimo evento do Sprint e é limitada a um máximo de quatro horas para um Sprint de um mês. Para Sprints mais reduzidos, o evento é geralmente mais curto. Sprint Retrospective O objetivo da Sprint Retrospective é planear formas de aumentar a qualidade e eficácia. A Scrum Team inspeciona como correu o último Sprint no que diz respeito a indivíduos, interações, processos, ferramentas e à sua Definition of Done. Os elementos inspecionados variam frequentemente com o âmbito do trabalho. As suposições que os desviaram são identificadas e as suas origens exploradas. A Scrum Team discute o que correu bem durante o Sprint, que problemas encontrou e como esses problemas foram (ou não) resolvidos. A Scrum Team identifica as mudanças mais úteis para melhorar a sua eficácia. As melhorias mais impactantes são endereçadas o mais rapidamente possível. Podem mesmo ser acrescentadas ao Sprint Backlog para o Sprint seguinte. A Sprint Retrospective conclui o Sprint. É limitada a um máximo de três horas para um Sprint de um mês. Para Sprints mais reduzidos, o evento é normalmente mais curto. Artefatos do Scrum Os artefatos do Scrum representam trabalho ou valor. São concebidos para maximizar a transparência da informação chave. Assim, todos os que os inspecionam têm a mesma base para adaptação. 10 Cada artefato contém um compromisso, para assegurar que fornece informação que aumenta a transparência e o foco, contra o qual o progresso pode ser medido: Para o Product Backlog é Product Goal. Para o Sprint Backlog é o Sprint Goal. Para o Increment é a Definition of Done. Estes compromissos existem para reforçar o empirismo e os valores do Scrum para a Scrum Team e os seus stakeholders. Product Backlog O Product Backlog é uma lista emergente e ordenada do que é necessário para melhorar o produto. É a única fonte de trabalho levada a cabo pela Scrum Team. Os artigos do Product Backlog que podem ser feitos pela Scrum Team dentro de um Sprint, são considerados prontos para seleção num evento de Sprint Planning. Normalmente adquirem este grau de transparência após as atividades de refinamento. O refinamento do Product Backlog é o ato de decompor e definir melhor os itens do mesmo em itens mais pequenos e mais precisos. Esta é uma atividade contínua para acrescentar detalhes, tais como descrição, ordenação e tamanho. Os atributos variam frequentemente com o domínio de trabalho. Os Developers que irão fazer o trabalho são responsáveis pelo dimensionamento. O Product Owner pode influenciar os Developers ajudando‐os a compreender e a selecionar trade‐offs. Compromisso: Product Goal O Product Goal descreve um estado futuro do produto que pode servir de meta para a Scrum Team delinear o seu planeamento. O Product Goal está no Product Backlog. O resto do Product Backlog surge para definir "o que" o Product Goal irá cumprir. Um produto é um veículo para entregar valor. Tem um limite claro, stakeholders conhecidos, utilizadores ou clientes bem definidos. Um produto pode ser um serviço, um produto físico, ou algo mais abstrato. O Product Goal é o objetivo a longo prazo para a Scrum Team. Devem cumprir (ou abandonar) um objetivo antes de assumirem o próximo. Sprint Backlog O Sprint Backlog é composto pelo Sprint Goal (porquê), o conjunto de itens do Produto Backlog selecionados para o Sprint (o quê), bem como um plano acionável para a entrega do Increment (como). 11 O Sprint Backlog é um plano de e para os Developers. É uma imagem altamente visível e em tempo real do trabalho que os Developers planeiam realizar durante o Sprint, a fim de alcançar o Sprint Goal. Consequentemente, o Sprint Backlog é atualizado durante o Sprint à medida que se vai aprendendo mais. Deverá ter detalhe suficiente para que possam inspecionar o seu progresso na Daily Scrum. Compromisso: Sprint Goal O Sprint Goal é o único objetivo para o Sprint. Embora o Sprint Goal seja um compromisso dos Developers, proporciona flexibilidade em termos do trabalho exato necessário para o alcançar. O Sprint Goal também cria coerência e foco, encorajando a Scrum Team a trabalhar em conjunto e não em iniciativas separadas. O Sprint Goal é criado durante o Sprint Planning e depois adicionado ao Sprint Backlog. Durante o seu trabalho durante o Sprint, os Developers mantêm o Sprint Goal em mente. Se o trabalho se revelar diferente do que esperavam, colaboram com o Product Owner para negociar o âmbito do Sprint Backlog dentro do Sprint sem afetar o Sprint Goal. Increment Um Increment é um degrau concreto em direção ao Product Goal. Cada Increment é acrescentado a todos os Increments anteriores e cuidadosamente verificado, assegurando que todos os Increments funcionam em conjunto. A fim de fornecer valor, o Increment deve ser utilizável. Podem ser criados multiplos Increments dentro de um Sprint. A soma dos Increments é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um Increment pode ser entregue aos stakeholders antes do fim do Sprint. A Sprint Review nunca deve ser considerada como uma porta para a entrega de valor. O trabalho não pode ser considerado parte de um Increment a menos que cumpra a Definition of Done. Compromisso: Definition of Done A Definition of Done é uma descrição formal do estado do Increment quando este cumpre as medidas de qualidade exigidas para o produto. No momento em que um item do Product Backlog satisfaz a Definition of Done, nasce um Increment. A Definition of Done cria transparência ao proporcionar a todos uma compreensão partilhada do trabalho que foi concluído como parte do Increment. Se um item de Product Backlog não cumpre a Definition of Done, não pode ser lançado ou mesmo apresentado na Sprint Review. Em vez disso, regressa ao Product Backlog para consideração futura. 12 Se a Definition of Done para um Increment fizer parte dos padrões da organização, todas as Scrum Teams devem segui‐lo como um mínimo. Se não for uma norma organizacional, a Scrum Team deve criar uma Definition of Done apropriada para o produto. Os Developers são obrigados a cumprir a Definition of Done. Se existirem várias Scrum Teams a trabalhar em conjunto num produto, devem definir e cumprir mutuamente a mesma Definition of Done. 13 Nota Final O Scrum é gratuito e oferecido neste Guia. A estrutura do Scrum, tal como aqui delineado, é imutável. Embora seja possível implementar apenas partes do Scrum, o resultado não é considerado Scrum. O Scrum existe apenas como um todo e funciona bem como um recipiente para outras técnicas, metodologias e práticas. Agradecimentos Pessoas Dos milhares de pessoas que contribuíram para o Scrum, nós devemos destacar aquelas que foram essenciais no início: Jeff Sutherland trabalhou com Jeff McKenna e John Scumniotales, Ken Schwaber trabalhou com Mike Smith e Chris Martin, e todos eles trabalharam em conjunto. Muitos outros contribuíram nos anos que se seguiram e sem a sua ajuda, o Scrum não estaria tão refinado como está atualmente. A História do Guia do Scrum Ken Schwaber e Jeff Sutherland co‐apresentaram o Scrum pela primeira vez na Conferência da OOPSLA em 1995. Esta apresentação documentou essencialmente a aprendizagem que Ken e Jeff obtiveram nos anos anteriores e tornou pública a primeira definição formal de Scrum. O Guia do Scrum documenta o Scrum tal como foi desenvolvido, evoluído e sustentado durante mais de 30 anos por Jeff Sutherland e Ken Schwaber. Outras fontes fornecem padrões, processos e ideias que complementam a estrutura do Scrum. Estas podem aumentar a produtividade, valor, criatividade e satisfação com os resultados. A história completa do Scrum é descrita noutro local. Para honrar os primeiros lugares onde foi testado e comprovado, queremos reconhecer a Individual Inc., Newspage, Fidelity Investments e IDX (agora GE Medical). Tradução Este guia foi traduzido por Pedro Silva e Mário Pereira, a partir da versão original em inglês fornecida por Ken Schwaber e Jeff Sutherland. 14 Mudanças do Guia do Scrum 2017 para o Guia do Scrum 2020 Ainda menos prescritivo Ao longo dos anos, o Guia do Scrum começou a tornar‐se um pouco mais prescritivo. A versão 2020 visava trazer o Scrum de volta a uma estrutura minima suficiente, removendo ou suavizando a linguagem prescritiva, por exemplo, removendo as perguntas da Daily Scrum, suavizando a linguagem em torno dos atributos dos itens do Produck Backlog, suavizando a linguagem em torno dos itens retro no Sprint Backlog, reduzindo a secção do cancelamento do Sprint, entre outros. Uma Equipa, centrada Num Produto O objetivo era eliminar o conceito de uma equipa separada dentro de uma equipa que levou a um comportamento de "procuração" ou "nós e eles" entre o Product Owner e Equipa de Desenvolvimento. Existe agora apenas uma Scrum Team centrada no mesmo objetivo, com três conjuntos diferentes de responsabilidades: Product Owner, Scrum Master e Developers. Introdução do Product Goal O Guia do Scrum 2020 introduz o conceito de um Product Goal a fim de proporcionar um foco para a Scrum Team rumo a um objetivo de maior valor. Cada Sprint deve aproximar o produto do Product Goal geral. Uma Casa para o Sprint Goal, Definition of Done e Product Goal Os Guias do Scrum anteriores descreviam o Sprint Goal e a Definition of Done sem realmente lhes dar uma identidade. Não eram bem artefatos mas estavam de certa forma ligados a artefatos. Com a adição do Product Goal, a versão 2020 fornece mais clareza em torno disto. Cada um dos três artefatos contém agora "compromissos" com eles. Para o Product Backlog é o Product Goal, o Backlog de Sprint tem o Sprint Goal e o Increment tem a Definition of Done (agora sem as aspas). Estes existem para trazer transparência e concentração no progresso de cada artefato. Auto‐Gestão em vez de Auto‐Organização Os anteriores Guias do Scrum referiam‐se às Equipas de Desenvolvimento como auto‐organizadas, escolhendo quem e como fazer o trabalho. Com um maior enfoque na Scrum Team, a versão 2020 enfatiza uma auto‐gestão da Scrum Team, escolhendo quem, como e em que trabalhar. Três Tópicos do Sprint Planning Para além dos tópicos do Sprint Planning de "O quê" e "Como", o Guia do Scrum 2020 coloca ênfase num terceiro tópico, "Porquê", referindo‐se ao Sprint Goal. 15 Simplificação geral da linguagem para um público mais vasto O Guia do Scrum 2020 colocou ênfase na eliminação de declarações redundantes e complexas, bem como na eliminação de qualquer inferência remanescente ao trabalho de TI (por exemplo, testes, sistema, concepção, requisitos, etc.). O Guia do Scrum tem agora menos de 13 páginas. 16