[Esta tradução adapta o texto original]
Ken Schwaber e Jeff Sutherland, co-autores do Scrum Guide, a introdução oficial ao Scrum (que dita as "regras do jogo") lançaram a primeira atualização do guia, originalmente lançado em fevereiro de 2010. A atualização foca no framework do Scrum, nas suas regras e cerimônias. Com principal mudança, o guia deixa de incluir detalhes específicos sobre estratégias e técnicas. Os autores dizem que iniciarão um resumo de "Melhores Práticas" para apresentar suas experiências.
A nova versão está disponível no site oficial do Scrum. A última página resume as mudanças em relação à versão anterior. Um documento separado, "Scrum Update", explica o contexto adicional do que foi mudado. A seguir são apresentadas as mudanças, juntamente com o contexto do que foi alterado.
O Scrum sempre deixou claro que existem somente três papeis, o Product Owner, ScrumMaster e o Membro do Time. Esses membros do time são chamados de Desenvolvedores no guia.
O time de pessoas que realizam o trabalho de criar um incremento é o Time de Desenvolvimento. Independentemente do trabalho executado por membros do time individualmente, são mais conhecidos como Desenvolvedores.
Os planos feitos no planejamento do sprint são frequentemente compromissos a serem assumidos. O próximo esclarecimento torna isso mais evidente em sprints curtos; o plano está aberto a mudanças, na medida em que for melhor compreendido:
Os Times de Desenvolvimento não se comprometem em completar um trabalho planejado durante o Sprint Planning. O Time de Desenvolvimento tem uma previsão do trabalho que acredita que será feito, mas a previsão mudará à medida que esse trabalho venha a ser mais conhecido durante o Sprint.
Nos últimos anos, os Diagramas de Fluxo Acumulativos (CFDs, em inglês) foram muitas vezes complementados ou substituídos pelos gráficos tradicionais de burndown para monitorar o progresso. Pelo esclarecimento abaixo, CFDs, burndowns, e outras abordagens de monitoramento são igualmente válidas, desde que informem diariamente o progresso do trabalho restante.
O Scrum não obriga a criação de um gráfico de burndown para monitorar o progresso; exige somente que:
- O restante do trabalho de um sprint seja resumido e conhecido diariamente.
- A tendência para completar o trabalho do sprint seja mantida ao longo do sprint.
Embora a maioria dos times faz de algum modo o planejamento do release, o planejamento do release não é obrigatório no framework Scrum, o que faz especialmente sentido para esforços de vida curta:
O Planejamento de um Release é algo de grande valia para se fazer quando se usa o Scrum, mas não é exigido pelo Scrum em si.
À medida que mais times utilizam ferramentas eletrônicas e criam relacionamentos complexos por meio de diferentes níveis de backlogs (por exemplo, do nível empresarial até o nível de time), perde o sentido a distinção exata entre os backlogs do produto. Como reforça o trecho abaixo, o backlog do sprint é simplesmente um conjunto de itens do backlog do produto que compõe o sprint, juntamente com um plano para realizá-los (para se tornarem Done).
O backlog do sprint é o conjunto de itens do backlog do produto selecionados para o sprint, somado um plano para entregá-los. Não há mais o conceito requerido para "itens do backlog do sprint", embora a técnica possa ajudar a criar um bom plano. Um Time de Desenvolvimento auto-organizado sempre tem um plano.
O conceito de priorização de um backlog do produto implica que a funcionalidade foi lançada puramente na ordem do valor de negócio, ignorando os aspectos técnicos e dilemas. O esclarecimento final usa a palavra "ordenada", ao invés de "priorizada", para representar uma visão mais holística da sequência para o lançamento.
O backlog do produto é "ordenado", ao invés de "priorizado". Isso traz flexibilidade para o Product Owner otimizar valor em suas circunstâncias específicas.
O novo guia está muito mais claro, e mais fácil de ler, além de mais conciso, o que beneficia o entendimento para aqueles que pretendem adotar o Scrum em seus times e empresas. Os esclarecimentos citados mostram a simplicidade do framework, desde a quantidade de papeis presentes e também dos itens que não são mais obrigatórios, como por exemplo o gráfico de burndown. O guia continua enfatizando a importância de o time adotar uma definição de "pronto" (Done), o que ajuda muito na identificação do que pode ser considerado um entregável para o Product Owner e para o negócio.