GUIA DO SCRUM

Por Ken Schwaber, Maio de 2009

GUIA DO SCRUM
Por Ken Schwaber, Maio de 2009

Traduo Heitor Roriz Filho Michel Goldenberg Rafael Sabbagh Reviso Anderson Marcondes nderson Quadros Ari do Amaral Torres Filho Marcos Garrido Rafael Fuchs Rafael Prikladnicki Rodrigo de Toledo Rafael Sabbagh (coordenao)

INTRODUO AO SCRUM
Scrum vem sendo utilizado para o desenvolvimento de produtos complexos desde o incio dos anos 90. Este guia descreve como usar o Scrum para desenvolver produtos. Scrum no um processo ou uma tcnica para o desenvolvimento de produtos. Ao invs disso, um framework dentro do qual voc pode empregar diversos processos e tcnicas. O papel do Scrum fazer transparecer a eficcia relativa das suas prticas de desenvolvimento para que voc possa melhor-las, enquanto prov um framework dentro do qual produtos complexos podem ser desenvolvidos.

TEORIA DO SCRUM
Scrum, que fundamentado na teoria de controle de processos empricos, emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Trs pilares sustentam qualquer implementao de controle de processos empricos.

O PRIMEIRO PILAR A TRANSPARNCIA

A transparncia garante que aspectos do processo que afetam o resultado devem ser visveis para aqueles que gerenciam os resultados. Esses aspectos no apenas devem ser transparentes, mas tambm o que est sendo visto deve ser conhecido. Isto , quando algum que inspeciona um processo acredita que algo est pronto, isso deve ser equivalente definio de pronto utilizada.

O SEGUNDO PILAR A INSPEO

Os diversos aspectos do processo devem ser inspecionados com uma frequncia suficiente para que variaes inaceitveis no processo possam ser detectadas. A frequncia da inspeo deve levar em considerao que qualquer

processo modificado pelo prprio ato da inspeo. O problema acontece quando a frequncia de inspeo necessria excede a tolerncia do processo inspeo. Os outros fatores so a habilidade e a aplicao das pessoas em inspecionar os resultados do trabalho.

O TERCEIRO PILAR A ADAPTAO

Se o inspetor determinar, a partir da inspeo, que um ou mais aspectos do processo esto fora dos limites aceitveis e que o produto resultante ser inaceitvel, ele dever ajustar o processo ou o material sendo processado. Esse ajuste deve ser feito o mais rpido possvel para minimizar desvios posteriores. Existem trs pontos para inspeo e adaptao em Scrum. A Reunio Diria utilizada para inspecionar o progresso em direo Meta da Sprint e para realizar adaptaes que otimizem o valor do prximo dia de trabalho. Alm disso, as reunies de Reviso da Sprint e de Planejamento da Sprint so utilizadas para inspecionar o progresso em direo Meta da Verso para Entrega e para fazer as adaptaes que otimizem o valor da prxima Sprint. Finalmente, a Retrospectiva da Sprint utilizada para revisar a Sprint passada e definir que adaptaes tornaro a prxima Sprint mais produtiva, recompensadora e gratificante.

CONTEDO DO SCRUM
O framework Scrum consiste em um conjunto formado por Times Scrum e seus papis associados, Eventos com Durao Fixa (Time-Boxes), Artefatos e Regras. Times Scrum so projetados para otimizar flexibilidade e produtividade. Para esse fim, eles so auto-organizveis, interdisciplinares e trabalham em iteraes. Cada Time Scrum possui trs papis: 1) o ScrumMaster, que responsvel por garantir que o processo seja entendido e seguido; 2) o Product Owner, que responsvel por maximizar o valor do trabalho que o Time Scrum faz; e 3) o Time, que executa o trabalho propriamente dito. O Time consiste em

desenvolvedores com todas as habilidades necessrias para transformar os requisitos do Product Owner em um pedao potencialmente entregvel do produto ao final da Sprint. Scrum emprega os eventos com durao fixa (time-boxes) para criar regularidade. Entre os elementos do Scrum que tm durao fixa, temos a reunio de Planejamento da Verso para Entrega, a Sprint, a Reunio Diria, a Reviso da Sprint e a Retrospectiva da Sprint. O corao do Scrum a Sprint, que uma iterao de um ms ou menos, de durao consistente com o esforo de desenvolvimento. Todas as Sprints utilizam o mesmo modelo de Scrum e todas as Sprints tm como resultado um incremento do produto final que potencialmente entregvel. Cada Sprint comea imediatamente aps a anterior. Scrum utiliza quatro artefatos principais. O Backlog do Produto uma lista priorizada de tudo que pode ser necessrio no produto. O Backlog da Sprint uma lista de tarefas para transformar o Backlog do Produto, por uma Sprint, em um incremento do produto potencialmente entregvel. Um burndown uma medida do backlog restante pelo tempo. Um Burndown de Verso para Entrega mede o Backlog do Produto restante ao longo do tempo de um plano de entrega. Um Burndown de Sprint mede os itens do Backlog da Sprint restantes ao longo do tempo de uma Sprint. As Regras fazem o elo entre os eventos com durao fixa (time-boxes), os papis e os artefatos do Scrum. Suas regras so descritas ao longo deste documento. Por exemplo, uma regra do Scrum diz que somente membros do Time - as pessoas comprometidas em transformar o Backlog do Produto em um incremento - podem falar durante uma Reunio Diria. Modos de implementar Scrum que no so regras, mas sim sugestes, esto descritas nas sees de "Dicas".

Dica: Quando as regras no so declaradas, espera-se que os usurios de Scrum descubram o que devem fazer. No tente descobrir uma soluo perfeita, porque geralmente o problema muda rapidamente. Ao invs disso, tente algo e veja como se sai. Os mecanismos de inspeo-e-adaptao inerentes natureza emprica de Scrum iro lhe guiar.

PAPIS NO SCRUM
O Time Scrum composto pelo ScrumMaster, pelo Product Owner e pelo Time. Os membros do Time Scrum so chamados porcos. Qualquer outra pessoa chamada de galinha. Galinhas no podem dizer aos porcos como eles devem fazer seu trabalho. Galinhas e porcos vm da seguinte histria:

Uma galinha e um porco esto juntos quando a galinha diz: Vamos abrir um restaurante! O porco reflete e ento diz: Como seria o nome desse restaurante? A galinha diz: Presunto com Ovos! O porco diz: No, obrigado, eu estaria comprometido, mas voc estaria apenas envolvida!

Dica: O ScrumMaster trabalha com os clientes e a gerncia para identificar e designar um Product Owner. O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners que eles saibam como conseguir otimizar valor atravs do Scrum. Se eles no souberem, consideramos o ScrumMaster responsvel.

O SCRUMMASTER
O ScrumMaster responsvel por garantir que o Time Scrum esteja aderindo aos valores do Scrum, s prticas e s regras. O ScrumMaster ajuda o Time Scrum e a organizao a adotarem o Scrum. O ScrumMaster educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior qualidade. O ScrumMaster ajuda o Time Scrum a entender e usar

autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster no gerencia o Time Scrum; o Time Scrum auto-organizvel.

Dica: O ScrumMaster pode ser um membro do Time; por exemplo, um desenvolvedor realizando tarefas da Sprint. No entanto, isso frequentemente leva a conflitos quando o ScrumMaster deve escolher entre remover impedimentos e realizar tarefas. O ScrumMaster nunca deve ser o Product Owner.

O PRODUCT OWNER
O Product Owner a nica pessoa responsvel pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantm o Backlog do Produto e garante que ele est visvel para todos. Todos sabem quais itens tm a maior prioridade, de forma que todos sabem em que se ir trabalhar. O Product Owner uma pessoa, e no um comit. Podem existir comits que aconselhem ou influenciem essa pessoa, mas quem quiser mudar a prioridade de um item, ter que convencer o Product Owner. Empresas que adotam Scrum podem perceber que isso influencia seus mtodos para definir prioridades e requisitos ao longo do tempo.

Dica: Para desenvolvimento comercial, o Product Owner pode ser o Gerente de Produto. Para esforos internos de desenvolvimento, o Product Owner poderia ser o gerente da funo de negcios em que se est trabalhando.

Para que o Product Owner obtenha sucesso, todos na organizao precisam respeitar suas decises. Ningum tem a permisso de dizer ao Time para trabalhar em um outro conjunto de prioridades, e os Times no podem dar ouvidos a ningum que diga o contrrio. As decises do Product Owner so visveis no contedo e na priorizao do Backlog do Produto. Essa visibilidade requer que o Product Owner faa seu melhor, o que faz o papel de Product Owner exigente e recompensador ao mesmo tempo.

Dica: O Product Owner pode ser um membro do Time, trabalhando tambm em desenvolvimento. Mas essa responsabilidade adicional pode reduzir a sua habilidade de lidar com as partes interessadas. No entanto, o Product Owner nunca pode ser o ScrumMaster.

O TIME
Times de desenvolvedores transformam o Backlog do Produto em incrementos de funcionalidades potencialmente entregveis em cada Sprint. Times tambm so interdisciplinares: membros do Time devem possuir todo o conhecimento necessrio para criar um incremento no trabalho. Membros do Time frequentemente possuem conhecimentos especializados, como programao, controle de qualidade, anlise de negcios, arquitetura, projeto de interface de usurio ou projeto de banco de dados. No entanto, os conhecimentos que os membros do Time devem compartilhar - isto , a habilidade de pegar um requisito e transform-lo em um produto utilizvel - tendem a ser mais importantes do que aqueles que eles no dividem. As pessoas que se recusam a programar porque so arquitetas ou designers no se adaptam bem a Times. Todos contribuem, mesmo que isso exija aprender novas habilidades ou lembrar-se de antigas. No h ttulos em Times, e no h excees a essa regra. Os Times tambm no contm subtimes dedicados a reas particulares como testes ou anlise de negcios. Times tambm so auto-organizveis. Ningum - nem mesmo o ScrumMaster diz ao time como transformar o Backlog do Produto em incrementos de funcionalidades entregveis. O Time descobre por si s. Cada membro do Time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficincia e eficcia geral do Time como um todo. O tamanho timo para um Time de sete pessoas mais ou menos duas pessoas. Quando h menos do que cinco membros em um Time, h menor interao e, como resultado, h menor ganho de produtividade. Mais do que isso, o time poder encontrar limitaes de conhecimento durante partes da Sprint e no ser capaz de entregar uma parte pronta do produto. Se h mais do que nove

membros, h simplesmente a necessidade de muita coordenao. Times grandes geram muita complexidade para que um processo emprico consiga gerenciar. No entanto, temos encontrado alguns Times bem-sucedidos que excederam os limites superior e inferior dessa faixa de tamanhos. O Product Owner e o ScrumMaster no esto includos nessa conta, a menos que tambm sejam porcos. A composio do Time pode mudar ao final da Sprint. Toda vez que o Time muda, a produtividade ganha atravs da auto-organizao reduzida. Deve-se tomar cuidado ao mudar a composio do Time.

TIME-BOXES
Os Eventos com Durao Fixa (Time-Boxes) no Scrum so a Reunio de Planejamento da Verso para Entrega, a Sprint, a Reunio de Planejamento da Sprint, a Reviso da Sprint, a Retrospectiva da Sprint e a Reunio Diria.

REUNIO DE PLANEJAMENTO DA VERSO PARA ENTREGA

O propsito do planejamento da verso para entrega o de estabelecer um plano e metas que o Time Scrum e o resto da organizao possam entender e comunicar. O planejamento da verso para entrega responde s questes: Como podemos transformar a viso em um produto vencedor da melhor maneira possvel? Como podemos alcanar ou exceder a satisfao do cliente e o Retorno sobre Investimento (ROI) desejados? O plano da verso para entrega estabelece a meta da verso, as maiores prioridades do Backlog do Produto, os principais riscos e as caractersticas gerais e funcionalidades que estaro contidas na verso. Ele estabelece tambm uma data de entrega e custo provveis que devem se manter se nada mudar. A organizao pode ento inspecionar o progresso e fazer mudanas nesse plano da verso para entrega a cada Sprint.

Ao se utilizar Scrum, os produtos so construdos iterativamente, de modo que cada Sprint cria um incremento do produto, iniciando pelo de maior valor e maior risco. Mais e mais Sprints vo adicionando incrementos ao produto. Cada incremento um pedao potencialmente entregvel do produto completo. Quando j tiverem sido criados incrementos suficientes para que o produto tenha valor e uso para seus investidores, o produto entregue. Muitas organizaes j possuem um processo de planejamento de verso para entrega, e na maior parte desses processos o planejamento feito no incio do trabalho da verso e no modificado com o passar do tempo. No planejamento de verso para entrega do Scrum, so definidos uma meta geral e resultados provveis. Esse planejamento geralmente no requer mais do que 15-20% do tempo que uma organizao costumava utilizar para produzir um plano de verso para entrega tradicional. No entanto, uma verso com Scrum realiza planejamento no momento da execuo de cada reunio de Reviso de Sprint e de Planejamento de Sprint, da mesma forma que realiza um planejamento dirio no momento da execuo de cada Reunio Diria. De forma geral, os esforos para uma verso para entrega com Scrum provavelmente consomem ligeiramente mais esforo do que os esforos para um planejamento de verso para entrega tradicional. Planejamento de verso para entrega requer estimar e priorizar o Backlog do Produto para a Verso. H diversas tcnicas para faz-lo que esto fora do alcance do Scrum, mas que apesar disso so teis quando usadas com ele.

A SPRINT
A Sprint uma iterao. Sprints so eventos com durao fixa. Durante a Sprint, o ScrumMaster garante que no ser feita nenhuma mudana que possa afetar a Meta da Sprint. Tanto a composio do time quanto as metas de qualidade devem permanecer constantes durante a Sprint. As Sprints contm e consistem na reunio de Planejamento de Sprint, o trabalho de desenvolvimento, a Reviso da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma aps a outra, sem intervalos entre elas.

10

Um projeto serve para cumprir alguma funo. Em desenvolvimento de software, o projeto utilizado para desenvolver um produto ou sistema. Cada projeto consiste em uma definio do que ser desenvolvido, um plano para desenvolv-lo, o trabalho realizado de acordo com o plano e o produto resultante. Cada projeto possui um horizonte, que o perodo de tempo para o qual o plano vlido. Se o horizonte for longo demais, a definio poder ter mudado, variveis demais podero ter surgido, o risco poder ser grande demais etc. Scrum um framework para projetos cujo horizonte no superior ao perodo de um ms, onde j h complexidade suficiente tal que um horizonte mais longo seria arriscado demais. A previsibilidade do projeto deve ser controlada pelo menos a cada ms, e o risco de que o projeto saia de controle ou se torne imprevisvel contido pelo menos a cada ms.

Dica: Se o time sentir que se comprometeu com mais do que podia, ele se encontra com o Product Owner para remover ou reduzir o escopo do Backlog do Produto selecionado para a Sprint. Se o time sentir que sobrar tempo, ele pode trabalhar junto ao Product Owner para selecionar mais do Backlog do Produto.

Dica: Quando um Time comea com o Scrum, Sprints de duas semanas o permite aprender sem se afundar na incerteza. Sprints desse tamanho podem ser sincronizadas com outros Times adicionando-se dois incrementos juntos.

As Sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele possa faz-lo sob influncia das partes interessadas, do Time ou do ScrumMaster. Sob que tipo de circunstncias pode ser necessrio cancelar uma Sprint? A gerncia pode precisar cancelar uma Sprint se a Meta da Sprint se tornar obsoleta. Isso pode ocorrer se a empresa mudar de direo ou se as condies do mercado ou tecnologia mudarem. Em geral, uma Sprint deve ser cancelada se ela no fizer mais sentido dadas as circunstncias atuais. Porm, por causa da curta durao das Sprints, raramente isso faz sentido.

11

Quando uma Sprint cancelada, todos os itens do Backlog do Produto que estejam completados e "feitos" so revisados. Eles so aceitos se representarem um incremento potencialmente entregvel. Todos os outros itens do Backlog do Produto so devolvidos ao Backlog do Produto com suas estimativas iniciais. Assume-se que qualquer trabalho realizado nesses itens perdido. Cancelamentos de Sprints consomem recursos, j que todos tm que se reagrupar em outra reunio de Planejamento de Sprint para iniciar uma nova Sprint. Cancelamentos de Sprints so frequentemente traumticos para o Time, e so muito incomuns.

REUNIO DE PLANEJAMENTO DA SPRINT

A Reunio de Planejamento da Sprint quando a iterao planejada. fixada em oito horas de durao para uma Sprint de um ms. Para Sprints mais curtas, aloca-se para essa reunio aproximadamente 5% do tamanho total da Sprint, e ela consiste de duas partes. A primeira parte, um evento com durao fixa em quatro horas, quando decidido o que ser feito na Sprint. A segunda parte, outro evento com durao fixa em quatro horas, quando o Time entende como desenvolver essa funcionalidade em um incremento do produto durante a Sprint. H duas partes na Reunio de Planejamento da Sprint: a parte do o qu? e a parte do como?. Alguns Times Scrum juntam as duas. Na primeira parte, o Time Scrum trata da questo do o qu?. Aqui, o Product Owner apresenta ao Time o que mais prioritrio no Backlog do Produto. Eles trabalham em conjunto para definir qual funcionalidade dever ser desenvolvida durante a prxima Sprint. As entradas para essa reunio so o Backlog do Produto, o incremento mais recente ao produto, a capacidade do Time e o histrico de desempenho do Time. Cabe somente ao Time a deciso de quanto do Backlog ele deve selecionar. Somente o Time pode avaliar o que ele capaz de realizar na prxima Sprint. Uma vez selecionado o Backlog do Produto, a Meta da Sprint delineada. A Meta da Sprint um objetivo que ser atingido atravs da implementao do Backlog do Produto. Ela uma descrio que fornece orientao ao Time sobre

12

a razo pela qual ele est desenvolvendo o incremento. A Meta da Sprint um subconjunto da Meta da Verso para Entrega. O motivo para se ter uma Meta da Sprint dar ao time alguma margem com relao funcionalidade. Por exemplo, a meta para a Sprint acima poderia tambm ser: Automatizar a funcionalidade de modificao de conta de clientes atravs de um middleware seguro capaz de recuperar transaes. Conforme o Time trabalha, ele mantm a meta em mente. Para satisfazer a meta, ele implementa a funcionalidade e a tecnologia. Se o trabalho se mostrar mais difcil do que o time esperava, o time ento ir colaborar com o Product Owner e implementar a funcionalidade apenas parcialmente. Na segunda parte da Reunio de Planejamento da Sprint, o Time trata a questo do como?. Durante as quatro horas seguintes da Reunio de Planejamento da Sprint, o Time define como transformar o Backlog do Produto selecionado durante a Reunio de Planejamento (o qu) em um incremento pronto. O Time geralmente comea projetando o trabalho. Enquanto projeta, o time identifica tarefas. Essas tarefas so pedaos detalhados do trabalho necessrio para converter o Backlog do Produto em software funcional. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas chamada de Backlog da Sprint. O time se auto-organiza para se encarregar e se responsabilizar pelo trabalho contido no Backlog da Sprint, tanto durante a Reunio de Planejamento da Sprint quanto no prprio momento da execuo da Sprint.

Dica: Geralmente, somente 60-70% do total do Backlog da Sprint ser definido na Reunio de Planejamento da Sprint. O restante deixado para ser detalhado mais tarde ou so dadas estimativas grandes que sero decompostas mais tarde na Sprint.

O Product Owner est presente durante a segunda parte da Reunio de Planejamento da Sprint para esclarecer o Backlog do Produto e para ajudar a efetuar trocas. Se o Time concluir que ele tem trabalho demais ou de menos, ele pode renegociar o Backlog do Produto escolhido com o Product Owner. O Time tambm pode convidar outras pessoas a participarem da reunio para

13

fornecerem conselhos tcnicos ou sobre o domnio em questo. Geralmente, um Time novo percebe pela primeira vez se ir ganhar ou perder como um Time - no individualmente - nessa reunio. O Time percebe que deve contar consigo mesmo. Conforme ele percebe isso, ele comea a se auto-organizar para assumir as caractersticas e comportamento de um verdadeiro Time.

REVISO DA SPRINT
Ao final da Sprint, feita uma reunio de Reviso da Sprint. Para Sprints de um ms, essa uma reunio com durao fixa em quatro horas. Para Sprints de duraes mais curtas, essa reunio no deve tomar mais do que 5% do total da Sprint. Durante a Reviso da Sprint, o Time Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanas no Backlog do Produto feitas durante a Sprint, eles colaboram sobre quais so as prximas coisas que podem ser feitas. Essa uma reunio informal, com a apresentao da funcionalidade, que tem a inteno de promover a colaborao sobre o que fazer em seguida. A reunio inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e o que no foi feito. O Time discute sobre o que correu bem durante a Sprint e quais problemas foram enfrentados, alm de como esses problemas foram resolvidos. O Time ento demonstra o trabalho que est pronto e responde a questionamentos. O Product Owner ento discute o Backlog do Produto da maneira como esse se encontra. Ele faz projees de datas de concluso provveis a partir de vrias hipteses de velocidade. Em seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relao ao que fazer em seguida. A Reviso da Sprint fornece entradas valiosas para as reunies de Planejamento de Sprints seguintes.

RETROSPECTIVA DA SPRINT
Aps a Reviso da Sprint e antes da prxima reunio de Planejamento da Sprint, o Time Scrum tem uma reunio de Retrospectiva da Sprint. Nessa reunio, com durao fixa em trs horas, o ScrumMaster encoraja o Time a revisar, dentro do

14

modelo de trabalho e das prticas do processo do Scrum, seu processo de desenvolvimento, de forma a torn-lo mais eficaz e gratificante para a prxima Sprint. Muitos livros documentam tcnicas que so teis em Retrospectivas. A finalidade da Retrospectiva inspecionar como correu a ltima Sprint em se tratando de pessoas, das relaes entre elas, dos processos e das ferramentas. A inspeo deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composio do time, preparativos para reunies, ferramentas, definio de pronto, mtodos de comunicao e processos para transformar itens do Backlog do Produto em alguma coisa pronta. No final da Retrospectiva da Sprint, o Time Scrum deve ter identificado medidas de melhoria factveis que ele implementar na prxima Sprint. Essas mudanas se tornam a adaptao para a inspeo emprica.

REUNIO DIRIA
Cada time se encontra diariamente para uma reunio de 15 minutos chamada Reunio Diria. Essa reunio sempre feita no mesmo horrio e no mesmo local durante as Sprints. Durante a reunio, cada membro explica:

O que ele realizou desde a ltima reunio diria; O que ele vai fazer antes da prxima reunio diria; e Quais obstculos esto em seu caminho.

As Reunies Dirias melhoram a comunicao, eliminam outras reunies, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rpida de decises e melhoram o nvel de conhecimento de todos acerca do projeto.

15

O ScrumMaster garante que o Time realize essa reunio. O Time resposvel por conduzir a Reunio Diria. O ScrumMaster ensina o time a manter a Reunio Diria com curta durao, reforando as regras e garantido que as pessoas falem brevemente. O ScrumMaster tambm enfatiza a regra de que galinhas no esto autorizadas a falar e nem a interferir de modo algum na Reunio Diria. A Reunio Diria no uma reunio de status. Ela s para as pessoas que esto transformando os itens do Backlog do Produto em um incremento (o Time), e para mais ningum. O Time se comprometeu com uma Meta da Sprint, e a esses itens do Backlog do Produto. A Reunio Diria uma inspeo do progresso na direo da Meta da Sprint (as trs perguntas). Geralmente acontecem reunies subsequentes para realizar adaptaes ao trabalho que est por vir na Sprint. A inteno otimizar a probabilidade de que o Time alcance sua Meta. Essa uma reunio fundamental de inspeo e adaptao no processo emprico do Scrum.

ARTEFATOS DO SCRUM
Os artefatos do Scrum incluem o Backlog do Produto, o Burndown da Verso para Entrega, o Backlog da Sprint e o Burndown da Sprint.

BACKLOG DO PRODUTO E BURNDOWN DA VERSO PARA ENTREGA

Os requisitos para o produto que o(s) Time(s) est(o) desenvolvendo esto listados no Backlog do Produto. O Product Owner o responsvel pelo Backlog do Produto, por seu contedo, por sua disponibilidade e por sua priorizao. O Backlog do Produto nunca est completo. A seleo inicial para o seu desenvolvimento somente mostra os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui medida que o produto e o ambiente em que ele ser usado evoluem. O Backlog dinmico, no sentido de que ele est constantemente mudando para identificar o que o produto

16

necessita para ser apropriado, competitivo e til. Enquanto existir um produto, o Backlog de Produto tambm existir. O Backlog do Produto representa tudo que necessrio para desenvolver e lanar um produto de sucesso. uma lista de todas as caractersticas, funes, tecnologias, melhorias e correes de defeitos que constituem as mudanas que sero efetuadas no produto para verses futuras. Os itens do Backlog do Produto possuem os atributos de descrio, prioridade e estimativa. A prioridade determinada por risco, valor e necessidade. H diversas tcnicas para dar valor a esses atributos.

Dica: Os itens do Backlog do Produto so geralmente representados como Estrias de Usurio. Casos de Uso tambm so apropriados, mas so mais adequados para desenvolvimento de softwares crticos em termos de vidas ou de desempenho.

O Backlog do Produto ordenado por prioridade. O Backlog do Produto de mais alta prioridade leva a atividades de desenvolvimento imediatas. Quanto mais alta sua prioridade, mais urgente ele , mais se pensou sobre ele e h mais consenso no que diz respeito ao seu valor. O Backlog de mais alta prioridade mais claro e possui mais informaes detalhadas do que o Backlog de prioridade mais baixa. Fazem-se melhores estimativas quando baseadas em uma maior clareza e em mais detalhes. Quanto mais baixa a prioridade, menor o nvel de detalhe, at que mal se consiga entender o item. medida que um produto utilizado, que seu valor aumenta e que o mercado fornece feedback, o Backlog do Produto torna-se uma lista maior e mais aprofundada. Os requisitos nunca param de mudar. O Backlog do Produto um documento vivo. Mudanas nos requisitos de negcios, condies do mercado, tecnologia e equipe causam mudanas no Backlog do Produto. Para minimizar o retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados. Os itens do Backlog do Produto que ocuparo os Times Scrum pelas vrias Sprints seguintes devero ter granularidade mais fina, tendo sido decompostos de forma tal que cada um dos itens possa ser feito dentro da durao da Sprint.

17

Dica: Os Times Scrum geralmente gastam 10% de cada Sprint preparando o Backlog do Produto para adequ-lo definio de Backlog do Produto feita acima. Quando estiverem adequados a esse nvel de granularidade, os itens no topo do Backlog do Produto (de maior prioridade e de maior valor) so decompostos de forma que caibam em um Sprint. Eles foram analisados e se refletiu sobre eles durante esse processo de preparao. Quando ocorre a reunio de Planejamento de Sprint, esses itens de maior prioridade do Backlog do Produto esto bem entendidos e so facilmente selecionados.

Frequentemente, mltiplos Times Scrum trabalham juntos no mesmo produto. Um nico Backlog do Produto usado para descrever o trabalho a ser realizado no produto. Ento, um atributo que agrupe os itens aplicado no Backlog do Produto. O agrupamento pode ocorrer por conjuntos de caractersticas, por tecnologia ou por arquitetura, e ele frequentemente utilizado como uma forma de se organizar o trabalho por Time Scrum.

Dica: Testes de aceitao so frequentemente utilizados como um outro atributo para o item do Backlog do Produto. Eles podem frequentemente substituir descries textuais mais detalhadas com uma descrio testvel do que o item do Backlog do Produto deve fazer uma vez que esteja completo.

O grfico de Burndown da Verso para Entrega registra a soma das estimativas dos esforos restantes do Backlog do Produto ao longo do tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que o Time Scrum e a organizao tenham decidido usar. As unidades de tempo geralmente so Sprints. As estimativas dos itens do Backlog do Produto so inicialmente calculadas durante o Planejamento da Verso para Entrega, e posteriormente medida que itens forem sendo criados. Durante a preparao do Backlog de Produto, os itens so revistos e revisados. Entretanto, eles podem ser atualizados em qualquer momento. O Time responsvel por todas as estimativas. O Product Owner pode influenciar o Time, ajudando-o a entender e a escolher as

18

mudanas, mas a estimativa final feita pelo Time. O Product Owner mantm o Backlog do Produto e o Burndown do Backlog da Verso para Entrega atualizados e publicados todo o tempo. Uma linha de tendncia pode ser traada baseada na mudana do trabalho restante.

Dica: Em algumas organizaes, acrescenta-se mais trabalho ao Backlog do que se realiza. Isso pode criar uma linha de tendncia plana ou at com inclinao crescente. Para compensar isso e manter a transparncia, um novo piso pode ser criado quando se adiciona ou quando se subtrai trabalho. O piso deve adicionar ou remover somente mudanas significativas e deve ser bem documentado.

Dica: A linha de tendncia pode no ser confivel pelas duas ou trs primeiras Sprints de uma verso, a menos que os times j tenham trabalhado juntos anteriormente, conheam bem o produto e entendam a tecnologia envolvida.

BACKLOG DA SPRINT E BURNDOWN DA SPRINT

O Backlog da Sprint consiste nas tarefas que o time executa para transformar itens do Backlog do Produto em um incremento pronto. Muitas delas so elaboradas durante a Reunio de Planejamento da Sprint. O Backlog da Sprint todo trabalho que o Time identifica como necessrio para alcanar a Meta da Sprint. Os itens do Backlog da Sprint devem ser decompostos. A decomposio deve ser suficiente para que mudanas no progresso possam ser entendidas na Reunio Diria. O Time modifica o Backlog da Sprint no decorrer da Sprint, bem como surge Backlog da Sprint durante a Sprint. Quando chega s tarefas individuais, o Time pode descobrir que mais ou menos tarefas sero necessrias, ou que uma determinada tarefa levar mais ou menos tempo do que era esperado. medida que novo trabalho surge, o Time o adiciona ao Backlog da Sprint. medida que se trabalha nas tarefas ou que elas so completadas, as horas

19

estimadas de trabalho restantes para cada tarefa so atualizadas. Quando se verifica que determinadas tarefas so desnecessrias, elas so removidas. Somente o Time pode modificar o seu Backlog da Sprint durante uma Sprint. Somente o Time pode mudar o seu contedo ou as suas estimativas. O Backlog da Sprint um retrato em tempo real altamente visvel do trabalho que o Time planeja efetuar durante a Sprint, e ele pertence unicamente ao Time. O Burndown do Backlog da Sprint um grfico da quantidade restante de trabalho do Backlog da Sprint em uma determinada Sprint ao longo do tempo da Sprint. Para criar esse grfico, determine quanto trabalho resta somando as estimativas do Backlog a cada dia da Sprint. A quantidade de trabalho restante para uma Sprint a soma do trabalho restante para tudo do Backlog da Sprint. Acompanhe essas somas diariamente e utilize-as para criar um grfico que mostre o trabalho restante ao longo do tempo. Traando uma linha atravs dos pontos no grfico, o Time pode gerenciar seu progresso em completar o trabalho de uma Sprint. A durao no considerada em Scrum. O trabalho restante e a data so as nicas variveis de interesse.

Dica: Sempre que possvel, desenhe o grfico de burndown mo em uma folha grande de papel exibida na rea de trabalho do Time. mais provvel que o Time veja um grfico grande e visvel do que um grfico de Burndown da Sprint no Excel ou em alguma ferramenta.

Uma das regras do Scrum est ligada ao objetivo de cada Sprint, que ter como resultado incrementos de funcionalidade potencialmente entregveis que estejam de acordo com uma definio de pronto operacional.

PRONTO
Scrum exige que os Times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente entregvel, pois o Product Owner pode optar por implantar a funcionalidade imediatamente. Para isso ser possvel, o incremento deve ser um pedao

20

completo do produto. Ele deve estar pronto. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos. No desenvolvimento de produtos, afirmar que a funcionalidade est pronta pode levar algum a presumir que ela est pelo menos bem codificada, refatorada, que tenha passado por testes unitrios, que tenha sido feito o build e que tenha passado por testes de aceitao. Outros podem presumir que apenas o cdigo tenha sido desenvolvido. Se ningum sabe qual a definio de pronto, os outros dois pilares do controle de processos empricos no funcionam. Quando algum descreve algo como pronto, todos devem entender o que pronto significa. Pronto define o que o Time quer dizer quando se compromete a aprontar um item de Backlog do Produto em uma Sprint. Alguns produtos no contm documentao, de forma que sua definio de pronto no inclui documentao. Um incremento completamente pronto inclui toda a anlise, projeto, refatoramento, programao, documentao e testes para o incremento e todos os itens do Backlog do Produto no incremento. Os testes incluem testes de unidade, de sistema, de usurio e de regresso, bem como testes no-funcionais como de performance, de estabilidade, de segurana e de integrao. Pronto inclui tambm qualquer internacionalizao necessria. Alguns Times ainda no so capazes de incluir em sua definio de pronto tudo o que necessrio para a implantao. Isto deve estar claro para o Product Owner. Esse trabalho restante dever ser feito antes que o produto possa ser implantado e utilizado.

Dica: Trabalho "no pronto" geralmente acumulado em um item do Backlog do Produto chamado "Trabalho No Pronto" ou "Trabalho de Implantao". medida que esse trabalho acumula, o Burndown do Backlog do Produto se mantm mais preciso do que se esse trabalho no fosse acumulado.

Dica: Algumas organizaes so incapazes de desenvolver um incremento completo dentro de uma Sprint. Elas podem ainda no ter infraestrutura automatizada de testes para completar todos os testes. Nesse caso, duas categorias

21

so criadas para cada incremento: o trabalho pronto e o trabalho no pronto. O trabalho no pronto a poro de cada incremento que ter que ser completada mais tarde. O Product Owner sabe exatamente o que ele est inspecionando ao final da Sprint, porque o incremento atende definio de pronto e o Product Owner entende essa definio. O trabalho no pronto adicionado a um item do Backlog do Produto chamado trabalho no pronto, de forma que ele se acumula e isso refletido corretamente no grfico de Burndown da Verso para Entrega. Essa tcnica cria transparncia no progresso em direo entrega. A inspeo e a adaptao na Reviso da Sprint sero to precisas quanto essa transparncia for. Por exemplo, se um Time no capaz de realizar os testes de performance, regresso, estabilidade, segurana e integrao para cada item do Backlog do Produto, a proporo desse trabalho em relao ao trabalho que pode ser pronto (anlise, projeto, refatoramento, programao, documentao, testes unitrio e testes de usurio) calculada. Vamos supor que essa proporo de seis peas de pronto e quatro peas de no pronto. Se o Time terminar um item de Backlog de Produto de seis unidades de trabalho (o Time est estimando baseado no que ele sabe como aprontar), quatro unidades sero acrescidas ao item do Backlog do Produto denominado trabalho no pronto quando eles tiverem terminado. Sprint a Sprint, o trabalho no pronto de cada incremento vai se acumulando e deve ser tratado antes da entrega do produto. Esse trabalho acumulado linearmente, embora haja algum tipo de acmulo exponencial que dependente das caractersticas de cada organizao. Sprints de entrega so adicionados ao final de cada verso para completar o trabalho no pronto. O nmero de Sprints imprevisvel visto que o acmulo de trabalho no pronto no linear.

Algumas tcnicas teis para conduzir uma Retrospectiva em Scrum podem ser encontradas em: Agile Retrospectives: Making Good Teams Great, Esther Derby e Diana Larsen, Pragmatic Bookshelf, 2006. User Stories Applied: For Agile Software Development, Mike Cohn, Addison-Wesley, 2004. Writing Effective Use Cases, Alistair Cockburn, Addison-Wesley, 2000.

22