Método ágil Scrum: o que você precisa saber

Nesse artigo vamos te explicar sobre a metodologia ágil Scrum e como aplicá-la em seu negócio. Clique aqui para saber mais!

Criado por Ken Schwaber e Jeff Sutherland, o Scrum surgiu no início dos anos 90 devido a necessidade de mudar a forma tradicional de gestão de projetos. A ideia seria ativar valor em menos tempo com ciclos menores de 2 a 4 semanas (Sprint), ao invés de projetar e realizar a entrega ao final de meses, de 1 ou 2 anos no modelo cascata, seguindo o modelo tradicional de gestão de projetos.

O Scrum é um framework para soluções adaptativas de problemas complexos, baseado no empirismo e no Lean Thinking. O empirismo nos diz que aprendemos baseados em experiência e na tomada de decisões no que pode ser observado. O Lean Thinking foca na redução do desperdício e no que é essencial.

Com os incrementos gerados a cada Sprint, conseguimos ativar valor de forma mais rápida, validar hipóteses, colher feedbacks e assim corrigir o curso dos produtos. Desta forma conseguimos melhorar a previsibilidade e eficiência dos times.

Existem 4 eventos formais no Scrum, são eles: Planning, Daily, Review, Retrospective.

Implementados pelos 3 pilares, Transparência, Inspeção e Adaptação, os 4 eventos estão contidos na Sprint, que nos ajuda na evolução do processo e produto. 

Neste artigo, explicaremos como funcionam cada um desses 4 eventos e vamos tirar todas as suas dúvidas sobre esse assunto. 

Boa leitura!

O movimento Ágil propõe alternativas à gestão tradicional de projetos. Abordagens ágeis são normalmente usadas no desenvolvimento de software para ajudar as empresas a responder à imprevisibilidade que se referem a um grupo de metodologias de desenvolvimento de software baseadas no desenvolvimento iterativo, onde requisitos e soluções evoluem por meio da colaboração entre equipes multifuncionais auto-organizadas.

O objetivo principal de ser Ágil é capacitar a equipe de desenvolvimento a capacidade de criar e responder às mudanças para ter sucesso em um ambiente incerto e turbulento.‎

Scrum e ágil não significa a mesma coisa, mas o scrum é um dos processos ágeis. Eles são baseados no desenvolvimento iterativo. Os requisitos e soluções de agilidade obtidos pela associação entre as equipes interfuncionais e auto-organizações, e quando implementados adequadamente podem ajudar as equipes a resolver problemas complexos, fornecendo incrementalmente produtos de maior valor, ao mesmo tempo em que mitigam o risco.‎

‎O Scrum envolve pronta inspeção e adaptação, o trabalho em equipe é aprimorado pela filosofia de liderança, responsabilidade e auto-organização, melhores práticas de engenharia que ajudam na entrega de software prompt de alta qualidade.‎

‎Um processo scrum distingue-se de outros processos ágeis por conceitos e práticas específicas, divididos nas três categorias de Funções (‎‎proprietário de produto‎‎, ‎‎mestre scrum‎‎, equipe de desenvolvimento e outras partes interessadas), eventos, artefatos e regras.‎

‎Para iniciar um processo scrum, um proprietário de produto cria uma lista de desejos priorizada chamada ‎‎backlog de produto‎‎. Durante o ‎‎planejamento de sprint‎, o backlog é dimensionado para complexidade e valor do negócio (prioridade). O proprietário do produto (cliente) e a equipe de desenvolvimento determinam quais itens de backlog são adicionados ao sprint. 

A equipe tem um certo tempo (chamado de ‎‎sprint‎‎, geralmente de duas a quatro semanas) para completar seu trabalho, mas se reúne todos os dias para avaliar seu progresso (‎‎scrum diário‎‎). Ao longo do caminho, o Scrum Master mantém a equipe focada em seu objetivo. No final do sprint, a equipe analisa seu progresso, mostra ao cliente o produto de trabalho e analisa o que deu certo ou o que eles precisam melhorar para o próximo sprint. Em seguida, o ciclo se repete.‎

Os objetivos do projeto, o trabalho a ser executado deve está visíveis a todos os envolvidos.

A falta de transparência pode levar as pessoas a tomarem decisões equivocadas aumentando a chance de risco, diminuindo o valor agregado.

A Inspeção acontece diariamente no Scrum. Com a transparência do trabalho em progresso, rumo aos objetivos definidos, facilita a inspeção e tomada de decisões ao detectar problemas indesejáveis. Para citar alguns problemas: erros no processo, falta de transparência dos objetivos, incremento gerado não atender aos objetivos do cliente dentre outros.

A adaptação vem do aprendizado com a Inspeção. Para que a mesma ocorra, o Scrum Team deve ser empoderado e auto-gerenciável.



Para clarificar: um plano de ação deve ser baseado em algum problema que de fato atrapalhe o alcance do Scrum Team nos seus objetivos. Como mencionado na Inspeção, se o Dev Team detecta um problema com a escrita das histórias, o plano de ação deve focar em resolver o problema da escrita, agregando valor ao trabalho do time.

O Scrum encoraja, empodera as tomadas de decisões ao Scrum Team. Para isso é necessário viver os 5 valores:

O Compromisso é firmado no momento de planejamento da Sprint, onde o Scrum Team define os objetivos a serem atingidos. Ao longo da Sprint o Dev Team deve manter o Foco nos objetivos firmados. O Scrum Team e Stakeholders tem Abertura para tratar e solucionar os desafios em busca de objetivos. O Respeito é mútuo entre os membros do Scrum Team e stakeholders. Devem ter a Coragem de trabalhar na coisa certa e em problemas difíceis.



O Scrum Team deve se basear nos valores para tomada de decisões, ações e comportamento.

O Scrum Team é composto por um Product Owner, Scrum Master e Developers, totalizando no máximo 10 pessoas.

A ideia de trabalhar com times menores é facilitar a comunicação entre as pessoas e manter um time produtivo. Quando houver um time com mais de 10 pessoas, o mesmo deve ser reorganizado em vários Scrum Team. Dentro do Scrum Team não deve haver subdivisões ou hierarquias.

Composto por pessoas multifuncionais, que possuem todas as habilidades necessárias para criar valor a cada Sprint. São também pessoas autogerenciáveis, que decidem internamente quem faz o quê, quando e como.

É de responsabilidade do Scrum Team as atividades relacionadas ao produto, a colaboração com stakeholder, verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento.

Composto por pessoas comprometidas e com as habilidades necessária para gerar Incremento utilizáveis e de valor a cada Sprint.

É de responsabilidade dos Developers:

• Por criar o Sprint Backlog;
• Pela Definição de Pronto; 
• Adaptar seu plano diariamente focado na meta da Sprint;
• Responsabilizar-se mutuamente como profissionais.

É de responsabilidade do Product Owner a maximização de valor do Produto a ser gerado pelo Scrum Team.

Também é de responsabilidade a gestão eficaz do Product Backlog, que inclui:

• Desenvolver e comunicar explicitamente a meta do produto;
• Criar e comunicar claramente os itens do Product Backlog;
• Priorizar os itens do Product Backlog;
• Garantir que o Product Backlog seja transparente, visível e compreensível. 

A responsabilidade de manutenção do Product Backlog pode ser delegada às pessoas do Scrum Team, no entanto o Product Owner continua com a responsabilidade pela gestão do mesmo.

Para que o trabalho do Product Owner seja efetivo é importante que o mesmo seja empoderado e respeitado nas suas decisões.



É importante observar que o Product Owner é apenas uma pessoa, podem representar muitos stakeholders. Caso esses stakeholders tenham a necessidade de priorização dos seus itens no Product Backlog, o mesmo deve ser feito junto ao Product Owner.

O Scrum Master é responsável por estabelecer o Scrum dentro da organização, garantido que todos tenham entendimento do framework.

Eles são líderes que devem servir ao Scrum Team, Product Owner e a Organização das seguintes maneiras

Scrum Team

• Treinar os membros do time para que sejam autogerenciáveis e multifuncional; 
• Ajudar o Scrum Team a se concentrar na criação de incrementos de alto valor que atendem à Definição de Pronto; 
• Remoção dos impedimentos; 
• Garantir que todos os eventos Scrum sejam efetivos e que ocorram no Timebox. 

Product Owner

• Ajudar a encontrar técnicas para a definição eficaz de meta do Produto e gerenciamento do Product Backlog;
• Ajudar o Scrum Team a entender a necessidade de itens do Product Backlog;
• Ajudar a estabelecer o planejamento empírico do produto para um ambiente complexo;
• Facilitar a colaboração dos stakeholders, conforme solicitado ou necessário.

Organização

• Liderar, treinar e orientar a organização na adoção do Scrum;
• Planejar e aconselhar implementação do Scrum dentro da organização;
• Ajudar os funcionários e os stakeholders a compreender e aplicar uma abordagem empírica para trabalhos complexos;
• Remover barreiras entre stakeholders e Scrum Teams.
  

Sprint Planning

Este evento marca o início da Sprint, é o momento em que o Scrum Team definirá os próximos passos e a meta a ser atingida ao final da Sprint. Os desenvolvedores poderão convidar pessoas fora do Scrum Team para participar, caso tenha necessidade.

Importante ressaltar que este evento deve durar no máximo 8 horas para uma Sprint de 1 mês.

O Product Owner deve garantir o Definition of Ready das histórias, itens do Product Backlog priorizados junto aos stakeholders, e que os Desenvolvedores tenham entendimento do que precisará ser desenvolvido.

Definition of Ready: são as políticas definidas nas fases de concepção do produto que ajudaram a garantir que as histórias estão devidamente escritas, com os critérios de aceite (utilizado para garantir que o desenvolvimento está atendendo a necessidade do cliente), style guide de telas definidas caso haja, com protótipo caso haja. Esses alguns exemplos para ajudar.

Os Desenvolvedores definirão a solução técnica para atender às solicitações dos stakeholders. Se neste momento eles entenderem que as histórias não estão atendendo a política de Definition of Ready, eles tem o poder de barrar as histórias.

Ao final do evento o Scrum Team tem que ter a clareza e transparência de qual a meta a ser atingida ao final da Sprint.

Dica de Planejamento:
No dia a dia dos projetos costumamos dizer que precisamos nos basear nos histórias no intuito de melhorarmos nossa previsibilidade. Então se você já tem o histórico de suas sprints passadas é muito importante utilizá-las, caso ainda não haja, a sugestão é de gerar esses histórico ao longo das próximas 3 ou 4 sprints. Quer saber como fazer? Se liga no módulo de métricas!

Daily

Este é o momento em que os desenvolvedores inspecionam a meta da Sprint e caso encontrem desvios, impedimentos, é hora de elaborar um plano de ação (adpatar) para retornar o trem aos trilhos.

O Product Owner e o Scrum Master não são obrigatórios neste evento, a não ser que eles tenham alguma história de sua posse.

A daily deve ter duração de no máximo 15 minutos.

Dica de execução:

Além de utilizar o burn down, burn up, utilize também o kanban para direcionar a inspeção dos desenvolvedores. Sempre olhando o quadro da direita para a esquerda, pois, isso ajuda o time a gastar energia naquilo que está mais próximo de ser entregue.

Para que haja o engajamento dos desenvolvedores, utilize de um tempo da daily para fazer uma dinâmica de quebra gelo, eu por exemplo: apresento um animal diferente todos os dias.

Review

A review é o momento de inspecionar a meta da Sprint. Devem participar deste evento o Scrum Team e os stakeholders.

Os desenvolvedores devem apresentar o incremento gerado ao longo da sprint para que haja a revisão da meta planejada.

Caso haja necessidade de evolução do incremento apresentado, é necessário fazer uma revisão dos itens de backlog e nova priorização.

Este evento deve durar no máximo 4 horas para Sprint de 1 mês.

Retrospective

A “retrospective” é o momento onde o Scrum Team inspeciona como foi o andamento da Sprint em atual. Este evento marca o encerramento da Sprint e deve ter duração no máximo de 3 horas para Sprint de 1 mês.

É preciso ter cuidado para que a Retrospective não vire uma sessão de lavagem de roupa suja, o evento deve ter o foco na melhoria contínua do processo, aumento de qualidade e eficácia. Assuntos como por exemplo: 1 colaborador do time de desenvolvedor não está focado em ajudar ao time atingir a meta da Sprint, deve ser tratado no dia a dia.

É uma boa prática, que você utilize das métricas, se liga no módulo de métricas, para identificar o que houve de bom e o que precisa ser melhorado. O Scrum Team vota nos itens que entendem como prioridade e que ajudam a melhorar o dia a dia e criam planos de ações para os itens mais votados.

Dicas de Execução:
Utilize um tempo do evento para fazer uma dinâmica de quebra gelo, o site da Fun Retro tem muitas sugestões.

Um exemplo de retrospetive é da 5 tias:

Refinamento ou Detalhamento

Oficialmente não é considerado um Evento do SCRUM, mas é de suma importância tanto quanto os demais eventos. É neste momento que o SCRUM TEAM seleciona itens da Product Backlog para o refinamento em termos de negócio e solução técnica.

É uma boa prática na 1a sessão o Product Owner apresentar o Product Backlog com as devidas atualizações dos itens e suas priorizações.

Ao refinar as histórias, é muito importante levar em consideração que as mesmas devam ser pequenas o suficiente, independentes, testáveis e que gerem valor ao final da Sprint.

Algumas técnicas como sugestão:

I - Independente

N - Negociável

V - Valor

E - Estimável
S - Pequena (Small)
T - Testável

A - Ação

R - Resultado

O - Objetivo

A técnica do INVEST nos ajuda a pensar e gerar histórias de qualidade e que agreguem valor ao final de cada SPRINT. Já a técnica ARO ajuda a dar clareza na descrição de cada item da Sprint Backlog.

No Scrum existem apenas 3 artefatos, são eles:

• Product Backlog
• Sprint Backlog
• Incremento gerado durante a Sprint
• 

Product Backlog

Contém a lista de desejos (épicos) dos stakeholders em ordem de prioridade. Este artefato deve estar acessível a todos, com clareza das principais informações e com o potencial para maximizar a qualidade do produto a ser construído.



O Product Owner é o responsável por manter a lista sempre atualizada de acordo com as necessidades dos stakeholders. Essa lista é a única fonte abastecedora da Sprint Backlog.

A Sprint Backlog é gerada a partir da Product Backlog, os desenvolvedores em tempo de Sprint Planning selecionam os itens de maior prioridade a serem trabalhados na Sprint.

É de suma importância que os itens estejam bem detalhados com o máximo de informação para que os desenvolvedores consigam planejar a melhor solução para a construção do item.



A partir dos itens selecionados, é gerado a Meta da Sprint.

O Incremento é o produto que é construído ao longo da Sprint, de acordo com a Meta definida na Sprint Backlog.

Chamamos de incremento os produtos construídos, pois a ideia é que seja somado aos outros produtos construídos em outras sprints. Assim dando forma ao Épico que foi solicitado na Product Backlog.



Importante ressaltar que os incrementos devem atender aos critérios de Definition of Done.

Definition of Done: política das etapas de construção do produto definida pelo time de desenvolvedores.

A principal contribuição da Scrum para o mundo do desenvolvimento de software é uma abordagem simples, mas eficaz, para gerenciar o trabalho de uma pequena equipe colaborativa envolvida no desenvolvimento de produtos. Ele fornece um quadro e um conjunto de regras simples que permitem uma quantidade adequada de planejamento, controle sobre o trabalho e identificação e mitigação de riscos e identificação e resolução de problemas.

Se você gostou deste conteúdo e gostaria de aprofundar ainda mais neste assunto, continue nos acompanhando no nosso blog e pode entrar em contato com o nosso time para quaisquer dúvidas!

Referência: Scrum Guide.