O que é Scrum?

O Scrum é um framework ágil para gerenciamento de projetos baseado na adaptação, iteratividade e entrega de valor incremental. O framework define os papéis a serem tomados no desenvolvimento do projeto, os eventos a serem realizados e os artefatos que precisam ser produzidos para apoiar o gerenciamento do projeto.

Como é um framework, o Scrum não é um processo, uma técnica ou mesmo um método definitivo. Trocando em miúdos, ele é uma estrutura base (como um molde) que serve de referência e pode ser aplicada em conjunto com vários outros processos e técnicas — como o Kanban, por exemplo.

Uma característica de um projeto gerenciado por meio do Scrum é que os times que participam dele têm poucas pessoas. Desse modo, ganha-se em flexibilidade e em qualidade da comunicação, fazendo com que o time seja altamente adaptativo.

Além disso, a execução de projetos Scrum é dividida em ciclos de trabalho, que são chamados de Sprint. Cada Sprint tem como objetivo entregar uma parte funcional do produto, sob um limite de tempo pré definido, e gerar o máximo de valor possível para o produto final.

Dentro desses períodos, o planejamento do projeto é revisto constantemente e o Backlog do Produto é refinado a medida que mudanças se fazem necessárias. Por exemplo, o responsável pelo software pode identificar que alguma funcionalidade que foi planejada não faz mais sentido para o mercado e atualizá-la antes que o time comece a desenvolvê-la.

Assim, evita-se o retrabalho e garante-se que o produto final terá o máximo de valor para os clientes.

Provavelmente você já conhece o Scrum e sabe que ele faz muito sucesso atualmente. Mas você já parou para pensar que houve uma época em que o Scrum não existia, e o modelo Cascata era o único método de gestão de projetos disponível?

Venha conosco descobrir quando o Scrum nasceu e como ele influencia a gestão de projetos até os dias de hoje.

Como surgiu o Scrum?

O conceito utilizado na formulação do Scrum surgiu na metade da década de 1980, como resultado de um estudo feito pelos professores Hirotaka Takeuchi e Ikujiro Nonaka, publicado na famosa revista Harvard Business Review.

O artigo, intitulado “O novo jogo de desenvolvimento de novos produtos”, discutia os pontos positivos e negativos de duas abordagens de gerenciamento: uma mais orientada a sequência de processos e à passagem de bastão (simbolizada pela corrida de revezamento) e outra baseada em um jogo onde o time trabalha como unidade, passando a bola para frente e para trás conforme necessário (representada pelo jogo de rúgbi).

Concluiu-se, nesse estudo, que a abordagem inspirada no jogo de rúgbi era muito mais atual e daria às empresas as ferramentas necessárias para competir no mercado de maneira ágil, inclusive internacionalmente. Nascia o conceito da abordagem adaptativa, posteriormente absorvido no Scrum.

O framework como conhecemos hoje foi testado e organizado alguns anos depois, por Ken Schwaber, Jeff Sutherland, Jeff McKenna e John Scumniotales. Em 1995, eles lançaram o artigo “SCRUM Development Process”, e revolucionaram o modo de gerenciar projetos de desenvolvimento de software. Os desenvolvedores, que até então só trabalhavam utilizando o método Waterfall (cascata), passaram a questionar se ele era realmente eficaz, e grande parte deles adotou o framework Scrum definitivamente na sua rotina de trabalho.

Mais tarde, em fevereiro de 2010, foi lançada a primeira edição do Guia Scrum, online e gratuita para todos. O objetivo era democratizar o acesso ao framework e torná-lo o mais sintetizado possível, de modo que qualquer pessoa que o baixasse pudesse aplicá-lo em sua empresa sem dificuldades.

Desde seu lançamento, o Guia Scrum vem sendo atualizado e revisado periodicamente, tornando-se mais otimizado a cada nova versão. Hoje, estima-se que mais de 60% das empresas que utilizam metodologias ágeis de gerenciamento de projetos utilizem o Scrum, tornando-o o framework mais famoso e utilizado do segmento.

Bem, falamos bastante sobre o Scrum ser um framework, mas ainda não explicamos o que é isso exatamente. Confira a descrição completa no tópico abaixo:

O que é um framework?

Um framework é uma estrutura básica composta por um conjunto de práticas, técnicas, ferramentas ou conceitos utilizados para resolver um problema ou orientar uma atividade específica (que pode ser o gerenciamento de um projeto, por exemplo, ou a estruturação de uma abordagem comercial).

Na prática, é como se o framework fosse um molde ou um gabarito que pode ser replicado várias vezes nas mesmas ocasiões. Quando um confeiteiro vai assar biscoitos, por exemplo, é comum que utilize moldes para cortá-los e garantir que todos saiam iguais, facilitando a padronização e também a própria produção dos biscoitos.

Um framework de gerenciamento de projetos (como o Scrum) funciona basicamente da mesma forma. Ele contém o direcionamento para ajudar a equipe envolvida no projeto a se organizar e estruturar o processo de planejamento, execução e controle das atividades, podendo ser replicado continuamente.

No caso do Scrum, o framework determina quais serão as funções a serem assumidas no projeto (os papéis), quais reuniões devem ser realizadas (os eventos) e quais instrumentos serão utilizados para gerenciar as atividades ao longo do tempo (os artefatos).

O Scrum também pode ser considerado uma metodologia se pensarmos que ele tem um conjunto de regras e boas práticas a serem seguidas. Veja mais sobre isso a seguir.

Conceito de metodologia ágil

As metodologias ágeis surgiram logo após o manifesto ágil, em 2001. A demanda por uma nova maneira de gerenciar projetos nas empresas de desenvolvimento de software as levou a transformar as metodologias existentes e adaptá-las ao seu contexto.

Em um cenário tão incerto quando o digital, não fazia sentido planejar tudo antes de colocar em prática se o time só descobre o que realmente pode fazer quando está com a mão na massa. Aliás, o desenvolvimento de softwares é um campo onde a inovação é a palavra de ordem, portanto, encontrar coisas inesperadas pelo caminho é praticamente uma regra.

Por isso, as metodologias ágeis idealizadas pelos profissionais dessa área priorizam a entrega de valor mais do que a documentação do projeto, e focam na adaptação às mudanças mais do que na necessidade de seguir um plano pré-estabelecido.

O verdadeiro significado de ágil, não é necessariamente ser rápido e entregar as atividades no prazo. Ser ágil significa ser capaz de lidar com mudanças no meio do caminho e adaptar o projeto a elas de maneira organizada e segura para todos os envolvidos.

Isso dá certo na prática porque, ao utilizar uma metodologia ágil, a equipe do projeto é preparada para lidar com as adversidades que podem surgir e tem flexibilidade para testar maneiras diferentes de trabalhar, afinal, não há um planejamento engessado que a impede de inovar.

O planejamento, na verdade, é feito aos poucos, no início de cada Sprint, e pode ser modificado a qualquer momento sem precisar seguir um processo de documentação extenso e burocrático.

Vale lembrar, também, que apesar de ter sido idealizado por equipes de desenvolvimento de software, as metodologias ágeis têm se popularizado cada vez mais em outras áreas do negócio. O marketing, por exemplo, que é uma área em constante transformação, tem se beneficiado bastante do uso das metodologias ágeis.

Mas, voltando ao tema do nosso post, que tal entendermos um pouco mais sobre os princípios do Scrum?

Quais são os princípios do Scrum?

Não há maneira melhor de conhecer algo ou alguém do que entendendo seus princípios, concorda? Por isso, trouxemos cada um dos princípios do Scrum para que você entenda totalmente o conceito deste framework.

De acordo com o Guia SBOK™ (Scrum Body of Knowledge), o Scrum tem seis princípios. Observe na imagem:

princípios do scrum

1) Controle de processos empíricos

Este princípio representa o fato de que todas as decisões dentro de um projeto Scrum devem ser tomadas com base em observação e experimentos, ao invés de planejamentos antecipados. Nesse sentido, o controle de processos empíricos conta com três ideias principais:

  • Transparência: permite que todos os ângulos do processo Scrum sejam visíveis por qualquer pessoa, por meio de uma comunicação fluida fortalecida pelas reuniões diárias e pelo acesso aos documentos do projeto para todos os envolvidos (Backlog do Produto, Visão do Projeto, gráfico de Burndown etc.).
  • Inspeção: representada pelo uso de um Scrumboard para acompanhar o progresso do Time Scrum, pela coleta de feedback dos clientes e outros stakeholders constantemente, e pela inspeção e avaliação das entregas, feitas pelo Product Owner e pelo cliente.
  • Adaptação: a adaptação é praticada pelo time Scrum quando ele adapta e faz melhorias o processo no que está sendo realizado. Exemplos disso são as mudanças adotadas a partir das dificuldades comunicadas nas reuniões diárias, da identificação de riscos ou mesmo das reuniões de retrospectiva.

2) Auto-organização

No Scrum, os colaboradores são motivados, proativos e buscam aceitar responsabilidades maiores, tendo a auto-organização como principal característica. Essa postura do Time é favorecida pelo modelo de liderança servidora adotado no Scrum, de modo que o líder e o liderado não são separados por fortes hierarquias, mas interagem em prol do projeto na mesma medida.
Além do mais, a auto-organização propicia um ambiente inovador e criativo, tornando a responsabilidade compartilhada e aumentando a satisfação do time.

3) Colaboração

Nenhum projeto pode sair do papel sem colaboração — por isso, o Time Scrum deve trabalhar em conjunto com os stakeholders para criar e validar as entregas do projeto.
Desse modo, todos os envolvidos e interessados no andamento do projeto ficam alinhados e garante-se que a visão do projeto será alcançada.
As três dimensões do trabalho colaborativo são:

  • Consciência: deve-se ter consciência do que os outros colegas de trabalho estão fazendo.
  • Articulação: a articulação precisa ser feita para que o trabalho seja dividido de maneira organizada entre os integrantes do time. O produto final é divido em unidades, distribuído entre os desenvolvedores, e quando pronto, é reintegrado novamente.
  • Apropriação: refere-se à adaptação da tecnologia para as situações do dia a dia. Ter aparato tecnológico para apoiar as operações de trabalho é essencial, principalmente quando falamos em colaboração.
  • 4) Priorização baseada em valor

    O Scrum tem como objetivo oferecer o máximo de valor de negócio em tempo mínimo. Para que isso seja possível, a priorização é um recurso indispensável.
    Assim, quanto maior valor um item tiver o poder de gerar, mais prioritário ele será na fila de atividades (conhecida no Scrum como Backlog do Produto).

    Quem tem a responsabilidade de determinar a prioridade das atividades é o Product Owner, papel do qual falaremos mais para frente. Ainda, é bom lembrar que deve-se considerar, além do valor, os riscos e as dependências entre as atividades que um produto pode ter, procurando tornar a etapa de priorização cada vez mais precisa.

    5) Time-boxing

    Outro princípio muito característico do Scrum é a limitação do tempo de cada Sprint e de cada Evento dentro dela.

    Em todo o projeto Scrum, as restrições de tempo são fixadas previamente, garantindo que a equipe não se perca nos prazos e não atrase entregas. As reuniões diárias de acompanhamento, por exemplo, não devem ultrapassar os 15 minutos de duração, e uma Sprint tem tempo máximo de 6 semanas.

    Isso traz como vantagem a economia com despesas gerais, o aumento da velocidade de trabalho e inclusive da produtividade. Porém, é preciso ter cuidado ao determinar o time-boxing dos eventos para que essa atitude não gere o efeito oposto (alguns integrantes do time podem sentir-se apreensivos e desmotivados caso a cobrança seja muito arbitrária).

    6) Desenvolvimento iterativo

    O princípio de desenvolvimento iterativo é baseado na repetição das Sprints ao longo do projeto, com o objetivo de gerar valor ao produto continuamente. Observe nos gráficos abaixo como isso se dá na prática, em comparação com o modelo tradicional (Cascata):

    modelo tradicional de gestão de projetos cascata e modelo framework scrum

    Enquanto a metodologia tradicional tem cinco etapas e começa a entregar valor apenas no último estágio do projeto, o Scrum tem um ciclo de etapas que se repete a cada Sprint, e assim pode entregar valor continuamente desde o começo. Porém, esse não é o único benefício que o desenvolvimento iterativo apresenta.

    Outra vantagem é que ele permite a correção ao longo do projeto, já que todos os envolvidos vão tendo conhecimento do que precisa ser entregue de maneira iterativa. Desse modo, o tempo e o esforço para chegar ao ponto final é reduzido, já que a equipe tem mais conhecimento e pode se auto organizar para chegar ao objetivo final, e então produz resultados que são mais adequados ao ambiente de negócios.

    Curioso para saber mais sobre o Scrum e como ele funciona? Acompanhe os próximos tópicos

O que é metodologia Scrum?

Metodologia Scrum é o método ágil mais conhecido entre todos os existentes. Ele agrupa conceitos, práticas e ferramentas para gerenciar projetos, especialmente projetos de software.

Se você trabalha com tecnologia, é bem provável que já tenha ouvido falar da Metodologia Scrum. Isso porque ela foi criada especialmente para atender a projetos de desenvolvimento de software. Entretanto, com o tempo, a metodologia começou a ser aplicada em outros tipos de projeto, especialmente os que possuem um escopo pouco conhecido e há incertezas em relação aos requisitos.

Webinar Guia Prático de Scrum para equipes de Tecnologia da Informação

O nome Scrum vem do Rugby e é referente ao trabalho em conjunto de um time para atingir um “goal”, que pode ser traduzido como gol ou objetivo, uma meta.

No Scrum, o trabalho de um projeto deve ser dividido em Sprints, que são pequenos ciclos de trabalho (de 2 a 6 semanas) que geram pequenas entregas. Essas entregas acrescentam um incremento ao produto final. Ou seja, ao fim de cada ciclo/Sprint, é entregue mais um “pedaço” do projeto. No caso de software, uma nova funcionalidade no produto.

As práticas do Scrum podem ser adaptadas ao contexto de cada organização. Entretanto, seus princípios ágeis dão a característica de que o escopo do projeto é planejado aos poucos conforme novas informações vão sendo conhecidas e o que já foi feito é entregue, testado e colocado em funcionamento.

Essa é a principal diferença do Scrum (e outros métodos ágeis) em relação às metodologias tradicionais. Se no método cascata, por exemplo, o escopo é totalmente planejado antes do início do projeto, no Scrum novos planejamentos são feitos conforme novos “pedaços” do projeto são entregues e disponibilizados ao cliente.

Vantagens do Scrum

Descentralização do gerenciamento

Uma das partes principais do funcionamento do time no Scrum é que a equipe deve ser autônoma e auto gerenciável. Isso significa que há uma descentralização do gerenciamento, evitando sobrecarga de uma pessoa e permitindo tomadas de decisão mais colaborativas.

Além disso, as informações também ficam descentralizadas. Portanto, todos sabem o que se passa no projeto, de modo que ideias e sugestões podem surgir de toda a equipe. Assim, os membros da equipe ajudam uns aos outros e todos são capacitados para tomar decisões assertivas.

Ajuda na organização das atividades

No Scrum, todo o trabalho do projeto é dividido em ciclos (Sprints). Ao final de cada Sprint, quando é entregue uma nova parte do projeto, são feitas reuniões para revisar o que foi feito e planejar o próximo ciclo.

Todo esse processo ajuda a evitar que o trabalho do projeto se torne um caos e as atividades fiquem desorganizadas. Sendo assim, o Scrum ajuda manter a organização do trabalho e, por consequência, evita retrabalho, atrasos e perda de produtividade.

Ajuda a incorporar mudanças no escopo.

Em metodologias clássicas, é mais difícil aplicar alterações no decorrer dos projetos. No Scrum, por sua vez, as mudanças e novidades no escopo são esperadas a, às vezes, até desejadas.

Sendo assim, a metodologia Scrum oferece flexibilidade suficiente para que o projeto seja adaptado a novas situações sem que seu andamento seja comprometido, de modo a tornar mais fácil a alteração de prioridades.

Ajuda a entregar um produto de qualidade

A metodologia Scrum traz uma série de práticas que ajudam a entregar um produto final de qualidade mesmo com as mudanças ocorridas ao longo de sua realização. Os eventos focados no planejamento e revisão dos processos são responsáveis por isso.

Ao término de cada Sprint, é necessário entregar um produto utilizável que será validado pelo Product Owner. Essa prática, assim como as reuniões para revisão e planejamento de atividades, impacta no resultado final do projeto, ajudando a entregar um produto de qualidade.

Há algumas palavras essenciais para entender a metodologia Scrum por inteiro, e a principal delas é o Product Backlog. Vamos falar mais sobre isso a seguir.

Product Backlog

O Product Backlog é a relação das principais entregas de um projeto ágil, priorizadas e sequenciadas conforme o nível de valor que podem gerar para o cliente. Quanto mais importante for a entrega, maior a urgência em começar a desenvolvê-la. Esses itens podem ser chamados de entregas, requisitos, funcionalidades, histórias ou User Stories, e em geral correspondem a uma atividade a ser colocada em prática ao longo do projeto.

Sendo assim, a função do Product Backlog é descrever o trabalho previsto de maneira organizada e flexível, servindo como consulta para todos os integrantes do Time Scrum.

Webinar Como priorizar os itens do backlog

Diferente do que acontece ao utilizar uma metodologia tradicional para gerenciar projetos (como a Cascata), ao utilizar o Scrum o escopo do projeto vai sendo definido aos poucos, e não já no começo. Isso explica por que o Product Backlog nunca está completo.

Conforme o produto vai sendo usado e ganha valor, o mercado vai fornecendo feedback e o Product Owner refina o Product Backlog, acrescentando e retirando funcionalidades da lista, atribuindo novas prioridades e adicionando detalhes aos itens abstratos. A essência do Scrum é justamente essa adaptabilidade e flexibilidade em relação aos requisitos e funcionalidades presentes no projeto.

Ao começar a desenvolver um software, é muito difícil que a empresa saiba exatamente como o mercado vai reagir — por isso, testar hipóteses é uma parte indispensável do processo, e o Scrum é perfeito para organizá-lo.

Durante a Reunião de Planejamento da Sprint, da qual falaremos mais em breve, o Time Scrum irá selecionar todos os itens mais prioritários do Product Backlog que conseguirem completar durante o período da Sprint (isto é, os que estiverem no topo da lista). O conjunto dos itens selecionados para a Sprint dá origem a um outro artefato do Scrum, chamado de Backlog da Sprint. Mas isso já é assunto para outro tópico.

Agora, vamos entender como se faz um Product Backlog. Acompanhe!

Como fazer o Product Backlog?

Primeiro, é necessário que o Product Owner (que detém toda a responsabilidade sobre o artefato) identifique os desejos do cliente e transforme-os em funcionalidades executáveis pelo Time de Desenvolvimento.

Para que isso seja possível, ele pode recorrer às histórias (ou User Stories, em inglês), que nada mais são do que as necessidades específicas do cliente que o produto se propõe a atender. Observe no exemplo abaixo:

Exemplo de Product Backlog

Cada item da lista corresponde a um desejo dos usuários de uma solução. O administrador, o membro e o visitante apresentam necessidades diferentes dentro do mesmo produto, as quais o Product Owner identifica e descreve na própria linguagem do cliente.

A partir dessa relação de funcionalidades, o Time Scrum pode se reunir para entender a relevância de cada uma, definir a prioridade e em qual Sprint elas serão entregues. Cada time pode escolher como prefere sinalizar a prioridade de uma história. Alguns utilizam Storypoints com os números de Fibonacci, outros utilizam escalas mais superficiais (com indicadores como “alta”, “média” e “baixa”), enfim, depende da complexidade do projeto e da quantidade de histórias que compõem o projeto.

É preciso destacar, porém, que o Product Backlog não tem a obrigação de ser feito em lista, essa é apenas uma das várias formas de organizá-lo. Você pode desenvolver o seu por meio de um quadro com post-its, em um documento no Word ou até mesmo em um software específico de gerenciamento de projetos.

O mais importante na construção deste artefato é que ele seja acessível a todo o Time Scrum e possa ser facilmente modificado, já que está em constante refinamento.

Tendo esclarecido o que é o Product Backlog e como desenvolvê-lo, podemos seguir para o próximo ponto que, segundo o Scrum, é o início da Sprint.

Sprint

Sprint, no Scrum, é um período de tempo limitado a um mês ou menos, no qual uma versão incremental e usável de um produto é desenvolvida.

Esse conceito vem do termo Sprint, em inglês, que se refere a um tipo de corrida de velocidade em que o atleta percorre uma distância curta num período de tempo mais curto ainda. Sendo assim, a ideia da Sprint no Scrum é que deve-se cumprir uma meta dentro de um período determinado, e que ao final o produto seja “Pronto”.

A duração da Sprint é time-boxed, isto é, limitada a um tempo, e pode variar de uma a quatro semanas, dependendo da produtividade do time para entregar uma funcionalidade completa (no caso dos projetos de TI) ou uma parte funcional do produto (em projetos de outras áreas). Porém, uma vez decidida a duração da Sprint, ela deve ser mantida até o final do projeto.

Assim, conforme a definição de o que é um projeto, a Sprint pode até ser considerada um projeto, já que tem delimitação de tempo, um plano de execução e um padrão de resultado esperado.

Curioso para saber como a Sprint é realizada na prática? Veja a seguir!

Como fazer uma Sprint?

Para fazer uma Sprint, além do momento da execução, há 4 Eventos: a reunião de planejamento da Sprint, a reunião diária, a reunião de revisão da Sprint e a retrospectiva da Sprint. Participam desses eventos, em maior ou menor grau, os componentes do Time Scrum, que são:

  • O Product Owner: também conhecido como PO ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento. Também é ele quem tem a responsabilidade de gerenciar o Backlog do Produto, de ordená-lo e garantir que o Time de Desenvolvimento entenda os itens no nível necessário.
  • O Scrum Master: é o responsável por garantir que o Scrum seja entendido e aplicado corretamente pelo PO e pelo Time de Desenvolvimento. Ele age como facilitador dos eventos do Time Scrum, treinando os desenvolvedores em autogerenciamento, interdisciplinaridade e criação de produtos de alto valor. Além disso, o Scrum Master remove os impedimentos para o progresso do Time de Desenvolvimento.
  • O Time de Desenvolvimento: é composto pelos profissionais que realizam o trabalho de entregar uma versão usável e que incremente o produto pronto no final da Sprint. Deve ter duas características: ser auto organizado e multifuncional. Não há sub-times dentro dessa estrutura, todos são considerados desenvolvedores, independentemente de sua função, e o tamanho do time varia entre 3 a 9 participantes.

Tendo esclarecido quais são os papéis necessários em cada Sprint, vamos entender quais são os eventos realizados dentro dela para saber como fazê-la:

1. Reunião de Planejamento da Sprint

A Reunião de Planejamento da Sprint (Sprint Planning) é um evento que acontece antes de cada Sprint, tendo como objetivo definir:

  • O que poderá ser entregue na próxima Sprint;
  • e

  • Como será realizado o trabalho para produzir a entrega.
  • Todos os integrantes do Time Scrum participam desta reunião, sendo que o time-box máximo é de 8 horas de duração. Em Sprints menores, a duração tende a ser proporcionalmente menor.
    O Product Owner começa a reunião apresentando os itens do Backlog do Produto (ou Product Backlog, que acabamos de apresentar, e o Time de Desenvolvimento avalia quais itens poderão ser entregues no período.

    Estabelece-se a meta da Sprint, que corresponde ao(s) item(s) do Backlog do Produto, e o Time de Desenvolvimento então decide como irá construir as funcionalidades necessárias.
    Para isso, o Time começa a desenhar o sistema e separar o trabalho em unidades de um dia de duração ou menos, podendo inclusive convidar outras pessoas para participar da Reunião e contribuir com opinião técnica.

    Como resultado, é produzido o Backlog da Sprint (ou Sprint Backlog), que é a junção dos itens selecionados do Backlog do Produto e seus respectivos planos de entrega.

    2. Desenvolvimento (execução)

    Assim que a Reunião de Planejamento da Sprint termina, inicia-se a etapa de execução. Aqui, o Time de Desenvolvimento começa a trabalhar segundo os planos de entrega que planejou, atentando-se aos requisitos de produto delineados pelo Product Owner e ao prazo final da Sprint.

    Como comentamos, a duração dessa etapa deve ser de no mínimo uma semana e no máximo quatro, podendo variar de acordo com a produtividade da equipe. O importante é que o tempo seja em função de semanas exatas, para facilitar o monitoramento.

    3. Reunião Diária

    Ao longo da execução da Sprint, o Time de Desenvolvimento se reúne diariamente para avaliar como está o andamento das atividades e definir o que será feito no dia para alcançar a meta da Sprint. São as chamadas Reuniões Diárias (também conhecidas como Daily Sprints ou Daily Scrum).

    O time-box dessas reuniões é de 15 minutos, e elas são comumente realizadas no mesmo local e no mesmo horário. Recomenda-se que o time de Desenvolvimento faça a Reunião Diária em pé, para não correr o risco de se acomodar e ultrapassar o limite de tempo.

    É bom lembrar, também, que o Product Owner e o Scrum Master não participam dessas reuniões ativamente, podendo apenas assistir a elas como ouvintes, já que o Time de Desenvolvimento é auto organizado e tem autonomia para decidir sozinho como o trabalho será realizado.
    Há três perguntas que devem ser respondidas na Reunião Diária:

    • O que eu fiz ontem que ajudou o time de Desenvolvimento a alcançar a meta da Sprint?
    • O que eu farei hoje para ajudar o time de Desenvolvimento a alcançar a meta da Sprint?
    • Existe algum obstáculo que impeça o Time de Desenvolvimento de alcançar a meta da Sprint?

    Pode-se utilizar recursos como o Gráfico de Burndown ou Burnup para monitorar a produtividade e identificar desvios rapidamente.

    representação do gráfico de burndown

    Gráfico de Burndown
    Imagine, por exemplo, que o Time de Desenvolvimento foi checar o Gráfico de Burndown (acima) no meio da Sprint e percebeu que o desempenho estava dois dias atrasado. Se esse ritmo continuasse, o produto final da Sprint não seria concluído no prazo.

    Por meio da comunicação em equipe, o Time identificou que havia um obstáculo no meio do caminho, e uma vez que o elimina, o desempenho volta ao normal.

    O responsável por eliminar os impedimentos que atrapalham o trabalho do Time de Desenvolvimento é o Scrum Master. Quando é comunicado a ele que algo está errado, ele é quem deve agir buscando soluções e alternativas, cumprindo com o seu objetivo principal de proporcionar um ambiente favorável para o Time de Desenvolvimento.

    Se o problema identificado for técnico demais e o Scrum Master sentir que não conseguirá solucioná-lo sozinho, ele pode pedir ajuda a um dos membros do Time que saiba como resolvê-lo.

    Em geral, as dificuldades reportadas pelos desenvolvedores envolvem problemas na infraestrutura de TI (problemas no computador, na rede de internet ou outras ferramentas de trabalho), interrupções por parte de pessoas que não fazem parte do Time Scrum (um Diretor querendo conversar sobre algo fora do projeto, por exemplo) ou mesmo a dificuldade em executar alguma tarefa técnica, indicando a necessidade de trabalhar em pares.

    Com a Daily Scrum, o Time pode identificar e contornar essas dificuldades rapidamente, evitando que problemas simples afetem as entregas do projeto por muito tempo.

    4. Revisão da Sprint

    Quando a Sprint chega ao final, é necessário realizar a Revisão da Sprint (ou Sprint Review) para inspecionar o resultado e adaptar o Backlog do Produto, se for o caso. Todo o Time Scrum participa do Evento, que tem time-box máximo de 4 horas.

    Os principais pontos de discussão da Revisão envolvem o esclarecimento sobre os itens que foram “Prontos” e os que não foram, a reflexão sobre o que foi bem e os problemas que foram encontrados, e as sugestões do Time Scrum para o que deve ser feito a seguir, levando em consideração as mudanças do mercado, a linha do tempo, o orçamento e as prioridades.

    Como resultado dessa reunião é produzida uma nova versão do Backlog do Produto, que poderá ser utilizada na próxima Sprint.

    5. Retrospectiva da Sprint

    Enquanto a Revisão da Sprint busca avaliar o produto do trabalho do Time de Desenvolvimento, a Retrospectiva da Sprint (Sprint Retrospective) é uma oportunidade para que a equipe avalie a si mesma, refletindo sobre suas práticas e desenhando melhorias para aplicar na próxima Sprint.

    Participam dessa reunião o Time de Desenvolvimento e o Scrum Master, que tem a responsabilidade de ensinar a equipe a seguir o processo Scrum e a ficar dentro do time-box de, no máximo, três horas.

    Ele encoraja a equipe a melhorar o processo de desenvolvimento de acordo com o framework do Scrum, ajudando-a a planejar formas de aumentar a qualidade do produto e a adaptar a definição de “Pronto”.

    Desse modo, no final da Retrospectiva da Sprint, o produto será a relação das melhorias a serem implementadas no próximo ciclo. O final desta reunião marca o final oficial da Sprint.

    A figura a seguir mostra o processo da Sprint de maneira resumida:

    Resumo de como uma sprint funciona

    Depois de todo esse trabalho, talvez você esteja se perguntando se adotar as Sprints no desenvolvimento de seus projetos realmente vale a pena. Acompanhe o próximo tópico e confira a resposta!

    Por que adotar Sprints na rotina de projetos?

    Como você viu, o principal objetivo de se trabalhar em Sprints é o constante acompanhamento das entregas do projeto, garantindo maior satisfação dos clientes com o resultado final.

    Ao contrário do que ocorre nas metodologias preditivas (como a Cascata), onde se planeja tudo de uma vez e há apenas uma entrega ao final do projeto, as Sprints quebram o trabalho em partes menores, fazendo com que a equipe possa ir definindo os pacotes de trabalho ao longo da execução.

    Justamente por esse motivo, os atrasos e inconformidades nas entregas das Sprints são significativamente menores do que os apresentados em outras metodologias. O time tem mais consciência sobre os prazos, pois participa ativamente das reuniões de planejamento, e pode comunicar-se internamente quando sentir que não conseguirá cumpri-lo, procurando alternativas e evitando desvios antes que eles tragam consequências sérias para o projeto.

    Outro motivo pelo qual a Sprint é uma boa opção para projetos de TI é o fato de que ela obriga os participantes a priorizarem as atividades que eles têm para executar antes do início de cada ciclo de trabalho.

    Essa atitude pode revelar tarefas que não façam mais sentido para o produto final depois de um tempo, ou mesmo chamar a atenção da equipe para aspectos que precisem de um esforço extra na hora da execução.

Qual o papel do Product Owner?

Product Owner, ou Dono do Produto, é encarregado de conectar a equipe de desenvolvedores aos pedidos dos clientes. Sua principal responsabilidade é gerenciar o Product Backlog, mantê-lo atualizado e manter todo o Time Scrum ciente dele. Mas seu papel não se resume apenas a isso. Veja:

Planejamento da Sprint

A reunião de planejamento marca o início de toda Sprint, e apesar de ser um momento desgastante e cansativo (principalmente em Sprints maiores), é indispensável para manter todo o Time Scrum alinhado.

O papel do Product Owner nesse evento é apresentar os itens do Product Backlog priorizado ao Time de Desenvolvedores, os quais selecionam as histórias mais prioritárias que couberem na Sprint. Não é papel do Product Owner, porém, pressionar a equipe ou escolher por ela quais atividades deverão ser feitas, afinal, isso fere o princípio de auto organização presente no Scrum.

Sua função é atuar como motivador e facilitador do processo, criando metas desafiadoras e solucionando dúvidas técnicas do Time de Desenvolvedores, já que ele é um especialista no produto que gerencia e está constantemente renovando seus conhecimentos.

Definir critérios de aceitação de histórias

Os critérios de aceitação de histórias são geralmente compostos por uma lista de itens a serem checados na nova funcionalidade para avaliar se ela foi desenvolvida conforme os requisitos do PO e do usuário. Eles são utilizados na Revisão da Sprint para que o PO valide ou invalide a entrega feita pelo time.

Frequentemente, os critérios envolvem: usabilidade, navegabilidade, responsividade, desempenho e ocorrência de bugs. Ao longo da Sprint, todos os membros do Time de Desenvolvimento têm conhecimento desses critérios, e inclusive operam Testes de Aceitação antes de concluir a entrega, para garantir que os resultados estarão adequados aos requisitos do Product Owner.

Aceitar/reprovar incrementos na Sprint

Assim que a equipe de desenvolvimento chega ao final da Sprint e demonstra a funcionalidade que desenvolveu e testou, é o Product Owner quem tem o poder de aceitá-la ou reprová-la. Como mencionamos há pouco, isso acontece no evento de Revisão da Sprint (ou Sprint Review).

Desse modo, o PO garante a qualidade das entregas, comparando o resultado do trabalho da equipe com os critérios de aceitação já definidos anteriormente. Se há inadequações no produto entregue, o PO sugere melhorias e adiciona-as ao Backlog do Produto. Dependendo de sua relevância, elas são selecionadas e executadas nas Sprints seguintes.

Agora, vamos ao segundo papel que compõe o Time Scrum, o Scrum Master.

Qual o papel do Scrum Master?

O termo Scrum Master significa mestre do Scrum, então para desempenhar esse papel, ele precisa ser familiar com o processo de Scrum e saber como realizá-lo corretamente, já que ele será como um guia para o Time Scrum. Ele atua em todos os setores do processo de Scrum, desde planejar a Sprint junto com o Product Owner, entre outros.

O perfil ideal de um Scrum Master é baseado na ideia de líder servidor, um tipo de gestor que faz mais do que monitorar o andamento do processo e o desempenho das equipes. Continue lendo, pois vamos te explicar o que é um líder servidor.

Líder servidor

Esse conceito se baseia na ideia de que liderar é também servir. Um líder que apenas cobra das equipes e não ajuda, não colabora na execução de um processo, recebe resultados de baixa qualidade e se afasta de seus colaboradores.

Porém, quando o líder se engaja em um processo e se dispõe a ajudar as equipes, prestando atenção às suas necessidades e problemas, quando ele se propõe a servir ao mesmo passo que lidera, o processo produtivo flui mais naturalmente e com menos imprevistos. O líder ocupa uma posição importante na empresa e entre seus colaboradores, e sua atuação causa fortes impactos.

O Scrum Master precisa agir como líder servidor porque sua função consiste basicamente em disponibilizar todo o conhecimento e materiais necessários para que os Sprints sejam executados corretamente. Ele age como um coach para o Time Scrum, tirando dúvidas e ajudando a resolver problemas que podem aparecer, e também para o Product Owner, para que ele consiga ter uma boa visão do objetivo e de como ele pode proceder de acordo com o processo Scrum.

Como você pode ver, a figura de um Scrum Master é muito importante na gestão de projetos, e ser um líder servidor é um requisito, e não uma responsabilidade. Por isso, vamos falar sobre as principais responsabilidades do Scrum Master.

Se todo o processo de Scrum ocorresse perfeitamente, o Scrum Master não seria necessário. Por isso, ele só interfere em algum processo quando necessário, ou seja, quando o Time Scrum está com dificuldade para realizar um Sprint, quando o Product Owner está se distanciando do objetivo a ser alcançado, entre outros motivos.

Desse modo, boa parte das ações do Scrum Master são indiretas, ou seja, sem afetar diretamente o processo produtivo do Time Scrum ou as decisões do Product Owner. Em geral, as ações diretas serão focadas em ajudar a lidar com algum problema e oferecer conselhos quando a situação ameaça fugir do controle. Mas essas não são as únicas oportunidades que o Scrum Master tem para ajudar a equipe. Confira as outras:

Facilitar os Sprints

Como já mencionamos, o Scrum Master conhece os processos de um Scrum, ele sabe quais são as melhores práticas e que tipo de decisão tomar em cada caso. Por isso, ele deve passar esse conhecimento ao Time Scrum, para que eles saibam como proceder em cada situação.
É importante deixar claro que o Scrum Master não determina quem deve fazer cada Sprint e de que jeito. Ele dá liberdade às equipes para trabalharem do modo que acharem correto e disponibiliza os recursos necessários, além de dar aconselhamento e direcionamento quando lhe for pedido.

Ajudar o Product Owner

O Product Owner é designado de acordo com seus conhecimentos no tema do projeto, e por isso pode acontecer que ele não esteja familiarizado com as práticas de Scrum. Nesses casos, a ajuda do Scrum Master é importante para adaptá-lo a essa metodologia.

Além disso, o Scrum Master é o principal canal de comunicação entre Product Owner e Time Scrum quando ela não vai bem. Ele ajuda a equipe a entender a visão e a meta desejada pelo Product Owner, ao passo que faz com que ele compreenda as limitações e considerações da equipe.

Eliminar empecilhos

Um Scrum é realizado em um cenário de muitos riscos, já que muitas vezes os projetos são inovadores e nunca foram realizados antes, e consequentemente são desconhecidos, inclusive porque o modo incremental de trabalho, apesar de rápido e eficiente, é como dar passos no escuro.

Por isso, imprevistos vão acontecer, alguns Sprints podem dar errado, e mudanças serão necessárias quando o projeto já estiver encaminhado. Diante dessa incerteza, o Scrum Master precisa resolver os empecilhos que cruzam o caminho do Time Scrum, além de fazer o possível para evitar mais acidentes. Ele faz isso pensando à frente de cada processo, planejando cuidadosamente cada Sprint e estando sempre à disposição do Time Scrum e do Product Owner.

Conectar todo o projeto

Uma das funções mais importantes do Scrum Master é criar conexões, não apenas entre os integrantes do Scrum, mas também conexões externas com os gestores da empresa, com fontes úteis para a execução de Sprints, com soluções de possíveis empecilhos, entre outras.

Além disso, o Scrum Master ajuda na realização dos Daily Scrums e no planejamento do Sprint seguinte, buscando sempre alinhar as funcionalidades que devem ser priorizadas e os feedbacks do Product Owner e o Time Scrum. Essas reuniões são muito importantes para mensurar o progresso do projeto e que mudanças devem ser feitas.

Qual o papel do Time de Desenvolvimento?

O terceiro e último papel do Scrum é o Time de Desenvolvimento, a equipe que põe a mão na massa para entregar os incrementos do produto.

Segundo o Guia Scrum, é indicado que o Time de Desenvolvimento tenha entre 5 a 9 integrantes, e que não ultrapasse esse número para não dificultar o gerenciamento.

Além disso, o manual recomenda que não haja segmentações dentro da equipe, isto é, que não se separe os desenvolvedores por funções (arquiteto, designer, programador, testador, DBA etc.). Dessa forma, garante-se um sentimento de unidade à equipe, que deve se responsabilizar pelo cumprimento das atividades como um time, e não como uma pessoa específica. O esforço e os resultados do trabalho (sejam eles positivos ou negativos) são atribuídos a todo o Time de Desenvolvimento, sendo assim, espera-se que os integrantes de mobilizem em prol do objetivo que têm em comum.

Às responsabilidades do Time de Desenvolvimento são:

Realizar a execução da Sprint

Como não poderia deixar de ser, o Time de Desenvolvimento detém a responsabilidade exclusiva de executar a Sprint, do início ao fim. Isso envolve os processos de concepção, desenvolvimento, teste e liberação das funcionalidades selecionadas na Reunião de Planejamento da Sprint.

É bom lembrar que o Time de Desenvolvimento é auto organizado, portanto, os membros devem se comunicar e decidir coletivamente os passos que darão para poder concluir as entregas conforme o combinado. A divisão das tarefas e o jeito que elas serão desenvolvidas é responsabilidade total do Time, mas se houver dúvidas e eles sentirem que precisam de ajuda, podem acionar o Scrum Master.

Inspeção e Adaptação

A inspeção e adaptação, que fazem parte dos princípios do Scrum, são garantidas por meio das Reuniões Diárias do Scrum. Estes momentos são quando o Time de Desenvolvimento se reúne para acompanhar o próprio desempenho, buscando saber se há algum impeditivo no caminho e adaptando o planejamento à realidade.

Se essas reuniões diárias não forem realizadas, o Time pode perder muito tempo “patinando” nas atividades erradas, tentando resolver problemas que o Scrum Master poderia resolver ou mesmo com dúvidas que um colega de equipe saiba responder.

Refinar o Product Backlog

Como você já sabe, o Product Backlog nunca está finalizado. Enquanto há Sprint acontecendo, o Time Scrum está aprendendo e refinando a lista constantemente.
Juntamente com o Product Owner e o Scrum Master, o Time de Desenvolvimento se encarrega de atualizar as estimativas de duração das atividades, re-priorizar demandas e adicionar detalhes às funcionalidades que estão pouco claras.

Planejar a Sprint

Além de atuar no refinamento e na execução da Sprint, o Time de Desenvolvimento deve também auxiliar no planejamento da Sprint, aquele momento em que se decide quais funcionalidades serão desenvolvidas no próximo período.

Como os desenvolvedores têm mais noção sobre sua produtividade, é interessante que tenham espaço para decidir o que poderão entregar, mas que também ouçam a opinião dos outros integrantes do Time Scrum.

De maneira resumida, essas são as responsabilidades e atribuições dos integrantes do Time Scrum.

Com o sucesso crescente do Scrum e das metodologias ágeis, muitos profissionais tem buscado se qualificar na área e obter certificações para serem reconhecidos no mercado. Pensando nisso, separamos um tópico só para te contar um pouco mais sobre as certificações Scrum. Aproveite!

Certificações Scrum, qual escolher?

Dependendo do momento da sua carreira, pode ser interessante optar por certificações mais ou menos avançadas.

A certificação ACP, por exemplo, é considerada uma das mais complexas, já que exige bastante experiência na área. Em contraponto, a certificação ASF é mais indicada caso o profissional esteja começando a ter contato com o Scrum e prefira fazer o exame em português.

A seguir, vamos abordar cada uma das certificações mais reconhecidas do mercado e explicar para quais perfis elas mais se aplicam.

Certified Scrum Master (CSM) pelo Scrum Alliance

É uma certificação de entrada que agrega bastante conhecimento específico sobre o framework, ajudando os profissionais a entenderem como o processo Scrum deve ser realizado, quais são os papéis, eventos e artefatos que o compõem e, principalmente, qual é o papel do Scrum Master nisso tudo.

Para obtê-la, é preciso fazer um curso presencial de 16 horas credenciado pela instituição, passar por um exame de 50 perguntas e obter pelo menos 37 acertos.

Professional Scrum Master (PSM I) pelo Scrum.org

O PSM I é uma certificação que não exige um curso credenciado, apenas que o participante passe por um teste específico sobre o Guia Scrum. Seu principal objetivo é comprovar o conhecimento do participante sobre as práticas do Scrum.

O teste, disponível apenas em inglês, é composto por 80 questões, e para poder respondê-lo, o profissional deve pagar uma taxa de U$150. A certificação é concedida se a pessoa atingir o número mínimo de acertos, que é 68.

A entidade que mantém essa certificação também oferece outras certificações mais avançadas, como a Professional Scrum Master II e III, Professional Scrum Product Owner I, Professional Scaled Scrum e Professional Scrum Developer, as quais são destinadas aos diferentes papéis dentro do Time Scrum.

Scrum Fundamentals Certified (SFC) pelo SCRUMstudy™

Esta certificação gratuita serve para o participante aprender mais sobre o Scrum, e é mantida pela organização responsável pelo Guia SBOK®, que é um corpo de conhecimento sobre Scrum mundialmente reconhecido.

Ao inscrever-se no curso online, o participante também tem acesso ao exame, que conta com 40 questões e pode ser repetido quantas vezes for necessário. Obtém-se a certificação mediante o acerto de pelo menos 30 questões, e ela tem validade de 3 anos.

Agile Scrum Foundation (ASF) pelo EXIN

A certificação Agile Scrum no nível Foundation oferecida pelo EXIN tem como principal benefício a credibilidade que essa entidade tem no mercado, afinal, o EXIN é reconhecido como um dos maiores institutos de exames de TI no mundo.

Além de atestar o conhecimento do profissional no framework Scrum, esta certificação também envolve o conhecimento em metodologias ágeis no geral.

Não há pré-requisitos para realizar o exame, é necessário apenas realizar o teste online que utiliza a própria webcam no participante para monitorá-lo. Se o profissional desejar continuar a formação, há mais um nível no sistema do EXIN, o Agile Scrum Master (ASM).

Agile Certified Practitioner (ACP) pelo PMI

O PMI, referência mundial em gerenciamento de projetos, oferece uma certificação especial para profissionais focados em metodologias ágeis: a Agile Certified Practitioner. Para consegui-la, o profissional deve comprovar 2.000 horas de experiência em equipes de projetos, 1.500 horas em equipes de projetos ágeis, 21 horas de curso relacionado a metodologias ágeis e realizar o exame aplicado pelo instituto.

O custo para inscrição é de U$495 e a certificação tem validade de 3 anos.

É bom lembrar, porém, que com esta certificação o profissional não terá conhecimento profundo sobre o Scrum, mas uma base sobre todos os frameworks e metodologias ágeis relevantes no mercado. Para quem já conhece o Scrum e busca se aprofundar no universo ágil, é uma boa alternativa.

Leia nosso Guia completo de certificações SCRUM para não restar dúvidas.