Scrum

Sua Jornada Começa Aqui

Bem-vindo ao guia completo da Avanti Studio sobre Scrum. Este artigo serve tanto como uma referência interna quanto um recurso valioso para nossos clientes, oferecendo insights sobre a estrutura Scrum que forma a espinha dorsal de nossas metodologias Ágeis. Na Avanti Studio, não implementamos apenas o Scrum – nós vivemos e respiramos seus princípios todos os dias. Nossa paixão pelas práticas Ágeis nos impulsiona a aprimorar e aperfeiçoar continuamente nosso processo Scrum, garantindo que entreguemos um valor incomparável aos nossos clientes. Scrum é mais do que uma metodologia de gerenciamento de projetos; é uma estrutura poderosa que permite às equipes entregar produtos de alto valor de forma iterativa e incremental. Ao adotar o Scrum, as organizações podem se adaptar rapidamente a requisitos em mudança, fomentar a inovação e atender de forma consistente às necessidades dos usuários no ambiente de negócios acelerado de hoje. Este guia fornece uma visão geral detalhada da estrutura Scrum como a praticamos na Avanti Studio, incluindo:

Papéis principais e suas responsabilidades
A estrutura dos projetos Scrum
O conceito e gerenciamento do Product Backlog
O uso de épicos e histórias para dividir o trabalho
O ritmo e propósito dos sprints
Cerimônias Scrum essenciais e sua importância

Se você é novo no Scrum ou está buscando aprimorar suas práticas Ágeis existentes, este guia oferece insights valiosos derivados de nossa ampla experiência. À medida que você explora cada componente do Scrum, você entenderá mais profundamente como essa estrutura pode transformar sua abordagem de gerenciamento de projetos e impulsionar sua equipe em direção à maior eficiência e sucesso. Vamos embarcar nesta jornada pelo mundo do Scrum, onde desvendaremos os princípios e práticas que o tornam uma ferramenta poderosa para o desenvolvimento de produtos modernos.

Papéis

A estrutura Scrum define principalmente três papéis cruciais: o Product Owner, o Scrum Master e a Development Team. Cada um desses papéis tem um conjunto único de responsabilidades, e todos devem trabalhar juntos de forma eficaz para garantir o sucesso do Scrum. A colaboração entre esses papéis forma a base de qualquer projeto Scrum e ajuda a entregar produtos de alto valor de forma iterativa e incremental.

Scrum Master

O Scrum Master é um líder-serviço para a equipe Scrum. Ele ajuda todos a entender e aplicar os princípios e valores do Scrum. O Scrum Master orienta, treina e apoia a equipe, remove obstáculos que possam impedir seu progresso e facilita os eventos Scrum quando necessário. O papel principal do Scrum Master é criar um equilíbrio onde a equipe possa ser mais produtiva, mantendo a estrutura Scrum e protegendo a equipe de interrupções externas.

Product Owner

O Product Owner é um papel estratégico responsável por maximizar o valor do produto resultante do trabalho da equipe de desenvolvimento. Este papel representa os interesses das partes interessadas e dos clientes. O Product Owner gerencia o Product Backlog, definindo e priorizando seus itens, e garante que a equipe trabalhe nas funcionalidades ou tarefas mais valiosas. Ele também representa a voz do cliente, garantindo que a equipe entenda as necessidades e desejos dos usuários.

Development Team

A Development Team é um grupo de profissionais responsáveis por entregar um incremento do produto “pronto” ao final de cada Sprint. Eles são auto-organizados, multifuncionais e possuem a autoridade para tomar decisões técnicas. Durante a reunião de Sprint Planning, a equipe decide colaborativamente como dividir o trabalho para o Sprint.

Projetos

As equipes usam projetos ou iniciativas para implementar mudanças significativas em um produto ou serviço. Eles são frequentemente baseados no princípio do Kaikaku, um termo japonês que significa “reforma radical”. Isso representa uma mudança substancial e transformadora para melhorar o desempenho e a competitividade dos negócios. Em contraste com a melhoria gradual e contínua observada no princípio Kaizen, os projetos Kaikaku visam alcançar mudanças grandes, ousadas e disruptivas que impactam substancialmente a organização.

Aqui estão alguns elementos chave dos projetos baseados em Kaikaku:

Visão ousada: desenvolver uma visão clara e convincente do objetivo da organização por meio da iniciativa.
Pensamento estratégico: usar o pensamento estratégico e o planejamento para identificar as oportunidades mais promissoras para mudanças radicais.
Colaboração: incentivo à colaboração multifuncional envolvendo todas as partes interessadas no processo de mudança.
Inovação: abraçar e promover o pensamento e abordagens inovadoras para impulsionar a mudança.
Assunção de riscos: disposição para assumir riscos calculados para alcançar uma mudança transformadora.

Ao incorporar esses princípios nos projetos, uma empresa pode impulsionar mudanças substanciais que impactam significativamente sua competitividade, desempenho e crescimento. Esses projetos ajudam a enfrentar desafios, aproveitar novas oportunidades e alcançar resultados revolucionários que podem não ter sido alcançados por abordagens mais incrementais.

Product Backlog

O Product Backlog é uma lista abrangente de funcionalidades, requisitos, melhorias e correções que o produto necessita. É um documento dinâmico que evolui conforme as necessidades dos usuários e da empresa mudam.

O Product Owner gerencia o Product Backlog, sendo responsável pelo seu conteúdo, disponibilidade e organização.

Os itens no Product Backlog, frequentemente chamados de “Backlog Items” ou “User Stories”, são normalmente escritos sob a perspectiva do usuário final. Cada item deve fornecer valor para os usuários e para os negócios, e deve ser claro e conciso o suficiente para que a equipe de desenvolvimento entenda e tome as ações necessárias.

Cada Backlog Item precisa ser estimado, geralmente em termos de esforço ou complexidade. Isso ajuda a equipe a planejar o trabalho para cada Sprint e fornece uma maneira de medir o progresso do produto ao longo do tempo.

O Product Backlog nunca está completo. Enquanto o produto existir, algo novo pode ser adicionado ao backlog. Ele é um documento vivo que reflete o trabalho necessário para melhorar o produto, atender às necessidades dos usuários e fornecer valor para o negócio.

Epics

Um épico é uma história de usuário importante e de alto nível que descreve uma modificação ou adição significativa ao produto. Devido à sua escala e complexidade, os épicos geralmente são grandes demais para serem concluídos em uma única sprint. Como resultado, eles são divididos em histórias menores que podem ser executadas ao longo de uma ou mais sprints.

Stories

Uma história, ou uma user story, é um pedaço distinto e compacto de funcionalidade que descreve um resultado específico ou valor que o produto deve entregar aos seus usuários.

Normalmente, as histórias são formuladas da seguinte maneira: “Como [usuário], eu quero [funcionalidade] para que [benefício].”

Elas capturam os requisitos do produto e guiam a equipe de desenvolvimento nas suas tarefas.

User stories descrevem a funcionalidade que um produto ou recurso deve fornecer sob a perspectiva do usuário final. Ao criar uma user story, é útil seguir os critérios INVEST:

I(Independente): Cada user story deve ser autossuficiente, ou seja, não deve depender de outras user stories para ser completa.
N(Negociável): As user stories devem estar abertas à discussão e refinamento, permitindo flexibilidade e adaptabilidade.
V(Valiosa): Cada user story deve oferecer valor ao usuário final, contribuindo positivamente para sua experiência.
E(Estimável): Uma user story deve ser possível de ser estimada em termos de esforço e complexidade, auxiliando no planejamento eficiente e na alocação de tarefas.
S(Compacta): As user stories devem ser compactas o suficiente para serem concluídas dentro de uma única sprint, promovendo foco e impulso.
T(Testável): Cada user story deve ser verificável por meio de testes manuais ou automatizados, garantindo sua funcionalidade e confiabilidade.

Sprints

Um sprint é um período definido, geralmente de duas semanas, durante o qual as equipes trabalham diligentemente para concluir um conjunto selecionado de histórias e entregar um incremento do produto ou valor tangível para o negócio. Os sprints são um componente fundamental do Scrum, proporcionando uma cadência consistente de trabalho e entrega, enquanto permitindo que a equipe se adapte a requisitos em mudança e feedback das partes interessadas.

Cerimônias

Cada Sprint é pontuada por uma série de cerimônias chave. Essas cerimônias fornecem estrutura e ritmo ao trabalho da equipe, orientam a colaboração e promovem transparência, inspeção e adaptação, que são valores essenciais do Scrum.

Daily Scrum

O Daily Scrum é um evento de 15 minutos para os desenvolvedores da equipe Scrum, com o objetivo de inspecionar o progresso em direção à Meta do Sprint e adaptar o Sprint Backlog conforme necessário.

O que foi realizado desde a última reunião
O que se pretende realizar antes da próxima reunião
Quais obstáculos estão sendo enfrentados

Recomenda-se que cada membro da equipe compartilhe sua tela para mostrar suas tarefas e comentar sobre seu progresso, promovendo participação ativa na reunião. Mesmo sem o Scrum Master ou Product Owner, o Daily Scrum deve acontecer, já que a equipe Scrum é auto-gerenciável. Discussões mais aprofundadas ou refinamentos do backlog devem ser feitos separadamente para manter essa reunião curta e focada.

Planning

O Sprint Planning define a base para o Sprint, delineando o trabalho para o próximo período. Este plano é desenvolvido colaborativamente por toda a equipe Scrum. O Product Owner garante que todos os participantes estejam prontos para discutir os itens mais importantes do Product Backlog e como eles se alinham com o Product Goal. A equipe Scrum também pode convidar outros para fornecer contribuições.

Para cada item selecionado do Product Backlog, a equipe de desenvolvimento planeja o trabalho necessário para criar um incremento que atenda à Definition of Done. Frequentemente, isso envolve a divisão dos itens do Product Backlog em tarefas menores que podem ser concluídas em um dia ou menos. Como essa divisão é realizada depende exclusivamente dos desenvolvedores. O Sprint Goal, os itens do Product Backlog selecionados para o Sprint e o plano de entrega formam o Sprint Backlog. O Sprint Planning tem duração máxima de 8 horas para um Sprint de um mês, com sprints mais curtos tendo reuniões proporcionalmente mais curtas. Por exemplo, o Sprint Planning dura cerca de uma hora em um Sprint de duas semanas.

O Backlog Refinement, ou grooming do backlog, é o processo de revisar e manter o backlog do produto ou projeto. Essa atividade contínua e regular envolve a equipe revisando tarefas e user stories no backlog, esclarecendo detalhes, estimando o esforço necessário e priorizando sua execução com base na importância e relevância para o projeto.

O Backlog Refinement garante que o backlog permaneça atualizado, relevante e bem estruturado, ajudando a equipe a focar nas tarefas de maior valor e alinhar seu trabalho com os objetivos do produto.

Nesta reunião, o Product Owner, o Scrum Master e a equipe de desenvolvimento colaboram para garantir que os itens do product backlog sejam claramente definidos, adequadamente priorizados e prontos para o desenvolvimento nas sprints futuras.

Ao refinar regularmente o backlog, as equipes podem melhorar sua eficiência e eficácia, garantindo que estão constantemente trabalhando nos itens mais valiosos e prontas para responder a mudanças em seu ambiente de negócios. O Backlog Refinement é um processo contínuo e não tem um limite de tempo rígido. No entanto, as equipes devem gastar 10% do seu tempo em atividades de refinamento do backlog.

Review

O Sprint Review é um momento para inspecionar os resultados do Sprint e determinar adaptações futuras. A equipe Scrum apresenta os resultados do seu trabalho para as partes interessadas chave, e o progresso em direção ao Product Goal é discutido.

Durante o Sprint Review, a equipe Scrum e as partes interessadas revisam o que foi alcançado durante o Sprint e o que mudou no seu ambiente. Com base nessas informações, o grupo colabora sobre os próximos passos, possivelmente ajustando o Product Backlog para responder a novas oportunidades. O Sprint Review é uma reunião de trabalho, não apenas uma apresentação. Para um Sprint de um mês, o Sprint Review tem duração máxima de 4 horas. Para sprints mais curtos, o evento é geralmente mais curto. Por exemplo, o Sprint Review dura cerca de 60 minutos para cada Sprint de duas semanas.

Retrospective

A Sprint Retrospective ocorre ao final de cada Sprint, proporcionando um momento para a equipe refletir sobre o que aconteceu, tanto de positivo quanto de negativo, durante o último Sprint. Ela também permite que a equipe avalie suas rotinas e processos para otimizar a forma como trabalham juntos.

Este template do Notion possui um template padrão utilizado dentro do Notion para realizar a Sprint Retrospective, onde os participantes indicam o que deu certo, o que poderia ter sido melhor e quais práticas devem continuar. Qualquer problema que precise de acompanhamento sugere que esse item gere uma tarefa. O Scrum Master é responsável por garantir que essas tarefas sejam criadas no backlog da equipe respectiva.

Maximize a Eficiência da Equipe com Scrum