O que é Scrum?

Segundo os criadores, Ken Schwaber e Jeff Sutherland, o Scrum é um framework (arcabouço) dentro do qual pessoas podem tratar e resolver problemas complexos enquanto constroem produtos de forma criativa e eficiente, com o mais alto valor possível (Guia do Scrum, 2017).

Agora você pode ouvir o artigo “O que é Scrum?”!

Ele não chega a ser um método, pois especifica apenas o que deve ser feito, mas não o como deve ser feito. Por exemplo: é necessário que haja um momento de planejamento do Time Scrum para o próximo ciclo de desenvolvimento, porém o Guia não descreve como esse momento é realizado.

Fala sobre os artefatos que devem existir, porém não exaustivamente. O formato dos mesmos também não é apresentado. O Scrum sempre irá requerer adaptações para os contextos específicos das organizações.

O que é Scrum? Conheça os três pilares e os valores

Qualquer adaptação do Scrum deve estar apoiada nos valores e nos três pilares: Transparência, Inspeção e Adaptação.

Transparência

O processo utilizado pelo Time Scrum, suas atividades e expectativas devem ter visibilidade para os interessados nos resultados do Time. Nada deve ser varrido para debaixo do tapete. Além disso, é necessário que os envolvidos utilizem uma linguagem comum compreendida por todos para que a comunicação flua.

Normalmente, essa transparência é implementada com o Quadro de Tarefas no qual o time dá visibilidade ao fluxo de trabalho e aos itens de valor que estão sendo desenvolvidos.

Times mais maduros são mais transparentes. O relacionamento e confiança entre eles e os demais stakeholders exerce forte influência na transparência. Se há uma relação de desconfiança ou imaturidade, teremos muito trabalho “escondido” e pouca visibilidade.

Além disso, a transparência está relacionada aos papéis que as pessoas desempenham durante o desenvolvimento do produto, resultados alcançados, expectativas, colaboração, etc.

Inspeção

O trabalho deve ser inspecionado frequentemente. O Time Scrum se pergunta se está caminhando rumo aos objetivos e resultados de negócio. Ele também deve se perguntar como pode aperfeiçoar seu método de trabalho, a atmosfera da equipe e a qualidade do produto que está sendo entregue. Utilizar Scrum é fazer-se constantemente a pergunta: como podemos melhorar?

Adaptação

Se a inspeção determinar que não estamos progredindo para os nossos objetivos, é hora de nos adaptarmos. Essa adaptação pode ser motivada por diversos fatores: mudanças de mercado, concorrentes, necessidades do cliente, necessidades do negócio, hipóteses invalidadas, entre muitos outros.

“Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.”
(Os 12 Princípios do Manifesto Ágil, 2001)

Valores do framework Scrum

São cinco valores  do Scrum:

• Comprometimento com o time, acordos e com a entrega e qualidade do produto ou serviço.
• Coragem para fazer o que precisa ser feito e tomar decisões mesmo que difíceis.
• Foco no cliente, resultado e objetivos do negócio.
• Abertura* para permitir que as pessoas sejam transparente e tenhamos um ambiente seguro para compartilhar conhecimento.
• Respeito às pessoas e organizações.

* Na tradução do Guia do Scrum esse valor é chamado de transparência, mas acredito que abertura seja um nome melhor, pois na versão original em inglês (openness) fala sobre termos ambientes seguros para o trabalho.

O Time Scrum

Ele é composto por  e só três papéis responsabilidades que são o Scrum Master (S.M.), Product Owner (P.O.) e o Time de Desenvolvimento. A versão de 2022 do Guia do Scrum, alterou o nome papel por responsabilidades. A ideia do Ken Schwaber e Jeff Sutherland é que o Time Scrum seja uma unidade que tem como objetivo primário construir o produto que atenda as necessidades e resolva os problemas dos clientes. A ideia de papel criava uma hierarquia entre uma pessoa e outra e muitas das vezes os membros do time diziam: “Isso aqui não é o meu papel” e o objetivo, que é único, era ignorado. As pessoas acabavam brigando por posições e não atendiam necessidades e nem resolviam problemas dos clientes.

Scrum Master (S.M.).

O Scrum Master é o facilitador do time. Ele busca insistentemente construir o melhor time do mundo e por isso trabalha para manter o Scrum funcionando. É um líder servidor que auxilia o Product Owner, Time de Desenvolvimento e demais stakeholders a compreender e praticar o Scrum. É ele que ajuda o Time Scrum a remover impedimentos e, se necessário, promover as mudanças organizacionais para que a empresa seja mais eficaz e eficiente.

No artigo Scrum Master: quem é e o que faz, o Lucas Gomes conta um pouco mais sobre esse papel. Já no artigo Disfunções no papel do Scrum Master, escrevo sobre o que NÃO deve ser o Scrum Master.

Product Owner (P.O.)

É ele quem dá a direção do produto. Ele é responsável por olhar problemas pela perspectiva do cliente e em conjunto com o Time de Desenvolvimento elaborar uma solução que os resolva e ainda traga resultados de negócio para a organização. Ele é o responsável por priorizar quais são as próximas fatias do produto a ser desenvolvidas e verificar os impactos causados pelas entregas através de métricas de eficácia. É uma pessoa de visão sistêmica que entende sobre estratégias de negócio, sobre o produto, sobre clientes, concorrentes, resultados, etc.

No artigo, Product Owner: descobrindo o papel do PO, a Andressa Chiara escreve sobre outros atributos necessários para desempenhar esse papel. Já no artigo O trabalho de FDP do Product Owner, Magno escreve sobre a essência do trabalho do P.O.

Time de Desenvolvimento Desenvolvedores

São todas as pessoas necessárias para fazer com que um item do backlog do produto se transforme em um incremento do produto (já veremos esses artefatos em breve). Ele deve ser multidisciplinar, auto-organizado, autônomo, autogerido, comprometido e incansável na busca de melhorar o seu processo de trabalho e o resultado e qualidade das suas entregas. Veja mais sobre esse papel no artigo: Quem é o Time de Desenvolvimento?

Atenção, a partir da atualização do Guia do Scrum 2020, pasou a se chamar Developers – Desenvolvedores. A ideia é tirar o sufixo Time que criava uma confusão entre o Time Scrum e o Time de Desenvolvimento. Além disso, segundo os autores do guia, afastaria a ideia de que Scrum só serveria para desenvolvimento de software 🤷🏽‍♂️.

Usuários, clientes, gestores, consumidores finais e demais stakeholders

Esses papéis NÃO estão escritos no Guia do Scrum, mas sabemos que eles têm influência sobre o Time Scrum. Essas pessoas possuem necessidades que o nosso produto deve resolver. São elas quem consomem aquilo que o Time entrega. O valor da entrega depende da percepção que elas têm sobre o produto. Em breve, veremos que eles participam de alguns eventos.

O Ciclo Scrum

A imagem abaixo explica o Ciclo de Desenvolvimento do Scrum. Ela contém os papéis (já descritos), os eventos, artefatos e algumas boas práticas que utilizamos e facilitam a vida do Time Scrum.

Planejamento da Sprint (Sprint Planning)

É o momento em que o Product Owner discute com o Time de Desenvolvimento quais itens do backlog serão desenvolvidos no próximo ciclo de construção do produto. O Scrum Master facilita a reunião garantindo que todos mantenham o foco e que os objetivos da mesma sejam alcançados.

Meta do Produto 🆕

Introduzido pela versão 2020 do Guia do Scrum, a meta do produto é definida como o estado futuro do produto. Quais são as necessidades e problemas dos clientes que pretendemos resolver. É a partir dessa meta que se deriva todo o Product Backlog que diz o que deve ser feito. A meta deve funcionar como um norte para fatiamento, priorização e descarte para criação do produto.

Um produto é um veículo para entregar valor. Tem um limite claro, stakeholders conhecidos, usuários ou clientes bem definidos. Um produto pode ser um serviço, um produto físico ou algo mais abstrato.
Guia do Scrum 2020 p.12

Product Backlog (P.B.)

O principal artefato de entrada é o Product Backlog. Ele é o conjunto de todas necessidades dos clientes e do negócio que serão resolvidas pelo produto. Ele é mantido valorado e priorizado pelo Product Owner.

Os itens não possuem o mesmo nível de detalhamento. Aqueles que estão no topo do backlog (mais prioritários) possuem mais informações sobre o que faremos, qual o propósito de fazermos e para quem entregaremos. Quanto maior a prioridade, maior o detalhamento.

Meta da Sprint

Uma das primeiras coisas que o Time Scrum deve fazer no planejamento é definir qual a Meta da Sprint. Ele serve como um guia para escolha dos itens. Exemplos de objetivos:

• Disponibilizar os produtos de Dia das Mães nas lojas piloto de três localidades: Manaus, Fortaleza, Goiânia.
• Disponibilizar a compra rápida no site.
• Lançar o seguro de vida nas cidades de São Paulo, Curitiba e Rio de Janeiro.

Perceba que agora está claro onde queremos chegar no final da Sprint. Imagine que você está no time que vai disponibilizar produtos de Dia das Mães. Faria algum sentido construir um item de backlog relacionado ao Natal? Ou fazer algo para ser avaliado em Bauru?

A Meta do Produto está para o Product Backlog (médio / longo prazo), assim como a Meta da Sprint está para o Sprint Backlog (curto prazo). Ambos tem a ideia de oferecer um norte para seleção de itens que comporão seus respectivos conteúdos.

Sprint Backlog

Uma vez definido o Objetivo da Sprint, o Time de Desenvolvimento em conjunto com o Product Owner define quais itens serão construídos na Sprint. É importante que a capacidade do time seja respeitada e o Scrum Master esteja lá para garantir isso. É comum que times Scrum utilizem o Planning Poker para definir essa capacidade.

O Time de Desenvolvimento pode detalhar ainda mais o item do backlog e para isso irá “quebrá-lo” em tarefas técnicas necessárias para transformá-lo em incremento do produto. O Sprint Backlog é o conjunto de itens do Backlog do Produto selecionados para a Sprint mais as tarefas técnicas.

Sprint

É o evento principal do Scrum e todo trabalho acontece durante ela. Seu início acontece quando começamos o Planejamento da Sprint e termina no final da Retrospectiva. Ela é um evento de período fixo (time-boxed).

Uma analogia para facilitar o entendimento de time-box é como se colocássemos o tempo dentro de uma caixa de aço que não pode se expandir. O tempo é como se fosse um líquido que enche a caixa. Quando lotar a caixa, acabou o tempo. Não há como colocar mais nada nela. Não tem aquele: “me dá mais uma semaninha que eu termino”.

Durante a Sprint, os itens do Sprint Backlog são construídos e transformados em incremento de produto potencialmente entregável.

Incremento do produto potencialmente entregável

Nome longo e estranho. Vamos explicar por partes. Incremento do produto é a aplicação do conceito de desenvolvimento iterativo e incremental adotado pelos Métodos Ágeis. Ao invés de ficarmos meses ou anos desenvolvendo um produto para entregarmos tudo ao final do projeto, no Scrum o produto é construído em várias iterações (i, i+1, i+2…). A cada iteração incrementamos e aperfeiçoamos o produto.

Alguns exemplos de incremento:

• No desenvolvimento de software, o incremento são as funcionalidades do software (features).
• Para a indústria de cosméticos, os incrementos podem ser o conjunto de produtos que serão lançados em um pacote. Por exemplo, no Dia das Mães, os incrementos poderiam ser: Batom, perfume, óleo para o corpo. Cada um entregue em 1 ciclo e já pode ser testado por alguns consumidores finais antes de começar a promoção.
• No marketing, os formatos de campanha de um produto: Campanha em redes sociais, e-mail marketing, marketing fone, promotor, etc.
• Para advogados, a construção de peças jurídicas.
• Engenharia de produção, o incremento dos módulos de operação.
• Etc.

Potencialmente entregável porque o incremento tem que estar em um estado que possa ser utilizado pelo consumidor. Não pode ser aquele: Está pronto, só falta testar. Também não é um protótipo que será descartado. Pode ser algo ainda incompleto, mas É UM PRODUTO/SERVIÇO consumível.

A entrega para o consumo é uma decisão de negócio e, portanto, depende da decisão do Product Owner. Isso acontece porque o Time pode entregar algo que ainda não é estrategicamente interessante lançar no mercado. Por exemplo, digamos que o Time está trabalhando em outubro para o site de promoção de Natal. Ele pode e deve chamar os clientes para experimentar o novo site e coletar feedback durante as iterações, mas não seria interessante lançar esse site antes da metade de novembro.

Definição de Pronto (Definition of Done)

Para saber se o incremento está pronto para ser entregue para o consumidor, utilizamos a Definição de Pronto. São todas as restrições que o produto deve cumprir antes de ser entregue. Uma espécie de lista de verificação (checklist).

• Exemplo de Definição de Pronto no Desenvolvimento de Software: código no repositório; passou em todos os testes no servidor de integração contínua; pacotes gerados, etc.
• Exemplo na engenharia de produção: robô instalado; manual de operação atualizado; regras de segurança afixadas em local visível, etc.

Se o item não cumprir todas as exigências da Definição de Pronto, ele não está pronto e não pode ser entregue. No Scrum, não existe ½ pronto ou 99,99% pronto.

Duração da Sprint

A duração é fixa e pode ser de uma até no máximo quatro semanas com preferência o menor tempo possível. Esse período NÃO fica variando. Isso significa que caso o Time Scrum decida que a Sprint terá a duração de duas semanas, todas as Sprints terão a duração de duas semanas.

Posso reduzir o tamanho da Sprint?

Sim. Todavia, deve ser algo em que todos estão de acordo em fazer e tem que ser motivado por algum fato importante. Por exemplo, o Time Scrum automatizou uma parte do processo e acredita que consegue fazer entregas de valor semanalmente. A partir de agora, todas as Sprints serão de uma semana.

Posso aumentar o tamanho da Sprint?

Muito cuidado ao fazer isso. O Time pode estar apenas escondendo um problema, ao invés de resolvê-lo na causa raiz. Por exemplo: o time aumenta a Sprint em uma semana porque a qualidade do produto está baixa e as pessoas de qualidade tem apenas algumas horas para verificar o produto. Agora, serão duas semanas de desenvolvimento mais uma semana de teste.

No início, todos acham que isso resolve o problema, mas não é verdade. Em breve esse time irá aumentar para quatro semanas, pois, na prática, o tempo de desenvolvimento também aumentará. A raiz do problema que deveria ser tratada é a baixa qualidade no desenvolvimento.

As consequências de aumentar o tamanho da Sprint:

• Evita tratar a causa raiz dos problemas;
• Reduz significativamente a capacidade de adaptação tanto do Time quanto do produto;
• Reduz a quantidade de experimentos que o Time fará;
• Diminui a eficiência;
• A entrega de valor (eficácia) também cai;
• Torna o time mais sujeito a interrupções externas;
• Diminui a quantidade de feedbacks sobre o produto;
• Retarda a melhoria contínua;
• Entre muitas outras.

Uma conta simples para vermos o quão ruim é uma Sprint grande demais:

Perceba que quanto maior a Sprint, menos experimentos teremos e com isso ficamos mais suscetíveis a sofrer as consequências listadas acima.

Reunião Diária (Daily Meeting)

Logo após o Time Scrum definir o Sprint Backlog, começa o trabalho de transformar os itens selecionados em incrementos do produto. Durante esse período, diariamente, o Time de Desenvolvimento se reúne em frente ao Quadro de Tarefas para fazer a Reunião Diária. Essa é uma reunião do Time de Desenvolvimento para o Time de Desenvolvimento. O Scrum Master facilita se necessário e a presença do Product Owner não é obrigatória. Pessoas externas (gestores, stakeholders, curiosos) só participam se o Time de Desenvolvimento concordar e ficam em silêncio durante todo o evento. Queremos criar um ambiente seguro de colaboração e não um momento de status report e justificativas.

Esse evento tem a duração máxima de 15 minutos e o objetivo é definir o que o Time de Desenvolvimento fará para dar mais alguns passos rumos ao Objetivo da Sprint naquele dia. É um momento para o Time fazer a inspeção (vamos atingir o Objetivo da Sprint?) e adaptação (o que faremos para corrigir o curso e atingir o Objetivo da Sprint?).

Para auxiliar esse propósito, existem três perguntas sugeridas no Guia do Scrum, mas elas não são obrigatórias.

• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir o objetivo da Sprint?
• O que eu farei hoje para ajudar o Time de Desenvolvimento atingir objetivo da Sprint?
• Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento de atingir o objetivo da Sprint?

Quadro de Tarefas

É uma ferramenta de transparência do Time Scrum. Ele contém todo o trabalho que o time deve fazer durante a Sprint, inclusive atividades que não estão relacionadas ao desenvolvimento do produto (participações em comitês, apoio a outros times, manutenção em outros produtos, reuniões, etc.).

O quadro pode começar no formato mais simples com três estágios de desenvolvimento: coisas a fazer, o que o Time de Desenvolvimento está fazendo e o que ele já fez.

Com o passar do tempo, o Quadro poderá refletir o fluxo de trabalho mais completo.

Gráficos de Acompanhamento

O Time Scrum também pode manter gráficos de acompanhamento para visualizar mais facilmente a evolução da Sprint ou a construção do produto inteiro. Os gráficos mais comuns de acompanhamento são o Burn Down Chart, Burn Up Chart, Gráfico de Valor e o Cumulative Flow Diagram (CFD).

Revisão da Sprint (Sprint Review)

Ao final da Sprint o incremento do produto é apresentado para consumidores, usuários, clientes, gestores e demais stakeholders. Todo o Time Scrum participa. O objetivo primário desse evento é obter feedback sobre o produto. O livro The mom test, de Rob Fitzpatrick, tem excelentes dicas de como fazer perguntas para obter bons feedbacks.

Os feedbacks proporcionados pelos convidados podem se tornar novos itens do Backlog do Produto. Eles podem ser muito estratégicos e entrarem no topo do backlog. Caso contrário, eles podem entrar no meio ou no final do mesmo. Há também a possibilidade de descartar o feedback caso ele seja irrelevante.

O correto nesse evento é que o consumidor utilize o produto. Não é uma reunião para apresentar slides ou incrementos que não atendem a Definição de Pronto.

Danilo, Agile Coach da K21 faz o papel de consumidor final para um Time Scrum durante o EVDnC.

Nessa reunião, podem ser apresentadas informações sobre o andamento do projeto, mas o foco sempre será o feedback sobre o uso do produto ou serviço.

Retrospectiva da Sprint (Sprint Retrospective)

É o momento da melhoria contínua. Todo o Time Scrum participa: Product Owner, Scrum Master e todos os membros do Time de Desenvolvimento. O objetivo dela é melhorar a forma de trabalho de todo time.

É um ambiente seguro em que o Time Scrum discute sobre falhas e pontos fracos. Logo, não devemos ter pessoas externas. A única exceção é se o time inteiro concordar em convidar alguém de fora.

No artigo “Retrospectiva: Fazendo a Melhoria Contínua do seu Time”, descrevo um pouco mais sobre esse evento importantíssimo. A K21 possui um e-book sobre Retrospectiva: baixe o e-book gratuito sobre Retrospectivas Ágeis! Também temos diversas dinâmicas de retrospectiva.

Refinamento do Backlog do Produto

Esse não é um evento oficial no Scrum, mas é uma boa prática. O refinamento pode ser feito a qualquer momento e podemos fazer reuniões para tal. O objetivo é manter o Backlog do Produto atualizado e priorizado com insumos de: novas ideias, resultados anteriores, clientes, gestores, alterações no mercado, mudanças nos competidores, inovações, etc.

Também é interessante que o Time de Desenvolvimento participe do refinamento para estimar o esforço ou discutir a complexidade técnica dos itens mais prioritários. Todavia, não deve consumir mais do que 10% da capacidade do Time de Desenvolvimento durante a Sprint.

Caso o refinamento não seja feito antes, ele acontecerá no Planejamento da Sprint. Nesse caso, teremos uma reunião muito longa. O ideal é que no momento do planejamento o Backlog do Produto já esteja atualizado, valorado, priorizado e se possível com o esforço estimado.

Definição de Preparado (Definition of Ready)

Alguns times gostam de utilizar uma definição mínima que garante que o item foi refinado e pode ser discutido no Planejamento da Sprint. A Definição de Preparado também não é oficial do Scrum, mas ajuda o time a perder menos tempo e ter mais foco durante as discussões de planejamento. Um exemplo poderia ser:

• O item tem que estar escrito no formato de História de Usuário;
• Os critérios de aceitação estão definidos;
• As métricas para medição de impacto do item foram selecionadas;
• O valor de negócio do item foi definido;
• Consumidores do item foram convidados para Revisão da Sprint;
• O esforço para construção do item foi estimado.

Quer saber mais sobre como começar na Agilidade? Confira o episódio do Love The Problem!

Conclusão

Este artigo trata de aspectos gerais do Scrum. Escrevo sobre itens oficiais do Guia do Scrum e boas práticas que nós, da K21, aprendemos ao longo do tempo. Espero que o texto te ajude a adotar o framework. Qualquer coisa, é só postar sua dúvida nos comentários.

Veja mais conteúdos sobre Agilidade e Scrum

• • Um hub com conteúdos completos sobre o que é Agilidade
  • Temos uma página completa com mais conteúdos sobre Scrum

Convido você para conhecer um pouco mais sobre este framework

Se você quer se tornar um Scrum Master, lhe convido para participar dos treinamentos de Certified Scrum Master (CSM) e Técnicas Ágeis de Facilitação.

Se você quer se tornar um Product Owner, os treinamentos de Certified Scrum Product Owner (CSPO) e Métricas Ágeis para Produtos, Times e Organizações são bons para compreender o quê deve ser feito.

Se você é membro de um Time de Desenvolvimento de Software, participe do treinamento de Certified Scrum Developer (CSD).

Agora, se você é o gestor em uma organização que está adotando Métodos Ágeis. Para esse, indico o treinamento de Management 3.0.

Acompanhe no nosso blog outros artigos sobre Scrum.