Você está na página 1de 17

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 Portugus por Jos Eduardo Deboni (eduardodeboni.com)

Contedo
Propsito do Guia do Scrum ........................................................................................................................ 3 Viso Geral do Scrum ................................................................................................................................... 3 Framework Scrum ........................................................................................................................................ 3 A Teoria do Scrum ........................................................................................................................................ 3 Transparncia .............................................................................................................................................. 3 Inspeo ....................................................................................................................................................... 4 Adaptao .................................................................................................................................................... 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 servios do Scrum Master para o Dono do Produto ............................................................................... 6 Os servios do Scrum Master para a Equipe de Desenvolvimento .............................................................. 6 Os servios do Scrum Master para a Organizao ....................................................................................... 7 Eventos do Scrum ........................................................................................................................................ 7 O Sprint ........................................................................................................................................................ 7 Cancelando um Sprint. ................................................................................................................................. 8 Reunio 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 Dirio............................................................................................................................................... 10 Reviso do Sprint ....................................................................................................................................... 10 A Retrospectiva do Sprint. ......................................................................................................................... 11 Backlog do produto .................................................................................................................................... 12 Monitorando o Progresso na direo de um Objetivo .............................................................................. 13 Backlog do Sprint ....................................................................................................................................... 13 Monitoramento do Progresso do Sprint .................................................................................................... 14 Incremento ................................................................................................................................................ 14 Definio do Pronto ................................................................................................................................ 14 Concluso ................................................................................................................................................... 15 Agradecimentos ......................................................................................................................................... 16

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 2

Propsito do Guia do Scrum


Scrum um framework para desenvolver e manter produtos complexos. Este Guia contm a definio do Scrum. Esta definio consiste em papeis, eventos, artefatos do Scrum e as regras que mantm 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.

Viso 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 possvel. O Scrum : Leve De entendimento simples Extremamente difcil de ter o domnio

O Scrum um framework de processo quem tem sido usado para gerenciar o desenvolvimento de produtos complexos desde o incio dos anos 90. Scrum no um processo ou tcnica para construir produtos, mais um framework dentro do qual se pode empregar processos e tcnicas variadas. O Scrum torna clara a eficcia relativa das prticas de gerenciamento e desenvolvimento de produtos, para que voc possa melhor-las.

Framework Scrum
O framework Scrum consiste nas equipes do Scrum, papis, eventos, artefatos e regras associados. Cada componente do framework serve a um propsito especfico e essencial para o sucesso e uso do Scrum. Estratgias especficas para uso do framework Scrum variam e so descritas em outros documentos. As regras do Scrum integram os eventos, papis e artefatos, governando as relaes e interaes entre eles. As regras do Scrum so descritas ao longo do corpo deste documento.

A Teoria do Scrum
O Scrum est baseado nas teorias empricas de controle de processo. O empirismo afirma que o conhecimento vem da experincia e tomar decises baseados no que se conhece. O Scrum aplica uma abordagem iterativa e incremental para aperfeioar a previsibilidade e o controle de riscos. Trs pilares sustentam a implementao de um controle de processo emprico: transparncia, inspeo e adaptao.

Transparncia
Aspectos significativos do processo devem estar visveis para os responsveis pelos resultados. Transparncia requer que aqueles aspectos sejam definidos por um padro comum para que os observadores compartilhem um entendimento comum do que est sendo visto.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 3

Por exemplo: Uma linguagem comum para se referir ao processo, deve ser compartilhada por todos os participantes, Uma definio comum de Pronto1 deve ser compartilhada por aqueles que desempenham o trabalho e aqueles que do o aceite do produto do trabalho.

Inspeo
Os usurios do Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso com objetivo de detectar variaes no desejadas. Esta inspeo no deve ser to frequente, que a inspeo fique no caminho do trabalho. As Inspees so mais benficas quando desempenhadas por inspetores habilidosos [diligentes] no local do trabalho.

Adaptao
Se um inspetor determina que um ou mais aspectos do processo desviar para longe de limites aceitveis, e que o resultado do produto no aceitvel, o processo ou o material que est sendo processado deve ser ajustado. Um ajuste deve ser feito to logo quanto possvel para minimizar os desvios futuros. O Scrum prescreve quatro oportunidades formais para inspeo e adaptao, como descritas na seo de Eventos do Scrum deste documento: Reunio de Planejamento do Sprint Scrum Dirio Reunio de Reviso 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 papis, eventos, artefatos e regras associadas. Cada componente no framework serve para um propsito especfico e essencial para o uso e sucesso do Scrum. As regras do Scrum integram os eventos, papeis e artefatos, governando as relaes e interaes entre eles. As regras do Scrum so 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 so auto organizadas e trans-funcionais. Equipes auto organizadas escolhem a melhor forma de realizar seu trabalho, ao contrrio de serem dirigidas por outros de fora da equipe. Equipes trans-funcionais tem todas as competncias necessrias para realizar o trabalho sem a dependncia de outras que no fazem parte da equipe. A equipe modelo no Scrum projetada para aperfeioar a flexibilidade, criatividade e produtividade.
1

Veja a definio na pgina 15.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 4

As equipes do Scrum produzem iterativamente e incrementalmente, aproveitando ao mximo as oportunidades para realimentao. Entregas incrementais de produtos Prontos garantem que uma verso potencialmente til do produto esteja sempre disponvel.

O Dono do produto
O Dono do produto2 responsvel por maximizar o valor do produto e do trabalho da equipe de desenvolvimento. Como isso feito pode variar amplamente entre organizaes, equipes de Scrum e indivduos. O Dono do produto a nica pessoa responsvel 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 alcanar os objetivos e misses; Garantir o valor do trabalho desempenhado pela equipe de desenvolvimento; Garantir que o Backlog do produto seja visvel, 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 nvel necessrio.

O Dono do produto pode fazer o trabalho acima, ou deixar que a equipe de projeto o faa. Entretanto, o Dono do produto o responsvel por ele. O Dono do produto uma pessoa, e no 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 organizao deve respeitar a sua deciso. As decises do Dono do produto esto visveis no contedo e na organizao do backlog do produto. Ningum est autorizado a mandar a equipe de desenvolvimento trabalhar em um conjunto diferente de requisitos e a equipe de desenvolvimento no 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 verso usvel que potencialmente incrementa o produto Pronto no final de cada Sprint. Somente membros da equipe de desenvolvimento criam o incremento. As equipes de desenvolvimento so estruturadas e autorizadasligei pela organizao para organizar e gerenciar seu prprio trabalho. A sinergia resultante aperfeioa a eficincia e efetividade global. As equipes de desenvolvimento tm as seguintes caractersticas: Elas so auto organizadas. Ningum (nem mesmo o Scrum Master) diz para a equipe de projetos como transformar o Backlog de produto em incrementos de funcionalidades potencialmente utilizveis;

Nota do Tradutor: O termo em ingls Product Owner e foi traduzido aqui como Dono do Produto, em letra maiscula, para indicar que um papel representado no processo do Scrum e no aquele que seria o proprietrio do produto de software.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 5

Equipes de desenvolvimento so trans funcionais, com todas as habilidades necessrias para criar o incremento do produto. O Scrum no reconhece perfis dos membros da equipe de desenvolvimento alm de Desenvolvedor, independente do trabalho que est sendo realizado pela pessoa, no h excees a essa regra; Individualmente os membros da equipe de desenvolvimento podem ter habilidades especializadas e reas de especializao, mas pertencem e respondem equipe de desenvolvimento como um todo; e, Equipes de desenvolvimento no possuem sub-equipes dedicadas a domnios particulares do conhecimento, como teste ou anlise de negcio.

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 trs membros em uma equipe de desenvolvimento diminui a interao e resulta em ganhos menores de produtividade. Equipes pequenas podem encontrar limitaes nas habilidades necessrias para um Sprint, e como consequncia no conseguindo entregar um incremento potencialmente utilizvel. Tendo mais do que nove membros se requer muita coordenao. Equipes de desenvolvimento grandes geram muita complexidade para um processo emprico gerenciar. Os papeis de Dono do produto e o Scrum Master no so includos nesta contagem a no ser que eles tambm executem o trabalho do Sprint Backlog.

O Scrum Master
O Scrum Master responsvel para garantir que o Scrum seja entendido e aplicado. Os Scrum Masters fazem isso garantindo que as equipes de Scrum obedeam teoria, prticas e regras do Scrum. O Scrum Master um lder-facilitador para a equipe do Scrum. O Scrum Master ajuda aqueles de fora da equipe do Scrum entender quais so as interaes com a equipe do Scrum que so benficas e quais no so. O Scrum Master ajudar todos a mudar suas interaes para maximizar o valor criado pela equipe de Scrum.

Os servios do Scrum Master para o Dono do Produto


O Scrum Master serve ao Dono do produto de vrias formas, incluindo: Encontrar tcnicas para o gerenciamento efetivo do Backlog do produto, Comunicar claramente a viso, 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 emprico, Entender e praticar a agilidade, Facilitar os eventos do Scrum quando solicitado ou necessrio.

Os servios do Scrum Master para a Equipe de Desenvolvimento


O Scrum Master serve a Equipe de Desenvolvimento de vrias formas, incluindo:

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 6

Orientar a Equipe de Desenvolvimento na sua auto organizao 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 necessrio, Orientar a Equipe de Desenvolvimento no ambiente organizacional no qual o Scrum ainda no amplamente adotado e compreendido.

Os servios do Scrum Master para a Organizao


O Scrum Master serve a organizao de vrias formas, incluindo: Liderar e Orientar a organizao na adoo do Scrum, Planejar as implementaes do Scrum dentro da organizao, Ajudar empregados e stakeholders a entender e implantar o Scrum e o desenvolvimento emprico de produtos, Provocar mudanas que aumentem a produtividade na Equipe de Scrum, Trabalhar com outros Scrum Masters para aumentar a efetividade da aplicao do Scrum na organizao.

Eventos do Scrum
Eventos prescritos so usados no Scrum para criar uma rotina e para minimizar a necessidade de encontros no definidos no Scrum. O Scrum usa eventos time-boxed3, onde cada evento tem uma durao mxima. Isso garante uma quantidade apropriada de tempo gasto em planejamento sem permitir perdas no processo de planejamento. Alm da prpria Sprint, que um container para outros eventos, cada evento no Scrum uma oportunidade para inspecionar e adaptar algo. Estes eventos so projetados especificamente para permitir uma transparncia crtica e inspeo. No incluir qualquer destes eventos reduzir a transparncia e perder a oportunidade para inspecionar e adaptar.

O Sprint
O corao do Scrum o Sprint, um time-box de um ms ou menos durante o qual uma verso potencialmente utilizvel de um incremento do produto criada. Sprints tem duraes consistentes ao longo do esforo de desenvolvimento. Um novo Sprint comea imediatamente depois da concluso do Sprint anterior. Sprints consistem em uma reunio de planejamento do Sprint, Scrums Dirios, o trabalho de desenvolvimento, a reunio de reviso do Sprint e a Retrospectiva do Sprint. Durante o Sprint: Nenhuma mudana deve ser feita que afete o objetivo do Sprint,

N.T. Time-boxed foi deixado em ingls por que reflete mais precisamente o conceito do Sprint no Scrum de ter um prazo fixo (intervalo de tempo fixo).

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 7

A composio da equipe de desenvolvimento e a qualidade dos objetivos se mantm 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 no pode ser maior do que um ms. Como projetos, Sprints so usados para se conquistar algo. Cada Sprint possui uma definio do que deve ser construdo, um projeto e um plano flexvel que vai guiar a construo o trabalho e o produto resultante. Sprints so limitados a um ms corrido. Quando o horizonte do Sprint muito longe a definio do que ser construdo pode mudar, complexidade pode aumentar e o risco pode se elevar. Sprints permitem a previsibilidade garantindo inspeo e adaptao do progresso na direo de um objetivo pelo menos a cada ms. Sprints tambm limitam o risco ao custo de um ms.

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 influncia dos stakeholders, da equipe de Desenvolvimento ou do Scrum mster. Um Sprint ser cancelado se o Objetivo do Sprint se tornar obsoleto. Isso pode ocorrer se empresa mudar a direo ou se as condies de mercado ou tecnologia mudarem. Em geral, um Sprint deve ser cancelado se ele no fizer mais sentido s dadas circunstncias. Mas, dada a curta durao 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 entregvel, o Dono do produto [tipicamente], o aceita. Todo o trabalho incompleto do Backlog do Produto so 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 reunio de planejamento de Spring para iniciar outro Sprint. O cancelamento de Sprints sempre traumtico para a Equipe de Scrum, e muito incomum.

Reunio de Planejamento do Sprint


O trabalho a ser executado no Sprint planejado na Reunio de Planejamento do Sprint. Este plano criado pelo trabalho colaborativo de toda a equipe do Scrum. A reunio de planejamento do Sprint fixa em oito horas para um Sprint de um ms. Para Sprints mais curtos, o evento proporcionalmente menor. Por exemplo, Sprints de duas semanas, tem Reunio de Planejamento do Sprint de quatro horas. A Reunio de Planejamento do Sprint dividida em duas partes, cada uma tendo a metade do tempo fixo, dedicado reunio de planejamento do Sprint. As duas partes da Reunio de Planejamento do Sprint respondem s seguintes questes, respectivamente:

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 8

O que vai ser entregue como resultado do Incremento do prximo Sprint? Como ser realizado o trabalho necessrio 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 reunio 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 prximo Sprint. Depois da previso da Equipe de Desenvolvimento dos itens do Backlog do Produto que sero 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 implementao do Backlog do Produto, e oferece uma orientao para a Equipe de desenvolvimento sobre a construo 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 executvel do produto. O trabalho pode variar de tamanho, ou estimativa de esforo. Entretanto, o trabalho suficiente planejado durante a Reunio 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 reunio. A equipe de Desenvolvimento se auto organiza para realizar o trabalho no Backlog do Sprint, tanto durante a Reunio de Planejamento do Sprint e quando for necessrio ao longo do Sprint. O Dono do Produto pode estar presente durante a segunda parte da Reunio 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 tambm convidar outras pessoas para participar da reunio, oferecendo aconselhamento tcnico ou do domnio. No final da reunio 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.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 9

Com o andamento do trabalho da Equipe de Desenvolvimento, ela mantm 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 propsito maior no mapa do produto.

Scrum Dirio
A Reunio do Scrum Dirio um evento com 15 minutos fixos para a Equipe de Desenvolvimento sincronizar as atividades e criar um plano para as prximas 24 horas. Isso se faz inspecionando o trabalho at o ltimo Scrum Dirio e prevendo o trabalho que pode ser Pronto antes do prximo. O Scrum dirio se d no mesmo horrio 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 prximo encontro? Quais so os obstculos que esto no seu caminho?

A Equipe de Desenvolvimento usa o Scrum Dirio para avaliar o progresso na direo do Objetivo do Sprint e para avaliar se o progresso tende para completar o trabalho no Backlog do Sprint. O Scrum Dirio aumenta a probabilidade da Equipe de Desenvolvimento atingir o Objetivo do Sprint. A Equipe de Desenvolvimento em geral, se encontra imediatamente depois do Scrum Dirio 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 responsvel por conduzir o Scrum Dirio. O Scrum Master ensina a Equipe de Desenvolvimento a manter o Scrum Dirio 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 Dirio. O Scrum Dirio no uma reunio de status, e voltada para as pessoas que transformam os itens do Backlog em um Incremento. Os Scrums Dirios melhoram a comunicao, eliminam outras reunies, identificam e removem os impedimentos para o desenvolvimento, destacam e promovem uma tomada de deciso rpida, e melhoram o nvel do conhecimento do projeto da Equipe de Desenvolvimento. Esta a reunio chave para inspeo e adaptao.

Reviso do Sprint
A Reunio de Reviso do Sprint executada no final do Sprint para inspecionar o Incremento e adaptar ao Backlog do Produto se necessrio. Durante a Reviso do Sprint, a Equipe de Scrum e stakeholders colaboram sobre o que foi Pronto no Sprint. Baseado nisso e em qualquer mudana no Backlog do Produto durante o Sprint, os presentes colaboram nas prximas coisas que precisam ser feitas. Est

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 10

uma reunio informal, e a apresentao do Incremento tem como inteno motivar uma realimentao e incentivar a colaborao. Esta uma reunio de time-box de 4 horas para um Sprint de um ms. Proporcionalmente menos tempo alocado para Sprints mais curtos. Por exemplo, Sprints de duas semanas vo ter Revises de Sprint de duas horas. A Reviso do Sprint inclui os seguintes elementos: O Dono do produto identifica que foi Pronto e o que no 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 provvel de trmino baseado no progresso at o momento; e, Todo o grupo colabora no que deve ser Pronto em seguida assim, a Reviso do Spring fornece um entrada valiosa para as prximas reunies de Planejamento do Sprint.

O resultado da reviso do Sprint um Backlog do Produto revisado que define os provveis itens do Backlog do Produto para a prxima 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 prximo Sprint. A Retrospectiva do Sprint ocorre depois da Reviso do Sprint e antes da Prxima reunio de planejamento do Sprint. Esta uma reunio marcada para com um time-box de 3 horas para um ms de Sprints. Proporcionalmente um tempo menor alocado para Sprints menores. O propsito da Retrospectiva do Sprint : Inspecionar como foi o ltimo Sprint no que diz respeito a pessoas, relaes, 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 mster encoraja a Equipe de Scrum para melhorar, dentro do framework de processo do Scrum, o processo de desenvolvimento e as prticas para faz-lo mais efetivo e agradvel para o prximo Sprint. Durante cada Retrospectiva do Sprint, a Equipe de Scrum planeja modos para aumentar a qualidade do produto adaptando a definio de pronto quando apropriado. No final da retrospectiva do Sprint, a equipe de Scrum deve identificar melhorias que sero aplicadas no prximo Sprint. Implementar estas melhorias no prximo Sprint adaptar a inspeo na prpria

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 11

Equipe do Scrum. Apesar de que melhorias podem ser adotadas a qualquer momento, a Retrospectiva do Sprint oferece um evento dedicado focado na inspeo e adaptao.

Artefatos de Scrum
Os artefatos do Scrum representam o trabalho ou valor de vrias formas que so teis de oferecer transparncias e oportunidades para inspeo e adaptao. Os artefatos definidos no Scrum so especialmente projetados para maximizar a transparncia e a informao chave necessrios 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 necessrio no produto e a fonte nica dos requisitos para qualquer mudana a ser feita no produto. O Dono do Produto responsvel para o Backlog do Produto, incluindo o seu contedo, disponibilidade e ordenao. Um Backlog do produto nunca est completo. A verso inicial dele apenas descreve o que foi conhecido no incio 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 dinmico; 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, funes, requisitos, melhorias e consertos que representam as mudanas a serem feitas no produto para as prximas verses. Os itens do Backlog do Produto tem os atributos de descrio, 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 so feitas com base na maior clareza e aumento de detalhes; quanto mais baixa a ordem, menos detalhes. Os itens do Backlog do Produto que vo ocupar a equipe de desenvolvimento no prximo Sprint so 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 so marcados como disponveis ou executveis para seleo na reunio de Planejamento do Sprint. Enquanto um produto usado, e ganha valor, e o mercado oferece uma realimentao, 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. Mudanas nos requisitos do negcio, condies de mercado ou tecnologia podem provocar mudanas no Backlog do produto. Mltiplas 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.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 12

A preparao do Backlog do produto o ato de adicionar detalhes, estimativas e ordenar os itens no Backlog do produto. Este um processo contnuo no qual o Dono do Produto e a Equipe de Desenvolvimento colaboram nos detalhes dos itens do Backlog do produto. Durante a preparao do Backlog do Produto, os itens so analisados e revisados. Entretanto, eles podem ser atualizados a qualquer momento pelo Dono do Produto ou escolha do Dono do Produto. Preparao 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 prprio domnio do conhecimento. Como e quando a preparao feita decidida pela Equipe do Scrum. Preparao usualmente consome no mais do que 10% da capacidade da Equipe de Desenvolvimento. A equipe de desenvolvimento responsvel por todas as estimativas. O Dono do produto pode influenciar a equipe ajudando a entender e selecionar os compromissos, mas as pessoas que vo realizar o trabalho quem deve fazer a estimativa final.

Monitorando o Progresso na direo 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 Reviso do Sprint. O Dono do Produto compara o total de trabalho faltante na reviso anterior do Sprint para avaliar o progresso na direo de completar o trabalho projetado pelo tempo estimado para o objetivo. Esta informao se torna transparente para todos os stakeholders. O Scrum no consideram o tempo gasto no trabalho com os Itens do Backlog do produto. O trabalho restante e as datas so as nicas variveis de interesse. Vrias prticas como burndown, burnup e outras prticas de estimativa tem sido usadas para prever o progresso. Elas tem se provado teis. Entretanto, Elas no substituem a importncia do empirismo. Em ambientes complexos, o que vai acontecer desconhecido. Somente o que aconteceu pode ser usado para uma tomada de deciso do que vai vir.

Backlog do Sprint
O Backlog do Sprint um conjunto de itens do Backlog do produto selecionados para o Sprint alm de um plano para obter o incremento do produto e atingir o objetivo do Sprint. O Backlog do Sprint uma previso da Equipe de Desenvolvimento sobre qual funcionalidade estar no prximo incremento e do trabalho necessrio 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 visvel todo o trabalho que a Equipe de Desenvolvimento identifica como necessrio para atingir o Objetivo do Sprint. O Backlog do Sprint um plano com detalhes suficiente que as mudanas em progresso sejam entendidas no Scrum Dirio. 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 necessrio para atingir o objetivo do Sprint.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 13

Se um novo trabalho for necessrio, 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 desnecessrios, eles so 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 visvel, 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 Dirio. A Equipe de Desenvolvimento acompanha estes totais dirios e projeta a que mais provavelmente vai alcanar o Objetivo do Sprint. Por rastrear o trabalho restante pelo Sprint, a Equipe de Desenvolvimento pode gerenciar o seu progresso. O Scrum no considera o tempo gasto nos itens do Backlog do Sprint. O trabalho restante e as datas so as nicas variveis 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 condio utilizvel e atende definio da Equipe do Scrum do Pronto. Ele deve estar em uma condio utilizvel independente da deciso do Dono do Produto decidir realmente liber-lo.

Definio 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 transparncia. Esta a definio de Pronto para a equipe do Scrum e usado para avaliar quando o trabalho est completo no Incremento do Produto. A mesma definio orienta a Equipe de Desenvolvimento em saber quantos itens do Backlog do produto ela pode selecionar durante a Reunio de Planejamento do Sprint. O propsito de cada Sprint entregar Incrementos de funcionalidades potencialmente utilizveis que atende definio atual da equipe de Desenvolvimento para Pronto. A Equipe de Desenvolvimento entrega um Incremento da funcionalidade do Produto a cada Sprint. Este Incremento usvel, assim o Dono do produto pode decidir liber-lo imediatamente. Cada Incremento adicionvel 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 definio de Pronto expanda para incluir critrios mais rigorosos de maior qualidade.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 14

Concluso
O Scrum livre e proposto neste guia. Os papeis, artefatos, eventos e regras do Scrum so imutveis e apesar de que implementao apenas de partes do Scrum possvel, o resultado no um Scrum. O Scrum existe somente na sua totalidade e funciona bem como um container para outras tcnicas, metodologias e prticas.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 15

Agradecimentos
Pessoas Das milhares de pessoas que tem contribudo para o Scrum, ns gostaramos 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 no seria refinado como hoje. David Starr ofereceu insights chave e habilidades editoriais na formulao desta verso do Guia do Scrum. Histria Ken Schwaber e Jeff Sutherland co-apresentaram inicialmente na conferencia OOPSLA em 1XXX. Esta apresentao essencialmente documentou o aprendizado de Ken e Jeff nos anos que antecederam a aplicao do Scrum. A histria do Scrum j considerada longa. Para honrar os primeiros lugares onde ele foi tentado e refinado, ns reconhecemos a Individual, Inc., Fidelity Investments e IDX (hoje GE Medical).

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 16

Revises O Guia do Scrum de Julho de 2011 diferente do seu predecessor, o Guia de Fevereiro de 2010. Em particular, ns tentamos remover tcnicas e boas prticas do ncleo do Scrum. Elas podem variar baseado nas circunstncias. Ns vamos comear um compndio de boas prticas para prover um pouco da nossa experincia recente. O Guia do Scrum documenta o Scrum enquanto ele se desenvolve e se mantm por mais de vinte anos por Jeff Sutherland e Ken Schwaber. Outras fontes provm padres, processos e vises sobre como as prticas, facilitadores e ferramentas complementam o framework do Scrum. Isto aperfeioa a produtividade, valor, criatividade e orgulho. Notas emitidas cobrindo as seguintes diferenas entre este guia e a verso de 2010 sero publicadas em outros lugares, incluindo discusses 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 previso. 6. Equipe (para Equipe de Desenvolvimento). 7. Porcos e Galinhas o conto do Scrum. 8. Ordenados no lugar de priorizados.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos

Pag. 17