Papéis
O framework Scrum define principalmente três papéis cruciais: o Product Owner, o Scrum Master e a Equipe de Desenvolvimento. 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 servidor para a Equipe Scrum. 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. Seu papel principal é criar um equilíbrio onde a equipe possa 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 da Equipe de Desenvolvimento. Este papel representa os interesses das partes interessadas e dos clientes. O Product Owner gerencia o Backlog do Produto, definindo e priorizando seus itens, e garante que a equipe trabalhe nos recursos ou tarefas mais valiosos. Eles também representam a voz do cliente, garantindo que a equipe entenda as necessidades e desejos dos usuários.
Equipe de Desenvolvimento
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 Backlog do Produto, definindo e priorizando seus itens, e garante que a equipe trabalhe nos recursos ou tarefas mais valiosos. Eles também representam a voz do cliente, garantindo que a equipe entenda as necessidades e desejos dos usuários.
Projetos
As equipes utilizam projetos ou iniciativas para implementar mudanças significativas em um produto ou serviço. Eles frequentemente são baseados no princípio do Kaikaku, um termo japonês que significa ‘reforma radical’. Isso representa uma mudança substancial e transformadora para aprimorar o desempenho e a competitividade empresarial. Em contraste com a melhoria gradual e contínua vista no princípio do 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 de 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 planejamento para identificar as oportunidades mais promissoras para mudanças radicais.
- Colaboração: Incentivar a colaboração entre as diferentes áreas envolvendo todas as partes interessadas no processo de mudança.
- Inovação: eles abraçam e promovem o pensamento inovador e abordagens para impulsionar a mudança.
- Risco: eles estão dispostos a correr riscos calculados para alcançar mudanças transformadoras.
Épicos
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 um único sprint. Como resultado, eles são divididos em histórias de usuário menores que podem ser executadas em um ou mais sprints.
Product Backlog
O Product Backlog é uma lista abrangente de recursos, funções, requisitos, melhorias e correções que o produto precisa. É 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 pelo seu conteúdo, disponibilidade e ordenação.
Os itens no Product Backlog, frequentemente referidos como “Itens do Backlog” ou “Histórias do Usuário”, geralmente são escritos do ponto de vista 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 tome medidas.
Cada Item do Backlog 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 do usuário e fornecer valor ao negócio.
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 potencialmente liberável do produto ou valor tangível para o negócio. Sprints são um componente fundamental do Scrum, proporcionando um ritmo consistente de trabalho e entrega, ao mesmo tempo em que permitem que a equipe se adapte a requisitos em mudança e feedback das partes interessadas.
Cerimônias
Cada Sprint é marcado por uma série de cerimônias-chave. Essas cerimônias fornecem estrutura e ritmo ao trabalho da equipe, guiam 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 Objetivo do Sprint e adaptar o Backlog do Sprint conforme necessário.
- O que eles realizaram desde a última reunião
- O que eles planejam realizar antes da próxima reunião
- Quaisquer obstáculos que estão enfrentando
É recomendável 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. Sem o Scrum Master ou Product Owner, o Daily Scrum ainda deve ocorrer, pois a Equipe Scrum é autogerenciada. Discussões detalhadas ou refinamento do backlog devem ser feitos separadamente para manter esta reunião curta e focada.
Planejamento
O Planejamento do Sprint prepara o terreno para o Sprint, delineando o trabalho para o período seguinte. Este plano é desenvolvido de forma colaborativa por toda a Equipe Scrum. O Product Owner garante que os participantes estejam prontos para discutir os itens mais cruciais do Product Backlog e como eles se alinham com o Objetivo do Produto. A Equipe Scrum também pode convidar outras pessoas para fornecerem contribuições.
Para cada item selecionado do Product Backlog, a Equipe de Desenvolvimento planeja o trabalho necessário para criar um incremento que atenda à Definição de Pronto. Frequentemente, isso envolve dividir os itens do Product Backlog em tarefas menores que podem ser concluídas em um dia ou menos. Como essa divisão é realizada fica a critério exclusivo dos Desenvolvedores. O Objetivo do Sprint, os itens do Product Backlog selecionados para o Sprint e o plano de entrega compõem o Backlog do Sprint. O Planejamento do Sprint é limitado a um máximo de oito horas para um Sprint de um mês, com sprints mais curtos tendo reuniões proporcionalmente mais curtas. Por exemplo, o Planejamento do Sprint dura cerca de uma hora em um Sprint de duas semanas.
Refinamento do Backlog
O Refinamento do Backlog, ou grooming do backlog, é revisar e manter o backlog do produto ou projeto. Essa atividade regular e contínua envolve a equipe revisando tarefas e histórias de usuário 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 se concentrar em tarefas de alto 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 backlog do produto estejam claramente definidos, devidamente priorizados e prontos para desenvolvimento nos próximos sprints.
Ao refinar regularmente seu backlog, as equipes podem melhorar sua eficiência e eficácia, garantindo que estejam constantemente trabalhando nos itens mais valiosos e prontas para responder às mudanças em seu ambiente de negócios. O refinamento do backlog é um processo contínuo e não tem um limite de tempo estrito. No entanto, as equipes devem dedicar 10% do seu tempo às atividades de refinamento do backlog.
Revisão
A Revisão do Sprint é um momento para inspecionar o resultado do Sprint e determinar adaptações futuras. A Equipe Scrum apresenta os resultados de seu trabalho às principais partes interessadas, e o progresso em direção ao Objetivo do Produto é discutido.
Durante a Revisão do Sprint, a Equipe Scrum e as partes interessadas revisam o que foi alcançado durante o Sprint e o que mudou em seu entorno. Com base nessas informações, o grupo colabora nos próximos passos, possivelmente ajustando o Product Backlog para responder a novas oportunidades.
A Revisão do Sprint é uma reunião de trabalho, não apenas uma apresentação.
Para um Sprint de um mês, a Revisão do Sprint tem limite de tempo de no máximo quatro horas. Para sprints mais curtos, o evento é tipicamente mais curto. Por exemplo, a Revisão do Sprint dura aproximadamente 60 minutos para cada Sprint de duas semanas.
Retrospectiva
A Retrospectiva do Sprint ocorre no final de cada Sprint, proporcionando um momento para a equipe refletir sobre o que aconteceu, tanto positivo quanto negativo, durante o último Sprint. Também permite que a equipe avalie suas rotinas e processos para otimizar como trabalham juntos.
A Retrospectiva do Sprint ocorre no final de cada Sprint, proporcionando um momento para a equipe refletir sobre o que aconteceu, tanto positivo quanto negativo, durante o último Sprint. Também permite que a equipe avalie suas rotinas e processos para otimizar como trabalham juntos.
