Atividades e Artefatos do Scrum

A seguir, não apenas as principais atividades e artefatos do Scrum serão explicados, mas também como eles estão conectados entre si.

O Product Owner tem uma determinada visão do produto. Como o produto pode ser muito complexo, ele é dividido em funcionalidades menores (elementos) através do chamado Backlog Refinement, que são listadas em uma lista de prioridades, o Product Backlog.

Um Sprint começa com o Sprint Planning, inclui o trabalho de desenvolvimento (Sprint Execution) durante o Sprint e termina com Review e Retrospectiva. O número de itens no Product Backlog geralmente é maior do que uma equipe de desenvolvimento conseguiria realizar em uma fase curta de Sprint. Por isso, a equipe de desenvolvimento precisa determinar inicialmente alguns itens no Product Backlog que acredita conseguir finalizar (Sprint Planning). O objetivo é ter um incremento de produto potencialmente entregável ao final do Sprint.

Uma observação sobre as atividades no Scrum

Em 2011, uma alteração no "The Scrum Guide" (Schwaber e Sutherland 2011) desencadeou um debate sobre se o termo mais adequado para descrever o resultado do Sprint Planning deveria ser "forecast" (previsão/estimativa) ou "commitment" (compromisso). Os defensores do termo Forecast preferem esta terminologia porque mesmo a melhor estimativa pode mudar com novas informações ao longo de um Sprint. Há também a opinião de que um Commitment por parte da equipa leva a que a qualidade do trabalho sofra, porque se tenta cumprir esse objetivo definido a todo o custo, ou porque a equipa pode tender a estabelecer metas demasiado baixas para garantir que as consegue alcançar.

Está fora de questão que cada equipa de desenvolvimento deve fazer uma estimativa do que pensa conseguir realizar num Sprint. No entanto, muitas equipas de desenvolvimento poderiam beneficiar se derivassem um Commitment a partir de um Forecast. Os Commitments levam a uma maior confiança entre o Product Owner e a equipa de desenvolvimento, assim como entre os membros individuais da equipa. Além disso, os Commitments simplificam o planeamento a curto prazo e uma tomada de decisão sensata numa empresa. Quando várias equipas estão envolvidas no desenvolvimento do produto, através dos Commitments conseguem coordenar melhor o seu planeamento – uma equipa pode orientar a sua tomada de decisão pelo Commitment de outra equipa. No entanto, um Commitment deve orientar-se principalmente pelo objetivo do Sprint e não tanto pelas tarefas em aberto. Com o aumento do conhecimento, as equipas frequentemente conseguem alcançar o objetivo do Sprint de forma diferente do que inicialmente pensado. (Na maioria das vezes será utilizado o termo Commitment a seguir. Se o contexto o exigir, será ocasionalmente utilizado também o termo Forecast.)

Para garantir que a equipa de desenvolvimento definiu um Commitment sensato, os membros da equipa criam um segundo Backlog durante o Sprint Planning, também chamado Sprint Backlog. Neste Sprint Backlog é descrito através de tarefas detalhadas (tasks) como a equipa pretende conceber, desenvolver, integrar e testar as características individuais do Product Backlog durante este Sprint.

O passo seguinte chama-se Sprint Execution, ou seja, a execução do Sprint. Aqui a equipa de desenvolvimento realiza as tarefas necessárias para implementar as features selecionadas. Nesta fase há diariamente os chamados Daily Scrums, nos quais são realizadas atividades de sincronização e verificação, bem como atividades de planeamento adaptativo. Através disso, os membros da equipa conseguem gerir melhor os seus fluxos de trabalho. No final da Sprint Execution, a equipa produziu um incremento de produto potencialmente entregável, que já representa uma parte daquilo que o Product Owner imaginou.

A Scrum Team termina o Sprint com a inspeção e adaptação (inspect-and-adapt) do produto e do processo Scrum. O produto é inspecionado no Sprint Review pela Scrum Team e pelos Stakeholders. A inspeção do processo Scrum, que é utilizado para a criação de um produto, é realizada pelos membros da equipa num processo chamado Retrospetiva. Como consequência, podem ser feitos ajustes no Product Backlog ou no processo de desenvolvimento.

Neste ponto, o ciclo do Sprint recomeça. A equipa de desenvolvimento determina agora os próximos Product Backlog Items que consegue concluir. Após um número adequado de Sprints, a visão do Product Owner terá sido realizada e o resultado pode então ser apresentado.

A seguir, cada uma destas atividades e artefactos será tratada em detalhe.

Backlog do Produto

No trabalho com Scrum, as tarefas mais valiosas são sempre realizadas primeiro. O Product Owner é – com o envolvimento da equipe de desenvolvimento e dos stakeholders – o responsável final pela sequência dessas etapas de trabalho e deve comunicá-las em uma lista de prioridades, o Product Backlog. No desenvolvimento de novos produtos, os itens do Product Backlog são inicialmente apenas funcionalidades necessárias para concretizar a visão do Product Owner. Na evolução de produtos, o Product Backlog também pode conter novas funcionalidades, assim como alterações em funcionalidades já existentes, correções de defeitos necessárias ou melhorias técnicas, etc.

O Product Owner trabalha junto com stakeholders internos e externos para reunir e definir os Product Backlog Items. Depois, ele precisa garantir que todos os itens sejam colocados na ordem correta (considerando valor, custo, conhecimento e risco), de modo que os itens mais valiosos apareçam no topo e os menos valiosos mais abaixo no Product Backlog. O Product Backlog é um artefato em constante evolução. Quando as circunstâncias de um projeto mudam ou o entendimento do Scrum Team sobre o produto cresce (através do feedback durante os Sprints), itens podem ser adicionados, removidos e revisados pelo Product Owner.

De modo geral, o processo de criar, detalhar, estimar e priorizar os Product Backlog Items é chamado de Backlog Grooming ou Backlog Refinement.

Antes de concluir a priorização ou ordenação dos itens no Product Backlog, é necessário conhecer o tamanho de cada item. O tamanho determina o custo, e o Product Owner precisa conhecê-lo para definir a prioridade de um item. O Scrum não define uma unidade de medida específica para isso. Na prática, muitas equipes utilizam unidades de medida relativas como Story Points ou Ideal Days. Uma unidade de medida relativa não expressa o tamanho absoluto de um item, mas apenas seu tamanho em relação a outros itens.

Sprints

No Scrum existem iterações ou ciclos de até um mês chamados Sprints. Um Sprint concluído deve sempre produzir algo de valor tangível para o cliente ou usuário.

Para todos os Sprints é definido um período de tempo (Timebox) com datas de início e término estabelecidas, que deve ter a mesma duração em todos os Sprints. Após a conclusão de um Sprint anterior, um novo Sprint começa imediatamente. Mesmo que haja mudanças no escopo ou na equipe que afetariam o objetivo e que normalmente não deveriam ser feitas durante um Sprint, às vezes isso é inevitável devido a certas necessidades do negócio.

Planejamento da Sprint

O trabalho em um Product Backlog pode durar várias semanas ou meses, muito mais do que pode ser realizado em um único Sprint curto. No Sprint Planning, o Product Owner, a equipe de desenvolvimento e o Scrum Master determinam quais são os Product Backlog Items mais importantes para o próximo Sprint. Nesse planejamento, o Product Owner e a equipe de desenvolvimento concordam com uma Meta do Sprint, ou seja, uma definição do que deve ser realizado no Sprint seguinte.

Com base nessa orientação, a equipe de desenvolvimento analisa o Product Backlog e identifica os itens mais valiosos que a equipe realmente consegue concluir no próximo Sprint. A velocidade de trabalho, também chamada de Sustainable Pace, deve ser escolhida de forma que possa ser mantida sem problemas por um período mais longo.

Para ter uma noção do que é viável, muitas equipes dividem cada Product Backlog Item em diferentes Tasks. Estes formam, junto com os itens correspondentes, um segundo Backlog, o Sprint Backlog.

Em seguida, as equipes de desenvolvimento fazem uma estimativa do esforço necessário para cada item (normalmente em horas). Dividir Product Backlog Items em Tasks é uma forma de Design e planejamento Just-in-Time para a conclusão das features. Com uma duração de Sprint de uma a quatro semanas, o Sprint Planning deve ser realizado em duas a oito horas – não se deve reservar mais tempo para isso. Existem diferentes abordagens, sendo que uma das mais populares segue um ciclo simples: seleciona-se um Product Backlog Item (se possível, o próximo item na lista de prioridades do Product Owner), divide-se em Tasks e decide-se se ele cabe bem no Sprint (considerando outros itens previstos para este Sprint). Se couber no Sprint e ainda sobrar tempo suficiente, o processo é repetido até que a capacidade da equipe para tarefas adicionais esteja esgotada.

Em outra abordagem, o Product Owner e a equipe determinam todos os Product Backlog Items desejados de uma só vez. Apenas a equipe de desenvolvimento faz a divisão em Tasks individuais e confirma assim que consegue concluir todos os itens desejados.

Execução do Sprint

Assim que o Scrum Team conclui o Sprint Planning e chega a um acordo sobre o conteúdo do próximo Sprint, a equipe de desenvolvimento começa a realizar o trabalho (no nível de tarefas) necessário para concluir as funcionalidades. Conclusão significa, neste caso, que todo o trabalho necessário para produzir funcionalidades de alta qualidade foi realizado.

Ninguém determina à equipe de desenvolvimento como e em que ordem ela deve executar o trabalho no Sprint Backlog no nível de tarefas. Assim, os membros da equipe podem definir seu próprio trabalho no nível de tarefas e se organizar da forma que considerem ideal para alcançar o objetivo do Sprint.

Daily Scrum / Daily Standup

Todos os dias durante o Sprint, preferencialmente no mesmo horário e local, os membros da equipe realizam uma reunião chamada Daily Scrum. Esta reunião deve durar no máximo 15 minutos. Este processo de Inspect-and-Adapt também é chamado de Daily Stand-Up, pois na prática todos os participantes costumam ficar em pé para manter a reunião curta.

Uma prática comum no Daily Scrum é cada membro da equipe responder três perguntas, o que é extremamente útil para o resto da equipe.

• O que consegui realizar desde o último Daily Scrum?
• No que provavelmente estarei trabalhando no próximo Daily Scrum?
• O que exatamente está me impedindo de fazer progresso?

Ao responder essas perguntas, todos obtêm uma visão geral do que está acontecendo, do progresso em relação ao Sprint Goal, das mudanças de planejamento para o próximo dia e dos problemas que precisam ser tratados. Para que a equipe possa garantir fluxos de trabalho rápidos e flexíveis em um Sprint, o Daily Scrum é indispensável.

Problemas não são resolvidos no Daily Scrum. Em vez disso, as equipes podem se reunir após o Daily Scrum em pequenos grupos com todos os interessados para discutir problemas. O Daily Scrum também não é uma reunião de status tradicional, como aquelas convocadas por um gerente de projeto para informá-lo sobre o estado atual do projeto. O Daily Scrum é mais voltado para comunicar o status dos itens do Sprint Backlog dentro da equipe de desenvolvimento. Principalmente, o Daily Scrum é uma atividade onde são realizadas inspeções, sincronizações e planejamento adaptativo, permitindo que uma equipe auto-organizada faça um trabalho ainda melhor.

Definição de Pronto

No Scrum, os resultados dos Sprints são chamados de incrementos de produto potencialmente entregáveis. Isso significa que tudo o que o Time Scrum queria realizar foi concluído de acordo com a Definition of Done (definição do que pode ser considerado pronto). Essa definição especifica o grau em que o resultado do trabalho é de boa qualidade e potencialmente entregável. No desenvolvimento de software, por exemplo, a Definition of Done deve especificar, no mínimo absoluto, o desenvolvimento completo de uma funcionalidade do produto, que é projetada, desenvolvida, integrada, testada e documentada.

Com uma Definition of Done rigorosa, uma empresa pode decidir a cada Sprint se deseja entregar o que foi desenvolvido para clientes internos ou externos.

Apenas para esclarecer: "potencialmente entregável" não significa que algo precisa ser realmente entregue. Essa é uma decisão de negócio que é constantemente influenciada por fatores como "Temos funcionalidades suficientes ou contribuímos o bastante para a satisfação do cliente?" ou "Nossos clientes conseguem lidar com mais uma mudança se já entregamos algo há duas semanas?".

"Potencialmente entregável" deve ser visto mais como o grau do que foi realmente realizado no Sprint. Isso significa que nenhum trabalho importante (como testes essenciais ou integração, etc.) ficou pendente e precisa ser concluído antes que o resultado do Sprint possa ser entregue. A Definition of Done não é escrita em pedra e deve ser submetida a inspeção e adaptação regulares, assim como tudo o mais. Na prática, muitos times modificam sua Definition of Done ao longo do tempo.

Revisão do Sprint

No final de cada Sprint, existem mais duas atividades de Inspect-and-Adapt. Uma delas é chamada de Sprint Review.

O objetivo desta atividade é a inspeção e adaptação do produto desejado. Um componente essencial aqui é a comunicação entre o Scrum Team, stakeholders, patrocinadores, clientes e membros interessados de outras equipes. O foco está na revisão das funcionalidades recém-concluídas em relação ao esforço total de desenvolvimento. Todos os presentes obtêm uma visão clara do que está acontecendo e têm a oportunidade de influenciar o desenvolvimento futuro, possibilitando assim a melhor solução para a organização.

Uma Review bem-sucedida resulta em um fluxo de informações em ambas as direções. As pessoas que não fazem parte do Scrum Team podem se informar sobre o estado do produto e influenciar os próximos passos. Ao mesmo tempo, os membros do Scrum Team têm a oportunidade de desenvolver uma melhor compreensão dos aspectos de negócios e marketing, recebendo feedback constante sobre se o desenvolvimento do produto está no caminho certo para que clientes e usuários fiquem entusiasmados com o produto. O Sprint Review representa, portanto, uma oportunidade planejada para inspecionar e adaptar um produto. Pessoas fora do Scrum Team podem realizar revisões de funcionalidades durante um Sprint e fornecer feedback, o que por sua vez ajuda o Scrum Team a alcançar seu Sprint Goal.

Retrospectiva do Sprint

A segunda atividade de Inspect-and-Adapt no final de um Sprint é a Sprint Retrospective e é realizada regularmente após o Sprint Review e antes do próximo Sprint Planning. Enquanto o Sprint Review é usado para inspecionar e adaptar o produto, a Sprint Retrospective é uma oportunidade para inspecionar e adaptar o processo. Em uma Sprint Retrospective, a equipe de desenvolvimento, o Scrum Master e o Product Owner se reúnem para discutir o que está funcionando na prática com o Scrum e o que não está. O foco está na melhoria contínua do processo, através da qual uma boa equipe Scrum pode se tornar uma equipe Scrum excelente. No final de uma Sprint Retrospective, a equipe Scrum deve identificar uma quantidade significativa de melhorias que serão implementadas no próximo Sprint.

Quando a Sprint Retrospective termina, todo o processo recomeça – começando com um novo Sprint Planning, onde são determinados os trabalhos mais valiosos nos quais a equipe precisa se concentrar.