O Guia do Scrum - EduardoDebonieduardodeboni.com/download/Scrum_Guide_2011_PTBR.pdf · O Guia do Scrum O Guia definitivo para o Scrum As regras do jogo Julho 2011 Desenvolvido e Mantido

O Guia do Scrum

O Guia definitivo para o Scrum

As regras do jogo

Julho 2011

Desenvolvido e Mantido por Ken Schwaber e Jeff Sutherland

Traduzido para o Português por José Eduardo Deboni (eduardodeboni.com)

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 2

Conteúdo Propósito do Guia do Scrum ........................................................................................................................ 3

Visão Geral do Scrum ................................................................................................................................... 3

Framework Scrum ........................................................................................................................................ 3

A Teoria do Scrum ........................................................................................................................................ 3

Transparência .............................................................................................................................................. 3

Inspeção ....................................................................................................................................................... 4

Adaptação .................................................................................................................................................... 4

Scrum ........................................................................................................................................................... 4

A Equipe de Scrum ....................................................................................................................................... 4

O Dono do produto ...................................................................................................................................... 5

A equipe de desenvolvimento ..................................................................................................................... 5

O Tamanho da Equipe de Desenvolvimento ................................................................................................ 6

O Scrum Master ........................................................................................................................................... 6

Os serviços do Scrum Master para o Dono do Produto ............................................................................... 6

Os serviços do Scrum Master para a Equipe de Desenvolvimento .............................................................. 6

Os serviços do Scrum Master para a Organização ....................................................................................... 7

Eventos do Scrum ........................................................................................................................................ 7

O Sprint ........................................................................................................................................................ 7

Cancelando um Sprint. ................................................................................................................................. 8

Reunião de Planejamento do Sprint ............................................................................................................ 8

Parte 1: O que será Pronto neste Sprint? .................................................................................................... 9

Parte 2: Como o trabalho escolhido será Pronto? ....................................................................................... 9

Objetivo do Sprint ........................................................................................................................................ 9

Scrum Diário............................................................................................................................................... 10

Revisão do Sprint ....................................................................................................................................... 10

A Retrospectiva do Sprint. ......................................................................................................................... 11

Backlog do produto .................................................................................................................................... 12

Monitorando o Progresso na direção de um Objetivo .............................................................................. 13

Backlog do Sprint ....................................................................................................................................... 13

Monitoramento do Progresso do Sprint .................................................................................................... 14

Incremento ................................................................................................................................................ 14

Definição do “Pronto” ................................................................................................................................ 14

Conclusão ................................................................................................................................................... 15

Agradecimentos ......................................................................................................................................... 16


Propósito do Guia do Scrum Scrum é um framework para desenvolver e manter produtos complexos. Este Guia contém a definição

do Scrum. Esta definição consiste em papeis, eventos, artefatos do Scrum e as regras que mantém

tudo integrado. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum, o Guia do Scrum é escrito e

oferecido por eles. Juntos, eles apoiam o Guia do Scrum.

Visão Geral do Scrum Scrum (subs masc.): Um framework dentro do qual as pessoas podem resolver problemas adaptativos

complexos, enquanto, produtivamente e criativamente entregam produtos com o mais alto valor

possível. O Scrum é:

Leve

De entendimento simples

Extremamente difícil de ter o domínio

O Scrum é um framework de processo quem tem sido usado para gerenciar o desenvolvimento de

produtos complexos desde o início dos anos 90. Scrum não é um processo ou técnica para construir

produtos, é mais um framework dentro do qual se pode empregar processos e técnicas variadas. O

Scrum torna clara a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos,

para que você possa melhorá-las.

Framework Scrum O framework Scrum consiste nas equipes do Scrum, papéis, eventos, artefatos e regras associados.

Cada componente do framework serve a um propósito específico e é essencial para o sucesso e uso do

Scrum.

Estratégias específicas para uso do framework Scrum variam e são descritas em outros documentos.

As regras do Scrum integram os eventos, papéis e artefatos, governando as relações e interações entre

eles. As regras do Scrum são descritas ao longo do corpo deste documento.

A Teoria do Scrum O Scrum está baseado nas teorias empíricas de controle de processo. O empirismo afirma que o

conhecimento vem da experiência e tomar decisões baseados no que se conhece. O Scrum aplica uma

abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.

Três pilares sustentam a implementação de um controle de processo empírico: transparência,

inspeção e adaptação.

Transparência Aspectos significativos do processo devem estar visíveis para os responsáveis pelos resultados.

Transparência requer que aqueles aspectos sejam definidos por um padrão comum para que os

observadores compartilhem um entendimento comum do que está sendo visto.


Por exemplo:

Uma linguagem comum para se referir ao processo, deve ser compartilhada por todos os

participantes,

Uma definição comum de “Pronto1” deve ser compartilhada por aqueles que desempenham o

trabalho e aqueles que dão o aceite do produto do trabalho.

Inspeção Os usuários do Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso com

objetivo de detectar variações não desejadas. Esta inspeção não deve ser tão frequente, que a

inspeção fique no caminho do trabalho. As Inspeções são mais benéficas quando desempenhadas por

inspetores habilidosos [diligentes] no local do trabalho.

Adaptação Se um inspetor determina que um ou mais aspectos do processo desviar para longe de limites

aceitáveis, e que o resultado do produto não é aceitável, o processo ou o material que está sendo

processado deve ser ajustado. Um ajuste deve ser feito tão logo quanto possível para minimizar os

desvios futuros.

O Scrum prescreve quatro oportunidades formais para inspeção e adaptação, como descritas na seção

de Eventos do Scrum deste documento:

Reunião de Planejamento do Sprint

Scrum Diário

Reunião de Revisão do Sprint

Retrospectiva do Sprint

Scrum O Scrum é um framework estruturado para suportar o desenvolvimento de produtos complexos. O

Scrum é formado pelas Equipes de Scrum e os papéis, eventos, artefatos e regras associadas. Cada

componente no framework serve para um propósito específico e é essencial para o uso e sucesso do

Scrum.

As regras do Scrum integram os eventos, papeis e artefatos, governando as relações e interações entre

eles. As regras do Scrum são descritas ao longo do corpo deste documento.

A Equipe de Scrum A Equipe de Scrum é formada do Dono do Produto, da Equipe de Desenvolvimento e do ScrumMaster.

As Equipes de Scrum são auto organizadas e trans-funcionais. Equipes auto organizadas escolhem a

melhor forma de realizar seu trabalho, ao contrário de serem dirigidas por outros de fora da equipe.

Equipes trans-funcionais tem todas as competências necessárias para realizar o trabalho sem a

dependência de outras que não fazem parte da equipe. A equipe modelo no Scrum é projetada para

aperfeiçoar a flexibilidade, criatividade e produtividade.

1 Veja a definição na página 15.


As equipes do Scrum produzem iterativamente e incrementalmente, aproveitando ao máximo as

oportunidades para realimentação. Entregas incrementais de produtos “Prontos” garantem que uma

versão potencialmente útil do produto esteja sempre disponível.

O Dono do produto O Dono do produto2 é responsável por maximizar o valor do produto e do trabalho da equipe de

desenvolvimento. Como isso é feito pode variar amplamente entre organizações, equipes de Scrum e

indivíduos.

O Dono do produto é a única pessoa responsável por gerenciar o Backlog do produto. O

gerenciamento do Backlog do produto inclui:

Expressar com clareza os itens do Backlog do produto;

Ordenar os itens do Backlog do produto para melhor alcançar os objetivos e missões;

Garantir o valor do trabalho desempenhado pela equipe de desenvolvimento;

Garantir que o Backlog do produto seja visível, transparente e claro para todos, e mostre no que

a equipe do Scrum irá trabalhar em seguida;

Garantir que a equipe de desenvolvimento entenda os itens do Backlog do produto no nível

necessário.

O Dono do produto pode fazer o trabalho acima, ou deixar que a equipe de projeto o faça. Entretanto,

o Dono do produto é o responsável por ele.

O Dono do produto é uma pessoa, e não um comitê. O Dono do produto pode representar os desejos

de um comitê no backlog do produto, mas aqueles que quiserem mudar um item do backlog do

produto devem convencer o Dono do produto.

Para o Dono do produto ter sucesso, toda a organização deve respeitar a sua decisão. As decisões do

Dono do produto estão visíveis no conteúdo e na organização do backlog do produto. Ninguém está

autorizado a mandar a equipe de desenvolvimento trabalhar em um conjunto diferente de requisitos e

a equipe de desenvolvimento não está autorizada a agir sobre o que outras pessoas disserem.

A equipe de desenvolvimento A equipe de desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma

versão usável que potencialmente incrementa o produto “Pronto” no final de cada Sprint. Somente

membros da equipe de desenvolvimento criam o incremento.

As equipes de desenvolvimento são estruturadas e autorizadasligei pela organização para organizar e

gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e efetividade global. As

equipes de desenvolvimento têm as seguintes características:

Elas são auto organizadas. Ninguém (nem mesmo o Scrum Master) diz para a equipe de

projetos como transformar o Backlog de produto em incrementos de funcionalidades

potencialmente utilizáveis;

2 Nota do Tradutor: O termo em inglês é Product Owner e foi traduzido aqui como Dono do Produto, em letra

maiúscula, para indicar que é um papel representado no processo do Scrum e não aquele que seria o proprietário do produto de software.


Equipes de desenvolvimento são trans funcionais, com todas as habilidades necessárias para

criar o incremento do produto.

O Scrum não reconhece perfis dos membros da equipe de desenvolvimento além de

Desenvolvedor, independente do trabalho que está sendo realizado pela pessoa, não há

exceções a essa regra;

Individualmente os membros da equipe de desenvolvimento podem ter habilidades

especializadas e áreas de especialização, mas pertencem e respondem à equipe de

desenvolvimento como um todo; e,

Equipes de desenvolvimento não possuem sub-equipes dedicadas a domínios particulares do

conhecimento, como teste ou análise de negócio.

O Tamanho da Equipe de Desenvolvimento O tamanho ótimo de uma equipe de desenvolvimento é suficientemente pequeno que se mantenha

ágil, e grande o suficiente para completar uma parcela representativa do trabalho. Menos do que três

membros em uma equipe de desenvolvimento diminui a interação e resulta em ganhos menores de

produtividade. Equipes pequenas podem encontrar limitações nas habilidades necessárias para um

Sprint, e como consequência não conseguindo entregar um incremento potencialmente utilizável.

Tendo mais do que nove membros se requer muita coordenação. Equipes de desenvolvimento grandes

geram muita complexidade para um processo empírico gerenciar. Os papeis de Dono do produto e o

Scrum Master não são incluídos nesta contagem a não ser que eles também executem o trabalho do

Sprint Backlog.

O Scrum Master O Scrum Master é responsável para garantir que o Scrum seja entendido e aplicado. Os Scrum Masters

fazem isso garantindo que as equipes de Scrum obedeçam à teoria, práticas e regras do Scrum. O

Scrum Master é um líder-facilitador para a equipe do Scrum.

O Scrum Master ajuda aqueles de fora da equipe do Scrum entender quais são as interações com a

equipe do Scrum que são benéficas e quais não são. O Scrum Master ajudar todos a mudar suas

interações para maximizar o valor criado pela equipe de Scrum.

Os serviços do Scrum Master para o Dono do Produto O Scrum Master serve ao Dono do produto de várias formas, incluindo:

Encontrar técnicas para o gerenciamento efetivo do Backlog do produto,

Comunicar claramente a visão, objetivos e os itens do Backlog do Produto para a Equipe de

Desenvolvimento,

Ensinar a Equipe de Desenvolvimento como criar itens do Backlog do produto claros e concisos,

Entender o planejamento de longo prazo do produto em um ambiente empírico,

Entender e praticar a agilidade,

Facilitar os eventos do Scrum quando solicitado ou necessário.

Os serviços do Scrum Master para a Equipe de Desenvolvimento O Scrum Master serve a Equipe de Desenvolvimento de várias formas, incluindo:


Orientar a Equipe de Desenvolvimento na sua auto organização e trans-funcionalidade,

Ensinar ou liderar a Equipe de Desenvolvimento para criar um produto de alto valor,

Remover impedimentos para o progresso da equipe de desenvolvimento,

Facilitar os eventos do Scrum quando solicitado ou necessário,

Orientar a Equipe de Desenvolvimento no ambiente organizacional no qual o Scrum ainda não é

amplamente adotado e compreendido.

Os serviços do Scrum Master para a Organização O Scrum Master serve a organização de várias formas, incluindo:

Liderar e Orientar a organização na adoção do Scrum,

Planejar as implementações do Scrum dentro da organização,

Ajudar empregados e stakeholders a entender e implantar o Scrum e o desenvolvimento

empírico de produtos,

Provocar mudanças que aumentem a produtividade na Equipe de Scrum,

Trabalhar com outros Scrum Masters para aumentar a efetividade da aplicação do Scrum na

organização.

Eventos do Scrum Eventos prescritos são usados no Scrum para criar uma rotina e para minimizar a necessidade de

encontros não definidos no Scrum. O Scrum usa eventos time-boxed3, onde cada evento tem uma

duração máxima. Isso garante uma quantidade apropriada de tempo gasto em planejamento sem

permitir perdas no processo de planejamento.

Além da própria Sprint, que é um container para outros eventos, cada evento no Scrum é uma

oportunidade para inspecionar e adaptar algo. Estes eventos são projetados especificamente para

permitir uma transparência crítica e inspeção. Não incluir qualquer destes eventos é reduzir a

transparência e perder a oportunidade para inspecionar e adaptar.

O Sprint O coração do Scrum é o Sprint, um time-box de um mês ou menos durante o qual uma versão

potencialmente utilizável de um incremento do produto é criada. Sprints tem durações consistentes ao

longo do esforço de desenvolvimento. Um novo Sprint começa imediatamente depois da conclusão do

Sprint anterior.

Sprints consistem em uma reunião de planejamento do Sprint, Scrums Diários, o trabalho de

desenvolvimento, a reunião de revisão do Sprint e a Retrospectiva do Sprint.

Durante o Sprint:

Nenhuma mudança deve ser feita que afete o objetivo do Sprint,

3 N.T. Time-boxed foi deixado em inglês por que reflete mais precisamente o conceito do Sprint no Scrum de ter

um prazo fixo (intervalo de tempo fixo).


A composição da equipe de desenvolvimento e a qualidade dos objetivos se mantêm

constantes,

O escopo pode ser esclarecido e renegociado entre o Dono do produto e a equipe de

desenvolvimento quando for aprendido mais.

Cada Sprint pode ser considerado um projeto com um horizonte que não pode ser maior do que um

mês. Como projetos, Sprints são usados para se conquistar algo. Cada Sprint possui uma definição do

que deve ser construído, um projeto e um plano flexível que vai guiar a construção o trabalho e o

produto resultante.

Sprints são limitados a um mês corrido. Quando o horizonte do Sprint é muito longe a definição do que

será construído pode mudar, complexidade pode aumentar e o risco pode se elevar. Sprints permitem

a previsibilidade garantindo inspeção e adaptação do progresso na direção de um objetivo pelo menos

a cada mês. Sprints também limitam o risco ao custo de um mês.

Cancelando um Sprint. Um Sprint pode ser cancelado antes cde o seu prazo ter se esgotado. Somente o Dono do produto tem

a autoridade para cancelar o Sprint, apesar de que ele (ou ela) pode fazer isso sob a influência dos

stakeholders, da equipe de Desenvolvimento ou do Scrum máster.

Um Sprint será cancelado se o Objetivo do Sprint se tornar obsoleto. Isso pode ocorrer se empresa

mudar a direção ou se as condições de mercado ou tecnologia mudarem. Em geral, um Sprint deve ser

cancelado se ele não fizer mais sentido às dadas circunstâncias. Mas, dada a curta duração do Sprint, o

cancelamento raramente faz sentido.

Quando um Sprint é cancelado,, qualquer dos itens do Backlog do Produto que estiver completado e

“Pronto” é revisado. Se uma parte do trabalho estiver potencialmente entregável, o Dono do produto

[tipicamente], o aceita. Todo o trabalho incompleto do Backlog do Produto são re-estimados e

colocados novamente no Backlog do Produto. O trabalho Pronto nele deprecia rapidamente e deve ser

constantemente re-estimado.

O cancelamento de Sprints consome recursos, desde que todos devem se reagrupar em outra reunião

de planejamento de Spring para iniciar outro Sprint. O cancelamento de Sprints é sempre traumático

para a Equipe de Scrum, e é muito incomum.

Reunião de Planejamento do Sprint O trabalho a ser executado no Sprint é planejado na Reunião de Planejamento do Sprint. Este plano é

criado pelo trabalho colaborativo de toda a equipe do Scrum.

A reunião de planejamento do Sprint é fixa em oito horas para um Sprint de um mês. Para Sprints mais

curtos, o evento é proporcionalmente menor. Por exemplo, Sprints de duas semanas, tem Reunião de

Planejamento do Sprint de quatro horas.

A Reunião de Planejamento do Sprint é dividida em duas partes, cada uma tendo a metade do tempo

fixo, dedicado à reunião de planejamento do Sprint. As duas partes da Reunião de Planejamento do

Sprint respondem às seguintes questões, respectivamente:


O que vai ser entregue como resultado do Incremento do próximo Sprint?

Como será realizado o trabalho necessário para entregar o Incremento?

Parte 1: O que será Pronto neste Sprint? Nesta parte, a Equipe de Desenvolvimento trabalhar para prever a funcionalidade que será

desenvolvida durante o Sprint. O Dono do Produto apresenta os itens do Backlog do produto

ordenado para a Equipe de Desenvolvimento e toda a Equipe do Scrum colabora no entendimento do

trabalho do Sprint.

Como dado de entrada para a reunião temos o Backlog do Produto, o último Incremento do produto, a

capacidade projetada da Equipe de Desenvolvimento durante o Sprint e o desempenho passado da

Equipe de desenvolvimento. Somente a equipe de desenvolvimento pode avaliar o que poderá

conseguir fazer no próximo Sprint.

Depois da previsão da Equipe de Desenvolvimento dos itens do Backlog do Produto que serão

entregues por este Sprint, a equipe de Scrum produz o Objetivo do Sprint. O Objetivo do Sprint é um

objetivo que será atingido pelo Sprint por meio da implementação do Backlog do Produto, e oferece

uma orientação para a Equipe de desenvolvimento sobre a construção do Incremento.

Parte 2: Como o trabalho escolhido será Pronto? Tendo selecionado o trabalho do Sprint, a equipe de desenvolvimento decide como ela irá transformar

esta funcionalidade em Incrementos “Prontos” durante o Sprint. Os itens selecionados do Backlog do

Produto para este Sprint somado ao plano para entregá-los é chamados de Backlog do Sprint.

A equipe de desenvolvimento usualmente inicia desenhando o sistema e o trabalho que precisa ser

convertido de um Backlog do produto ao incremento executável do produto. O trabalho pode variar de

tamanho, ou estimativa de esforço. Entretanto, o trabalho suficiente é planejado durante a Reunião de

Planejamento do Sprint pela Equipe de Desenvolvimento para prever o que ela acredita possa fazer no

Sprint seguinte. O Trabalho planejado para os primeiro dias é decomposto em unidades de um dia ou

menos até o final da reunião. A equipe de Desenvolvimento se auto organiza para realizar o trabalho

no Backlog do Sprint, tanto durante a Reunião de Planejamento do Sprint e quando for necessário ao

longo do Sprint.

O Dono do Produto pode estar presente durante a segunda parte da Reunião de Planejamento do

Sprint para esclarecer itens selecionados do Backlog do Produto e para ajudar a realizar os

compromissos. Se a Equipe de Desenvolvimento determina que tenha demasiado trabalho ou que tem

pouco trabalho, ela pode renegociar itens do Backlog do Sprint com o Dono do Produto. A Equipe de

Desenvolvimento pode também convidar outras pessoas para participar da reunião, oferecendo

aconselhamento técnico ou do domínio.

No final da reunião de planejamento do Sprint, a Equipe de Desenvolvimento deve estar apta a

explicar ao Dono do Produto e ao Scrum Master como pretende trabalhar como uma equipe auto

organizada para conseguir criar o Incremento desejado e atingir o Objetivo do Sprint.

Objetivo do Sprint O objetivo do Sprint dá alguma flexibilidade à equipe de desenvolvimento sobre as funcionalidades a

serem implementadas no Sprint.


Com o andamento do trabalho da Equipe de Desenvolvimento, ela mantém em mente o objetivo. De

modo a atender ao objetivo do Sprint, ela implementa a funcionalidade e a tecnologia. Se o trabalho

se torna diferente do que o que a Equipe de Desenvolvimento esperava, ela pode colaborar com o

Dono do produto para negociar o escopo do Backlog do Sprint dentro do Sprint.

O objetivo do Sprint pode ser um marco dentro do propósito maior no mapa do produto.

Scrum Diário A Reunião do Scrum Diário é um evento com 15 minutos fixos para a Equipe de Desenvolvimento

sincronizar as atividades e criar um plano para as próximas 24 horas. Isso se faz inspecionando o

trabalho até o último Scrum Diário e prevendo o trabalho que pode ser Pronto antes do próximo.

O Scrum diário se dá no mesmo horário e lugar todo o dia para reduzir a complexidade. Durante o

encontro, cada membro da Equipe de Desenvolvimento esclarece:

O que tem conseguido realizar desde o último encontro?

O que vai ser Pronto até o próximo encontro?

Quais são os obstáculos que estão no seu caminho?

A Equipe de Desenvolvimento usa o Scrum Diário para avaliar o progresso na direção do Objetivo do

Sprint e para avaliar se o progresso tende para completar o trabalho no Backlog do Sprint. O Scrum

Diário aumenta a probabilidade da Equipe de Desenvolvimento atingir o Objetivo do Sprint. A Equipe

de Desenvolvimento em geral, se encontra imediatamente depois do Scrum Diário para replanejar o

restante do trabalho do Sprint. Todo dia, a Equipe de Desenvolvimento deve estar apta a explicar para

o Dono do Produto e para o Scrum Master como pretende trabalhar em conjunto, como uma equipe

auto organizada para atingir o objetivo e criar o incremento desejado no restante do Sprint.

O Scrum Master garante que a equipe de desenvolvimento tem o encontro, mas a Equipe de

Desenvolvimento é responsável por conduzir o Scrum Diário. O Scrum Master ensina a Equipe de

Desenvolvimento a manter o Scrum Diário dentro do limite de tempo de 15 minutos.

O Scrum Master aplica a regra que somente os membros da Equipe de Desenvolvimento participem do

Scrum Diário. O Scrum Diário não é uma reunião de status, e é voltada para as pessoas que

transformam os itens do Backlog em um Incremento.

Os Scrums Diários melhoram a comunicação, eliminam outras reuniões, identificam e removem os

impedimentos para o desenvolvimento, destacam e promovem uma tomada de decisão rápida, e

melhoram o nível do conhecimento do projeto da Equipe de Desenvolvimento. Esta é a reunião chave

para inspeção e adaptação.

Revisão do Sprint A Reunião de Revisão do Sprint é executada no final do Sprint para inspecionar o Incremento e adaptar

ao Backlog do Produto se necessário. Durante a Revisão do Sprint, a Equipe de Scrum e stakeholders

colaboram sobre o que foi Pronto no Sprint. Baseado nisso e em qualquer mudança no Backlog do

Produto durante o Sprint, os presentes colaboram nas próximas coisas que precisam ser feitas. Está é


uma reunião informal, e a apresentação do Incremento tem como intenção motivar uma

realimentação e incentivar a colaboração.

Esta é uma reunião de time-box de 4 horas para um Sprint de um mês. Proporcionalmente menos

tempo é alocado para Sprints mais curtos. Por exemplo, Sprints de duas semanas vão ter Revisões de

Sprint de duas horas.

A Revisão do Sprint inclui os seguintes elementos:

O Dono do produto identifica que foi “Pronto” e o que não foi “Pronto”.

A Equipe de Desenvolvimento discute que foi bem durante o Sprint, quais problemas ocorreram

e como estes problemas foram resolvidos;

A Equipe de Desenvolvimento demonstra o trabalho que foi “Pronto” e responde as perguntas

sobre o incremento;

O Dono do Produto discute o Backlog do Produto. Ele projeta a data mais provável de término

baseado no progresso até o momento; e,

Todo o grupo colabora no que deve ser Pronto em seguida assim, a Revisão do Spring fornece

um entrada valiosa para as próximas reuniões de Planejamento do Sprint.

O resultado da revisão do Sprint é um Backlog do Produto revisado que define os prováveis itens do

Backlog do Produto para a próxima Sprint. O Backlog do produto pode ser ajustado como um todo

para atender novas oportunidades.

A Retrospectiva do Sprint. A retrospectiva do Sprint é uma oportunidade para a Equipe do Scrum inspecionar-se a si mesma e

criar um plano de melhorias que deve ser valer durante o próximo Sprint.

A Retrospectiva do Sprint ocorre depois da Revisão do Sprint e antes da Próxima reunião de

planejamento do Sprint. Esta é uma reunião marcada para com um time-box de 3 horas para um mês

de Sprints. Proporcionalmente um tempo menor é alocado para Sprints menores.

O propósito da Retrospectiva do Sprint é:

Inspecionar como foi o último Sprint no que diz respeito a pessoas, relações, processos e

ferramentas,

Identificar e ordenar os principais itens que foram bem e as potenciais melhorias,

Criar um plano para programar melhorias no modo de como a Equipe de Scrum trabalha.

O Scrum máster encoraja a Equipe de Scrum para melhorar, dentro do framework de processo do

Scrum, o processo de desenvolvimento e as práticas para fazê-lo mais efetivo e agradável para o

próximo Sprint. Durante cada Retrospectiva do Sprint, a Equipe de Scrum planeja modos para

aumentar a qualidade do produto adaptando a definição de “pronto” quando apropriado.

No final da retrospectiva do Sprint, a equipe de Scrum deve identificar melhorias que serão aplicadas

no próximo Sprint. Implementar estas melhorias no próximo Sprint é adaptar a inspeção na própria


Equipe do Scrum. Apesar de que melhorias podem ser adotadas a qualquer momento, a Retrospectiva

do Sprint oferece um evento dedicado focado na inspeção e adaptação.

Artefatos de Scrum

Os artefatos do Scrum representam o trabalho ou valor de várias formas que são úteis de oferecer

transparências e oportunidades para inspeção e adaptação. Os artefatos definidos no Scrum são

especialmente projetados para maximizar a transparência e a informação chave necessários para

garantir que as equipes do Scrum sejam bem sucedidas ao entregar o Incremento “Pronto”.

Backlog do produto O Backlog do produto é uma lista ordenada de tudo o que pode ser necessário no produto e é a fonte

única dos requisitos para qualquer mudança a ser feita no produto. O Dono do Produto é responsável

para o Backlog do Produto, incluindo o seu conteúdo, disponibilidade e ordenação.

Um Backlog do produto nunca está completo. A versão inicial dele apenas descreve o que foi

conhecido no início e os requisitos mais bem conhecidos. O Backlog do produto evolui ao mesmo

tempo em que o produto e o ambiente no qual ele será usado evolui. O Backlog do Produto é

dinâmico; ele muda constantemente para identificar o que o produto precisa para ser útil, apropriado

e competitivo. Enquanto um produto existir, um Backlog do Produto deve existir.

O Backlog do Produto lista todas as funcionalidades, funções, requisitos, melhorias e consertos que

representam as mudanças a serem feitas no produto para as próximas versões. Os itens do Backlog do

Produto tem os atributos de descrição, ordem e estimativa.

O Backlog do produto é, geralmente, ordenado por valor, risco, prioridade e necessidade. Os itens

mais altos do Backlog do Produto determinam atividades de desenvolvimento mais imediatas. Quanto

mais alto a ordem do item, mais o item do Backlog do Produto deve ser considerado, e mais consenso

existe a respeito deste valor.

Itens do Backlog do produto de ordem mais alta devem ser mais claros e serem mais detalhados que

os de ordem inferior. Estimativas mais precisas são feitas com base na maior clareza e aumento de

detalhes; quanto mais baixa a ordem, menos detalhes. Os itens do Backlog do Produto que vão ocupar

a equipe de desenvolvimento no próximo Sprint são bem refinados, tendo sido decompostos para que

todos os itens possam ficar “Prontos” dentro dos limites do Time-box do Sprint. Os itens do Backlog do

Produto que podem ficar “Prontos” pela Equipe de Desenvolvimento dentro de um Sprint são

marcados como “disponíveis” ou “executáveis” para seleção na reunião de Planejamento do Sprint.

Enquanto um produto é usado, e ganha valor, e o mercado oferece uma realimentação, o Backlog do

Produto se torna uma lista longa e mais completa. Requisitos nunca param de mudar, assim o Backlog

do produto é um artefato vivo. Mudanças nos requisitos do negócio, condições de mercado ou

tecnologia podem provocar mudanças no Backlog do produto.

Múltiplas Equipes de Scrum frequentemente trabalham juntas no mesmo produto. Um Backlog do

Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog o Produto

que agrupa os itens é aplicado.


A preparação do Backlog do produto é o ato de adicionar detalhes, estimativas e ordenar os itens no

Backlog do produto. Este é um processo contínuo no qual o Dono do Produto e a Equipe de

Desenvolvimento colaboram nos detalhes dos itens do Backlog do produto. Durante a preparação do

Backlog do Produto, os itens são analisados e revisados. Entretanto, eles podem ser atualizados a

qualquer momento pelo Dono do Produto ou escolha do Dono do Produto.

Preparação é uma atividade em tempo parcial durante um Spring entre o Dono do Produto e da

Equipe de Desenvolvimento. Frequentemente as equipes de Desenvolvimento devem preparar o

próprio domínio do conhecimento. Como e quando a preparação é feita é decidida pela Equipe do

Scrum. Preparação usualmente consome não mais do que 10% da capacidade da Equipe de

Desenvolvimento.

A equipe de desenvolvimento é responsável por todas as estimativas. O Dono do produto pode

influenciar a equipe ajudando a entender e selecionar os compromissos, mas as pessoas que vão

realizar o trabalho é quem deve fazer a estimativa final.

Monitorando o Progresso na direção de um Objetivo Em qualquer momento no tempo, o trabalho total restante para se atingir um objetivo pode ser

sumarizado. O Dono do Produto acompanha o trabalho total restante pelo menos em cada Revisão do

Sprint. O Dono do Produto compara o total de trabalho faltante na revisão anterior do Sprint para

avaliar o progresso na direção de completar o trabalho projetado pelo tempo estimado para o

objetivo. Esta informação se torna transparente para todos os stakeholders.

O Scrum não consideram o tempo gasto no trabalho com os Itens do Backlog do produto. O trabalho

restante e as datas são as únicas variáveis de interesse.

Várias práticas como burndown, burnup e outras práticas de estimativa tem sido usadas para prever o

progresso. Elas tem se provado úteis. Entretanto, Elas não substituem a importância do empirismo. Em

ambientes complexos, o que vai acontecer é desconhecido. Somente o que aconteceu pode ser usado

para uma tomada de decisão do que vai vir.

Backlog do Sprint O Backlog do Sprint é um conjunto de itens do Backlog do produto selecionados para o Sprint além de

um plano para obter o incremento do produto e atingir o objetivo do Sprint. O Backlog do Sprint é uma

previsão da Equipe de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e do

trabalho necessário para entregar esta funcionalidade.

O Backlog do Sprint define o trabalho que a Equipe de Desenvolvimento irá desempenhar para

transformar os itens do Backlog do produto em Incrementos “Prontos”. O Backlog do Sprint torna

visível todo o trabalho que a Equipe de Desenvolvimento identifica como necessário para atingir o

Objetivo do Sprint.

O Backlog do Sprint é um plano com detalhes suficiente que as mudanças em progresso sejam

entendidas no Scrum Diário. A Equipe de Desenvolvimento modifica o Backlog do Sprint ao longo do

Sprint, e o Backlog do Sprint surge durante o Sprint. Este surgimento ocorre quando a Equipe de

Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para atingir o

objetivo do Sprint.


Se um novo trabalho for necessário, A Equipe de Desenvolvimento o adiciona ao Backlog do Sprint. Na

medida em que o trabalho é desempenhado e completado, a estimativa do trabalho restante é

atualizada. Quando elementos do plano se mostrarem desnecessários, eles são removidos. Somente a

Equipe de Desenvolvimento pode alterar o Backlog do Sprint durante o Sprint. O Backlog do Sprint é

uma figura em tempo real, altamente visível, do trabalho que a Equipe de Desenvolvimento planeja

atingir durante o Sprint, e pertence somente à Equipe de desenvolvimento.

Monitoramento do Progresso do Sprint A qualquer instante do tempo de um Sprint, o trabalho total restante nos itens do Backlog do Sprint

pode ser sumarizado. A Equipe de desenvolvimento acompanha este total de trabalho restante pelo

menos todo Scrum Diário. A Equipe de Desenvolvimento acompanha estes totais diários e projeta a

que mais provavelmente vai alcançar o Objetivo do Sprint. Por rastrear o trabalho restante pelo Sprint,

a Equipe de Desenvolvimento pode gerenciar o seu progresso.

O Scrum não considera o tempo gasto nos itens do Backlog do Sprint. O trabalho restante e as datas

são as únicas variáveis de interesse.

Incremento O incremento é a soma de todos os itens do Backlog do produto completados por um Sprint e por

todos os Sprints anteriores. No final de um Sprint, o novo Incremento deve estar “Pronto”, o que

significa que ele está em uma condição utilizável e atende à definição da Equipe do Scrum do “Pronto”.

Ele deve estar em uma condição utilizável independente da decisão do Dono do Produto decidir

realmente liberá-lo.

Definição do “Pronto” Quando um item do Backlog do Produto ou um Incremento é descrito como “Pronto”, todos devem

entender o que “Pronto” significa. Apesar de que isso pode variar significativamente para cada Equipe

de Scrum, os membros devem ter um entendimento compartilhado do que significa que o trabalho

estar completo, para garantir transparência. Esta é a “definição de “Pronto”” para a equipe do Scrum e

é usado para avaliar quando o trabalho está completo no Incremento do Produto.

A mesma definição orienta a Equipe de Desenvolvimento em saber quantos itens do Backlog do

produto ela pode selecionar durante a Reunião de Planejamento do Sprint. O propósito de cada Sprint

é entregar Incrementos de funcionalidades potencialmente utilizáveis que atende à definição atual da

equipe de Desenvolvimento para “Pronto”.

A Equipe de Desenvolvimento entrega um Incremento da funcionalidade do Produto a cada Sprint.

Este Incremento é usável, assim o Dono do produto pode decidir liberá-lo imediatamente. Cada

Incremento é adicionável ao todos os Incrementos anteriores e por meio de testes, garantir que too o

incremento trabalha em conjunto.

Na medida de que a equipe de Scrum fica madura, se espera que a definição de “Pronto” expanda para

incluir critérios mais rigorosos de maior qualidade.


Conclusão O Scrum é livre e proposto neste guia. Os papeis, artefatos, eventos e regras do Scrum são imutáveis e

apesar de que implementação apenas de partes do Scrum é possível, o resultado não é um Scrum. O

Scrum existe somente na sua totalidade e funciona bem como um container para outras técnicas,

metodologias e práticas.


Agradecimentos Pessoas

Das milhares de pessoas que tem contribuído para o Scrum, nós gostaríamos de destacar aqueles que

foram essenciais nos seus primeiros anos. Inicialmente a Jeff Sutherland, trabalhando com Jeff

McKenna e Ken Schwaber, trabalhando com Mike Smith e Chris Martin. Muitos outros contribuiram

nos anos seguintes e sem a sua ajuda, o Scrum não seria refinado como é hoje. David Starr ofereceu

insights chave e habilidades editoriais na formulação desta versão do Guia do Scrum.

História

Ken Schwaber e Jeff Sutherland co-apresentaram inicialmente na conferencia OOPSLA em 1XXX. Esta

apresentação essencialmente documentou o aprendizado de Ken e Jeff nos anos que antecederam a

aplicação do Scrum. A história do Scrum já é considerada longa. Para honrar os primeiros lugares onde

ele foi tentado e refinado, nós reconhecemos a Individual, Inc., Fidelity Investments e IDX (hoje GE

Medical).


Revisões

O Guia do Scrum de Julho de 2011 é diferente do seu predecessor, o Guia de Fevereiro de 2010. Em

particular, nós tentamos remover técnicas e boas práticas do núcleo do Scrum. Elas podem variar

baseado nas circunstâncias. Nós vamos começar um compêndio de boas práticas para prover um

pouco da nossa experiência recente.

O Guia do Scrum documenta o Scrum enquanto ele se desenvolve e se mantém por mais de vinte

anos por Jeff Sutherland e Ken Schwaber. Outras fontes provêm padrões, processos e visões sobre

como as práticas, facilitadores e ferramentas complementam o framework do Scrum. Isto aperfeiçoa a

produtividade, valor, criatividade e orgulho.

Notas emitidas cobrindo as seguintes diferenças entre este guia e a versão de 2010 serão publicadas

em outros lugares, incluindo discussões sobre:

1. Planejamento de Release.

2. Burndown do Release.

3. Backlog do Sprint.

4. Burndown do Product e Backlog do Sprint Backlog.

5. Compromisso agora é previsão.

6. Equipe (para Equipe de Desenvolvimento).

7. Porcos e Galinhas … o conto do Scrum.

8. Ordenados no lugar de priorizados.

Documents

O Guia do Scrum - EduardoDebonieduardodeboni.com/download/Scrum_Guide_2011_PTBR.pdf · O Guia do Scrum O Guia definitivo para o Scrum As regras do jogo Julho 2011 Desenvolvido e Mantido