Sua Jornada Começa Aqui
Bem-vindo ao guia abrangente de Scrum da Avanti Studio. Este artigo serve tanto como uma referência interna quanto como um recurso valioso para nossos clientes, oferecendo insights sobre o framework Scrum que forma a espinha dorsal de nossas metodologias Ágeis. Na Avanti Studio, não apenas implementamos Scrum – vivemos e respiramos seus princípios todos os dias. Nossa paixão por práticas Ágeis nos impulsiona a continuamente refinar e aperfeiçoar nosso processo Scrum, garantindo que entregamos um valor inigualável aos nossos clientes. Scrum é mais do que apenas uma metodologia de gerenciamento de projetos; é um framework poderoso 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 às mudanças de requisitos, fomentar a inovação e atender consistentemente às necessidades dos usuários no ambiente de negócios acelerado de hoje. Este guia fornece uma visão detalhada do framework Scrum conforme praticamos na Avanti Studio, incluindo:
- Principais funções e suas responsabilidades
- A estrutura dos projetos Scrum
- O conceito e a gestão do Product Backlog
- O uso de épicos e histórias para dividir o trabalho
- O ritmo e o propósito das sprints
- Cerimônias essenciais do Scrum e sua importância
Se você é novo no Scrum ou está procurando aprimorar suas práticas Ágeis existentes, este guia oferece insights valiosos extraídos de nossa vasta experiência. À medida que você explora cada componente do Scrum, você ganhará uma compreensão mais profunda de como esse framework pode transformar sua abordagem de gerenciamento de projetos e levar sua equipe a uma maior eficiência e sucesso. Vamos embarcar nesta jornada pelo mundo do Scrum, onde descobriremos os princípios e práticas que o tornam uma ferramenta tão poderosa para o desenvolvimento moderno de produtos.
Funções
O framework Scrum define principalmente três funções cruciais: o Product Owner, o Scrum Master e o Development Team. Cada uma dessas funções tem um conjunto único de responsabilidades, e todas devem trabalhar juntas de forma eficaz para garantir o sucesso do Scrum. A colaboração entre essas funções 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-servidor para o Scrum Team. Eles ajudam todos a entender e aplicar os princípios e valores do Scrum. Eles orientam, treinam e mentoram a equipe, removem obstáculos que possam impedir seu progresso e facilitam os eventos do Scrum quando necessário. Sua função principal é criar um equilíbrio onde a equipe pode ser mais produtiva, mantendo o framework 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 do Development Team. 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. Eles também representam a voz do cliente, garantindo que a equipe entenda as necessidades e desejos dos usuários.
Development Team
O Development Team é um grupo de profissionais responsáveis por entregar um Incremento potencialmente liberável de produto “Feito” no final de cada Sprint. Eles são auto-organizados, multifuncionais e detêm as decisões técnicas. Durante a reunião de Sprint Planning, a equipe decide colaborativamente como dividir o trabalho para um Sprint específico.
Projetos
As equipes utilizam projetos ou iniciativas para implementar mudanças significativas em um produto ou serviço. Elas geralmente se baseiam no princípio de Kaikaku, um termo japonês que significa “reforma radical.” Isso representa uma mudança substancial e transformadora para melhorar o desempenho e a competitividade empresarial. Em contraste com a melhoria contínua e gradual vista no princípio Kaizen, os projetos de 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: desenvolvimento de uma visão clara e convincente do objetivo da organização por meio da iniciativa.
- Pensamento estratégico: uso de pensamento e planejamento estratégico para identificar as oportunidades mais promissoras para mudanças radicais.
- Colaboração: incentivo à colaboração entre diferentes funções, envolvendo todas as partes interessadas no processo de mudança.
- Inovação: eles adotam e promovem o pensamento inovador e as abordagens criativas para impulsionar a mudança.
- Assunção de riscos: eles estão dispostos a assumir riscos calculados para alcançar uma mudança transformadora.
Ao incorporar esses princípios em projetos, uma empresa pode promover mudanças substanciais que impactam significativamente sua competitividade, desempenho e crescimento. Esses projetos ajudam a enfrentar desafios, aproveitar novas oportunidades e alcançar resultados inovadores que poderiam não ser atingidos por meio de abordagens mais incrementais.
Product Backlog
O Product Backlog é uma lista abrangente de funcionalidades, funções, requisitos, melhorias e correções que o produto necessita. É um documento dinâmico que evolui conforme as necessidades dos usuários e do negócio mudam.
O Product Owner gerencia o Product Backlog, sendo responsável por seu conteúdo, disponibilidade e ordenação.
Os itens no Product Backlog, frequentemente chamados de “Backlog Items” ou “User Stories”, são geralmente escritos da perspectiva do usuário final. Cada item deve fornecer valor aos usuários e ao negócio e deve ser claro e conciso o suficiente para que a equipe de desenvolvimento entenda e possa tomar providências.
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. É um documento vivo que reflete o trabalho necessário para melhorar o produto, atender às necessidades dos usuários e fornecer valor ao negócio.
Épicos
Um épico é uma importante user story 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 user stories menores que podem ser executadas ao longo de uma ou mais sprints.
Stories
Uma story, ou user story, é uma funcionalidade distinta e compacta que descreve um resultado específico ou valor que o produto deve entregar aos seus usuários.
Normalmente, as stories 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 em suas tarefas.
As user stories descrevem a funcionalidade que um produto ou recurso deve fornecer do ponto de vista do usuário final. Ao criar uma user story, é benéfico 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 concluída.
- N(Negociável): As user stories devem estar abertas a discussões e refinamentos, permitindo flexibilidade e adaptabilidade.
- V(Valiosa): Cada user story deve oferecer valor ao usuário final, contribuindo positivamente para a sua experiência.
- E(Estimável): Uma user story deve ser passível de estimativa em termos de esforço e complexidade, auxiliando no planejamento eficiente e na alocação de tarefas.
- S(Pequena): As user stories devem ser compactas o suficiente para serem concluídas em uma única sprint, promovendo foco e momentum.
- T(Testável): Cada user story deve ser verificável por meio de testes manuais ou automatizados, garantindo sua funcionalidade e confiabilidade.
Sprints
Uma sprint é um período definido, geralmente de duas semanas, durante o qual as equipes trabalham diligentemente para completar um conjunto selecionado de stories e entregar um incremento de produto potencialmente liberável ou um valor tangível para o negócio. As sprints são um componente fundamental do Scrum, proporcionando um ritmo consistente de trabalho e entrega, enquanto permitem que a equipe se adapte às mudanças de requisitos e ao feedback das partes interessadas.
Cerimônias
Cada sprint é marcada 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 ao Sprint Goal e adaptar o Sprint Backlog conforme necessário.
- O que foi realizado desde a última reunião
- O que planejam realizar antes da próxima reunião
- Quaisquer obstáculos que estão enfrentando
É recomendado que cada membro da equipe compartilhe sua tela para mostrar suas tarefas e comentar sobre seu progresso, promovendo a participação ativa na reunião. Mesmo sem a presença do Scrum Master ou Product Owner, o Daily Scrum deve ocorrer, pois a equipe Scrum é autogerenciável. Discussões mais detalhadas ou refinamento do backlog devem ser feitos separadamente para manter esta reunião curta e focada.
Planning
O Sprint Planning estabelece o cenário para a Sprint, delineando o trabalho para o próximo período. Esse plano é desenvolvido de forma colaborativa por toda a equipe Scrum. O Product Owner garante que 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 outras pessoas para fornecer contribuições.
Para cada item do Product Backlog escolhido, a equipe de desenvolvimento planeja o trabalho necessário para criar um incremento que atenda à Definição de Pronto. Frequentemente, isso envolve a divisão dos itens do Product Backlog em tarefas menores que possam ser concluídas em um dia ou menos. Como essa divisão é realizada fica a critério exclusivo dos Desenvolvedores. O Sprint Goal, os itens do Product Backlog selecionados para a Sprint e o plano de entrega compõem o Sprint Backlog. O Sprint Planning tem um tempo limite de até oito horas para uma Sprint de um mês, com sprints mais curtas tendo reuniões proporcionalmente menores. Por exemplo, o Sprint Planning dura cerca de uma hora em uma Sprint de duas semanas.
Refinamento do Backlog
O Refinamento do Backlog, ou grooming do backlog, é a revisão e manutenção do backlog do produto ou projeto. Essa atividade regular e contínua 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 em sua importância e relevância para o projeto.
O Refinamento do Backlog garante que o backlog permaneça atualizado, relevante e adequadamente estruturado, ajudando a equipe a focar em tarefas de alto valor e a 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 estejam claramente definidos, devidamente priorizados e prontos para o desenvolvimento nas próximas sprints.
Ao refinar regularmente o backlog, as equipes podem melhorar sua eficiência e eficácia, garantindo que estejam constantemente trabalhando nos itens de maior valor e prontas para responder às mudanças no ambiente de negócios. O refinamento do backlog é um processo contínuo e não tem um tempo fixo. No entanto, as equipes devem dedicar 10% de seu tempo às atividades de refinamento do backlog.
Review
A Sprint Review é um momento para inspecionar o resultado da Sprint e determinar adaptações futuras. A equipe Scrum apresenta os resultados de seu trabalho para as principais partes interessadas, e o progresso em direção ao Product Goal é discutido.
Durante a Sprint Review, a equipe Scrum e as partes interessadas revisam o que foi alcançado durante a Sprint e o que mudou no ambiente. Com base nessas informações, o grupo colabora nos próximos passos, possivelmente ajustando o Product Backlog para responder a novas oportunidades. A Sprint Review é uma reunião de trabalho, não apenas uma apresentação.
Para uma Sprint de um mês, a Sprint Review tem um tempo limite de até quatro horas. Para sprints mais curtas, o evento é normalmente mais breve. Por exemplo, a Sprint Review dura aproximadamente 60 minutos para cada Sprint de duas semanas.
Retrospective
A Sprint Retrospective ocorre no final de cada Sprint, proporcionando um momento para a equipe refletir sobre o que aconteceu, tanto positivo quanto negativo, durante a última 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 modelo padrão usado no Notion para conduzir a Sprint Retrospective, onde os participantes indicam o que foi bem, o que poderia ter sido melhor e quais práticas devem continuar. Qualquer questão que precise de acompanhamento sugere que esse item deve gerar uma tarefa. O Scrum Master é responsável por garantir que essas tarefas sejam criadas no backlog da respectiva equipe.