Guia do Scrum Comentado
Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação.
Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos.
Backlog do Produto
O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto.
É a única origem dos requisitos para qualquer mudança a ser feita no produto.
O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação.
Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos estabelecem os requisitos inicialmente conhecidos e melhor entendidos.
Produtos interativos nunca tem fim. Por isso se foca no que é conhecido , que seu esforço e valor de negócio estimado dão o maior retorno.
O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil.
Se um produto existe, seu Backlog do Produto também existe.
O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões.
Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor. Os itens do Backlog geralmente incluem descrições de testes que comprovarão sua completude quando “Prontos”.
Um item tem que estar descrito de forma que não haja dúvida sobre o que ele vai realizar quando estiver finalizado.
Enquanto um produto é usado e ganha valor, e o mercado fornece feedback, o Backlog do Produto torna-se uma lista maior e mais completa. Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo. Mudanças nos requisitos de negócio, condições de mercado ou tecnologia podem causar mudanças no Backlog do Produto.
Constantemente. Pediu pra aumentar a logo? Vai pro Backlog para ser reestimado.
Múltiplos Times Scrum frequentemente trabalham juntos no mesmo produto. Um Backlog do Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog do Produto que agrupe itens pode ser então aplicado.
O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto. Este é um processo contínuo no qual o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos itens do Backlog do Produto. Durante o refinamento do Backlog do Produto, os itens são inspecionados e revisados. O Time de Scrum decide como e quando o refinamento está “Pronto”. Este refinamento usualmente não consome mais de 10% da capacidade do Time de Desenvolvimento. Contudo, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do Product Owner.
Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em maior clareza e maior detalhamento; Quanto menor a ordem na lista, menos detalhes.
Já que pode acontecer de nem todos os itens serem desenvolvidos.
Os itens do Backlog do Produto que irão ocupar o Time de Desenvolvimento na próxima Sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro do time-boxed da Sprint. Os itens do Backlog do Produto que podem ser “Prontos” pelo Time de Desenvolvimento dentro de uma Sprint são considerados “Preparados” para seleção no Planejamento da Sprint. Itens do Backlog do Produto geralmente adquirem este grau de transparência através das atividades de refinamento descritas acima.
O pedaço do Backlog selecionado para a Sprint deve estar separado em tarefas de no máximo um dia de trabalho para facilitar o acompanhamento diário.
O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve influenciar o Time de Desenvolvimento, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalho fazem a estimativa final.
Somente o Time de Desenvolvimento pode estimar esforço. O esforço pode inclusive influenciar como será a execução desse item.
Monitorando o Progresso a Caminho dos Objetivos
Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser somado.
O Product Owner acompanha o total do trabalho restante pelo menos a cada Revisão da Sprint. O Product Owner compara este valor com o trabalho restante nas Revisões das Sprints anteriores, para avaliar o progresso na direção de completar o trabalho previsto pelo tempo desejado para alcançar o objetivo. Esta informação deve ser transparente para todas as partes interessadas.
Conferir a estimativa realizada pelo restante do tempo é uma boa forma de medir se o Time precisa alterar sua velocidade de desenvolvimento.
Várias práticas para prever tendências foram usadas para prever o progresso, tais como burn-downs, burn-ups, ou fluxos cumulativos. Estas tem se provado úteis. Contudo, não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido.
Não gaste muito tempo tentando prever. Faça de forma que não atrapalhe a velocidade.
Somente o que já acorreu pode ser usado para uma tomada de decisão a respeito do que virá.
Backlog da Sprint
O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint.
O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto”.
O Backlog da Sprint torna visível todo o trabalho que o Time de Desenvolvimento identifica como necessário para atingir o objetivo da Sprint.
Para garantir melhoria contínua, é incluído no mínimo um item de prioridade alta sobre melhoria do processo identificado na última Reunião de Retrospectiva.
O Backlog da Sprint é um plano com detalhes suficientes que as mudanças no progresso sejam entendidas durante a Reunião Diária.
Tarefas de no máximo um dia.
O Time de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Este surgimento ocorre quando o Time de Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para atingir o objetivo da Sprint.
Tarefas são criadas e descartada sem alterar o objetivo da Sprint.
Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do trabalho restante é atualizada. Quando elementos do plano são considerados desnecessários, eles são removidos.
Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o Time de Desenvolvimento planeja completar durante a Sprint, e que pertence exclusivamente ao Time de Desenvolvimento.
Monitorando o Progresso da Sprint
Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos itens do Backlog da Sprint pode ser somado.
O Time de Desenvolvimento monitora o total do trabalho restante pelo menos a cada Reunião Diária para projetar a probabilidade de alcançar o objetivo da Sprint. Ao acompanhar o trabalho restante ao longo de toda a Sprint, o Time de Desenvolvimento pode gerenciar o seu progresso.
Incremento
O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição de ser utilizado e atender a definição de “Pronto” do Time Scrum. Um incremento é uma parte principal inspecionável de trabalho pronto que suporta empirismo no final da sprint. O incremento é um passo na direção de uma visão ou de um objetivo. O incremento deve estar na condição de ser utilizado independente do Product Owner decidir por liberá-lo ou não.
Transparência do Artefato
Scrum invoca transparência. Decisões para otimizar o valor e o controle de riscos são feitos. com base na percepção existente do estado dos artefatos. Na medida em que a transparência é plena, estas decisões tem uma base sólida. Na medida em que os artefatos não são completamente transparentes, estas decisões podem ser falhas, valores podem diminuir e riscos podem aumentar.
O Scrum Master deve trabalhar com o Product Owner, Time de Desenvolvimento, e outras partes envolvidas para entender se os artefatos estão plenamente transparentes. Há práticas para lidar com transparência incompleta, o Scrum Master deve ajudar todos a aplicar a mais apropriada prática na falta de uma transparência plena. O Scrum Master pode detectar transparência incompleta pela inspeção dos artefatos, percebendo padrões, ouvindo atentamente o que está sendo dito, e detectando diferenças entre o esperado e os resultados reais.
Diálogo e coragem é essencial.
O trabalho do Scrum Master é trabalhar com o Time Scrum e com a organização para aumentar a transparência dos artefatos. Este trabalho geralmente envolve aprendizagem, convencimento e mudança. Transparência não ocorre de um dia para o outro, mas é um caminho.
As pessoas só vão entender plenamente quando forem usar e ver o resultado final.
Definição de “Pronto”
Quando um item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa. Embora, isso possa variar por Time Scrum, os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é usado para assegurar quando o trabalho esta completado no incremento do produto.
A mesma definição orienta o Time de Desenvolvimento no conhecimento de quantos itens do Backlog do Produto podem ser selecionados durante o Planejamento da Sprint. O propósito de cada Sprint é entregar incrementos de funcionalidades potencialmente liberáveis que aderem à definição atual de “Pronto” do Time Scrum.
O Time de Desenvolvimento entrega um incremento de funcionalidade do produto a cada Sprint. Este incremento é utilizável, então o Product Owner pode escolher por liberá-lo imediatamente. Se a definição de “Pronto” para um incremento é parte das convenções, padrões ou diretrizes de desenvolvimento da organização, todos os Times Scrum devem segui-la como um mínimo.
Se “Pronto” para um incremento não é uma convenção de desenvolvimento da organização, o Time de Desenvolvimento do Time Scrum deve definir uma definição de “pronto” apropriada para o produto. Se há múltiplos Times Scrum trabalhando no sistema ou versão do produto, os Times de Desenvolvimento de todos os Times Scrum devem mutuamente definir uma definição de “Pronto”.
Cada incremento é adicionado a todos os incrementos anteriores e completamente testado, garantindo que todos os incrementos funcionam juntos.
Como um Time Scrum maduro, é esperado que a sua definição de “Pronto” seja expandida para incluir critérios mais rigorosos de alta qualidade. Novas definições, quando usadas, podem descobrir trabalho a ser feito em incrementos “Prontos” anteriormente. Qualquer produto ou sistema deve ter uma definição de “Pronto” que é um padrão para qualquer trabalho feito sobre ele.
A definição do item ajuda no entendimento do “pronto”. A definição deve conter os testes, evidências, resultados esperados e toda informação útil esperada do item do Backlog.
Conclusão
O Scrum é livre e oferecido neste guia. Papéis, eventos, artefatos e regras do Scrum são imutáveis e embora seja possível implementar somente partes do Scrum, o resultado não é Scrum. Scrum existe somente na sua totalidade e funciona bem como um container para outras técnicas, metodologias e práticas.
Você pode até não usar algo da estrutura do Scrum, mas garanta que exista uma forma de substituir essa ausência. Tudo descrito nesse guia tem um propósito de existir. Espero que minhas anotações tenham sido úteis e caso queira bater um papo ou comentar fique à vontade que tentarei responder o mais rápido possível.
Este artigo faz parte das minhas anotações sobre o Guia do Scrum, um capítulo em cada artigo, e se possível com exemplos práticos. Onde estiver em itálico é o texto do Guia, senão são minhas anotações.
