Scrum, Kanban e Scrumban: o minimo que voce precisa saber.pdf

F. R. Alff
SCRUM
KANBAN E
SCRUMBAN
O MÍNIMO QUE VOCÊ PRECISA SABER

SCRUM, KANBAN E
SCRUMBAN
O mínimo que você precisa saber
3

Este livro é resultado da iniciativa do portal
AnalisedeRequisitos.com.br
O livro "Scrum, Kanban e Scrumban: O
mínimo que você precisa saber" é fruto de uma
iniciativa singular do site
AnalisedeRequisitos.com.br, referência em conteúdo
de qualidade para profissionais da área de análise de
requisitos.
A idealização e viabilização da obra
demonstram o compromisso do site em contribuir
para a comunidade de gerenciamento de projetos,
fornecendo materiais relevantes e práticos que
atendam às demandas do mercado.
Reconhecendo a lacuna de materiais
abrangentes e práticos sobre a metodologia
Scrumban, o site Analisederequisitos.com.br se
dedicou à produção de um livro que fosse além da
teoria, oferecendo aos leitores uma visão
aprofundada e contextualizada da aplicação do
Scrumban em projetos reais.
5

Para garantir a excelência do conteúdo, a
equipe do site, composta por profissionais
experientes em análise de requisitos e
gerenciamento de projetos, cuidadosamente
selecionou o autor, Francilvio Roberto Alff (Chico
Alff), especialista com vasta experiência prática na
metodologia Scrumban.
Durante todo o processo de produção, desde
a pesquisa e escrita até a revisão e edição, a equipe
do site acompanhou de perto o trabalho do autor,
garantindo que o livro atendesse aos mais altos
padrões de qualidade e rigor técnico.
O resultado é um material completo e de fácil
acesso, com mais de 200 páginas, que oferece aos
leitores:
Uma introdução abrangente ao Scrumban: O
livro apresenta os fundamentos da metodologia,
seus princípios e valores, e as principais diferenças
entre Scrum e Kanban.
Um guia prático para implementação do
Scrumban: O autor fornece instruções passo a passo
6

para a implementação da metodologia em
diferentes contextos, desde a criação do backlog até
a realização de retrospectivas.
O autor oferece sugestões práticas para melhorar o
desempenho das equipes, como técnicas de
estimativa de esforço, ferramentas de visualização e
indicadores de desempenho.
O livro "Scrum, Kanban e Scrumban: O mínimo que
você precisa saber" se destaca como um recurso
valioso para profissionais que buscam:
● Aprimorar suas habilidades e conhecimentos
em gerenciamento de projetos ágeis.
● Implementar a metodologia Scrumban em
seus projetos de forma eficaz.
● Aumentar a produtividade e o desempenho
das equipes.
● Obter melhores resultados na entrega de
projetos.
7

Este livro é um exemplo de como o site se dedica a
fornecer materiais relevantes e práticos que
contribuem para o aprimoramento profissional e o
sucesso dos projetos.
8

SUMÁRIO
Metodologias Ágeis................................................................................16
Metodologias pesadas e ágeis....................................................................19
Manifesto Ágil de 2001.....................................................................................30
Princípios do manifesto ágil........................................................................36
Scrum................................................................................41
Mecânica e Processos..................................................................................... 44
Papéis do Scrum.................................................................................................49
Scrum Master................................................................................................ 51
Product Owner............................................................................................53
Scrum Team.................................................................................................. 55
Cerimônias do Scrum.......................................................................................57
Sprint Planning............................................................................................61
Daily Scrum Meeting..............................................................................64
Sprint Review............................................................................................... 67
Sprint Retrospective................................................................................69
Artefatos do Scrum.............................................................................................71
Product Backlog.........................................................................................74
Sprint Backlog............................................................................................. 77
Sprint Burndown.......................................................................................80
TaskBoard.......................................................................................................87
TaskBoard vs Kanban Board..............................................................92
Funcionamento do Scrum TaskBoard........................................95
Refinamento do backlog do produto...................................................98
Backlog grooming........................................................................................... 103
SCRUM: Monitorando o desempenho................................................106
10

Scrum Team Capacity............................................................................110
Quantidade de entregas.......................................................................111
Velocidade atual e média do time................................................ 112
Velocity Chart...............................................................................................115
Gestão do Débito Técnico..................................................................120
Entusiasmo da Equipe.......................................................................... 121
Melhoria no Processo Retrospectivo.......................................... 122
Sucesso nas metas dos sprint.........................................................124
Kanban......................................................................................................127
Princípios Fundamentais do Kanban..................................................132
Os Papéis do Kanban..................................................................................... 138
Mecânica e Processo...................................................................................... 146
Artefatos do Kanban........................................................................................152
Kanban Board............................................................................................154
Stream Value Map...................................................................................159
Velocidade de entrega......................................................................... 162
KANBAN: Monitorando desempenho.................................................169
Production Lead Time...........................................................................171
Takt time........................................................................................................173
Customer Lead Time............................................................................. 175
Throughput..................................................................................................178
Work in Progress (WIP)....................................................................... 180
Filas (pulls)....................................................................................................182
Bloqueios ou bloqueadores (blockers).....................................184
Cadência (cadence)................................................................................186
SCRUMBAN............................................................................................. 188
Mecânica e Processos...................................................................193
Scrumban Flow.......................................................................207
Planning e Daily Meetings.................................................................213
Comparativo Scrum-Kanban-Scrumban........................................ 226
11

Papéis do Scrumban......................................................................................230
Scrumban para times Scrum................................................................... 233
Quando adotar o Scrumban...........................................................242
Sobre o Autor................................................................. 246
12

SCRUM, KANBAN e SCRUMBAN

Metodologias Ágeis
Não há bala de prata, nem receita de bolo
O desenvolvimento de software é um ramo de
estudo da engenharia de computação com o
objetivo de orientar todos os indivíduos envolvidos
em um projeto para práticas e métodos que
melhorem as probabilidades de sucesso do próprio
projeto.
Ao longo do tempo, vários modelos de
desenvolvimento de software foram propostos, com
resultados variáveis em relação ao tamanho do
projeto, à equipe de desenvolvimento, ao tempo e
aos recursos financeiros disponíveis. A tarefa do
modelo é gerenciar efetivamente o orçamento, o
tempo disponível, a comunicação e interação entre
os desenvolvedores, a compreensão completa dos
requisitos e todas as fases que compõem o processo
de desenvolvimento.
Em todos os setores, são conduzidos estudos
para analisar as disparidades entre uma empresa de
Chico Alff - 14

qualquer setor e as empresas de maior sucesso no
mercado de referência, a fim de compreender os
processos empresariais que conduzem a resultados
ótimos de maneira eficiente.
Infelizmente, ou felizmente, o
desenvolvimento de software
é um processo distinto em
relação à produção:
utilizando uma analogia com
o mundo culinário,
poderíamos afirmar que o
desenvolvimento de software se assemelha a um
chef de cozinha em um restaurante de culinária
experimental, que cria um prato, enquanto a
produção de um produto tradicional é por sua vez
similar ao de um chef em um restaurante que
oferece apenas pratos executivos, seguindo uma
receita da maneira mais precisa possível.
Essa simples analogia destaca como o
desenvolvimento de software está vinculado à
criatividade e à experiência, enquanto a produção é
um processo repetitivo e mecânico. Naturalmente,
aprimorar um processo produtivo é mais simples:
após analisar as diversas etapas e identificar os
Chico Alff - 15

pontos críticos, é possível estudar um sistema que
torne a produção mais eficiente, intervindo nessas
questões.
Chico Alff - 16

Metodologias pesadas e ágeis
A tarefa de estudar e
compreender sistemas mais
eficientes para o
desenvolvimento de
software não é algo fácil, pois
a eficácia do método está
relacionada não apenas à
estrutura organizacional,
mas também à cultura empresarial e ao método
operacional adotado pela equipe de
desenvolvimento. Por esse motivo, existem
numerosos métodos ligados ao desenvolvimento de
software que compartilham objetivos semelhantes,
mas apresentam configurações completamente
distintas.
De maneira geral, o processo de
desenvolvimento de software é caracterizado pelas
seguintes fases ou etapas em seu ciclo de vida:
Chico Alff - 17

● Levantamento, análise, especificação e
gerenciamento de requisitos
● Definição de arquitetura e solução tecnológica
● Desenvolvimento ou codificação do sistema
● Análise e execução de testes e garantia de
qualidade
● Deployment ou implantação em ambiente de
produção
Cada modelo de desenvolvimento de software
é distintivo pelas especificações que oferece para
cada uma das fases do ciclo de vida mencionado
anteriormente.
Não há um modelo que seja mais eficaz que
os outros em todas as situações (no cenário de
desenvolvimento de software não há bala de prata
ou receita de bolo), a escolha da metodologia e do
método mais apropriados para o sistema em
questão torna-se, portanto, um fator decisivo para o
sucesso do produto final.
Chico Alff - 18

Os métodos empregados no desenvolvimento
de software encontram inspiração em práticas
previamente utilizadas no contexto da produção de
bens físicos, como em sistemas de produção que
seguem métodos como o da linha de produção.
A transposição de princípios da produção para
o desenvolvimento possibilita a aplicação de
abordagens semelhantes, embora seja crucial
observar a necessidade de adaptação das práticas.
Isso ocorre devido à natureza universal dos
princípios, os quais mantêm sua validade em
diversas circunstâncias, enquanto as práticas
demandam ajustes para sua efetiva aplicação no
domínio específico do desenvolvimento de software
A consideração cuidadosa e a customização
das práticas derivadas da produção são essenciais
para assegurar uma integração bem-sucedida e
eficiente desses princípios no cenário particular do
desenvolvimento de software.
As principais metodologias de
desenvolvimento de software podem ser
categorizadas da seguinte maneira:
Chico Alff - 19

● Metodologias pesadas (por exemplo, modelo
em cascata)
● Metodologias iterativas (por exemplo, modelo
em espiral)
● Metodologias ágeis (por exemplo, Scrum, XP,
Kanban, ...)
Nos últimos anos, as metodologias ágeis
experimentaram uma ampla adoção. O estudo
"VersionOne State of Agile Development Survey
2013" relata que em 2013 muitas equipes de
desenvolvimento se beneficiaram do uso de uma
metodologia ágil:
● 88% dos entrevistados afirmam que sua
empresa utiliza uma metodologia ágil.
● 92% dos entrevistados observaram melhorias
ano após ano em todas as áreas identificadas
pelo questionário.
● Em particular, as categorias em que houve
melhorias incluem habilidade para lidar com
mudanças (92%), aumento de produtividade
Chico Alff - 20

(87%), maior visibilidade do projeto (86%),
maior motivação da equipe (86%) e melhor
qualidade do software (82%).
Os motivos desse sucesso podem ser
identificados nos princípios fundamentais da
metodologia ágil:
● Satisfazer o cliente entregando software de
valor imediatamente e de forma contínua é a
máxima prioridade da equipe.
● Os projetos são fundamentados em
indivíduos motivados, aos quais é fornecido o
ambiente e suporte necessários, confiando-se
em sua capacidade de concluir o trabalho.
● Aceitam-se mudanças nos requisitos, mesmo
em estágios avançados do desenvolvimento.
● Os processos ágeis são orientados para
explorar as mudanças em benefício da
vantagem competitiva do cliente.
● Entregas fracionadas focadas em
funcionalidades, com intervalos variando de
Chico Alff - 21

algumas semanas a alguns meses,
preferindo-se prazos curtos.
● Ao longo do projeto, é esperado e necessário
que clientes e desenvolvedores colaborem
diariamente.
● A comunicação eficiente e eficaz é realizada
por meio de conversas cara a cara, tanto com
a equipe quanto internamente.
● O progresso é medido principalmente pelo
software funcional.
● Os processos ágeis promovem um
desenvolvimento sustentável, onde
patrocinadores, desenvolvedores e usuários
devem ser capazes de manter um ritmo
constante indefinidamente.
● A atenção contínua à excelência técnica e ao
design sólido realça a agilidade, enquanto se
destaca a essencialidade da simplicidade - a
arte de maximizar o trabalho não realizado.
Esses fundamentos são contrapostos aos das
metodologias pesadas, que, por sua vez, favorecem
Chico Alff - 22

uma abordagem mais clássica do ponto de vista do
gerenciamento empresarial.
Uma metodologia ágil é composta por um
conjunto de práticas que produzem bons resultados
quando aplicadas de forma simultânea. O foco de
cada metodologia ágil reside na qualidade e na
comunicação, tanto com o cliente quanto entre os
membros da equipe de desenvolvimento.
O resultado desse enfoque é a entrega de um
serviço pelo qual, frequentemente, o cliente se
mostra mais satisfeito em comparação com um
serviço gerado seguindo uma metodologia pesada.
A necessidade de adaptar o software às
demandas do cliente e à constante evolução das
ferramentas e técnicas de desenvolvimento de
software constitui um estímulo adicional para as
empresas adotarem um método ágil.
É importante observar que entre os princípios
ágeis não há referência à organização interna ou à
estrutura hierárquica. A atenção está totalmente
voltada para a comunicação e colaboração. O
desenvolvimento de software, de fato, não é
concebido para reproduzir resultados repetíveis, mas
Chico Alff - 23

sim para fornecer soluções adequadas e
personalizadas para o cliente.
Uma iteração consiste em um incremento útil
do software, planejado, programado, testado,
integrado e liberado em um curto período de tempo.
O software será aprimorado com o decorrer
das iterações, mas já está funcional desde o primeiro
lançamento. As iterações permitem ter um feedback
contínuo com o cliente, enquanto nos métodos
pesados o feedback só ocorre no lançamento final.
As iterações desempenham um papel crucial
na comunicação não apenas com o cliente, mas
também entre os membros da equipe de
desenvolvimento.
Após a conclusão de uma funcionalidade, é
necessário integrá-la ao sistema para criar um
produto uniforme e funcional [3]. Além disso, as
interações permitem uma melhor gestão das
mudanças.
Ter prazos conhecidos para a entrega parcial
do software possibilita intercalar a implementação
com o planejamento, proporcionando momentos
Chico Alff - 24

para avaliar alterações em relação aos planos
estabelecidos anteriormente. Gerenciar a mudança
também implica em documentá-la. Um desafio
comum das metodologias pesadas é ter uma
documentação detalhada, mas excessivamente
extensa e difícil de gerenciar e modificar.
As metodologias ágeis favorecem uma
documentação mais concisa que contenha todas as
informações necessárias para fazer o projeto
funcionar, embora seja possível expandir os limites
da documentação conforme as necessidades da
equipe de desenvolvimento.
A ideia é implementar um conjunto coerente
de funcionalidades a cada iteração. Uma
funcionalidade é uma atividade que adiciona valor
ao software do ponto de vista do cliente, mas é
suficientemente pequena para permitir que a
equipe de desenvolvimento estime com precisão o
tempo de implementação.
Quando uma funcionalidade é muito
complexa para ser lançada em uma única iteração,
ela deve ser dividida em funcionalidades menores.
Chico Alff - 25

As constantes modificações no software para
introduzir novas funcionalidades, no entanto, correm
o risco de minar a estabilidade do produto. Por esse
motivo, equipes ágeis fazem amplo uso de testes.
Estes são úteis para comunicar de forma inequívoca
quais funcionalidades são esperadas e também
garantem que todas as partes do software
funcionem corretamente, assegurando que o
sistema atenda efetivamente às expectativas.
A prática de realizar todos os testes antes de
cada lançamento é conhecida como integração
contínua e é difundida em todos os métodos ágeis.
Além de garantir a qualidade do software, os testes
também constituem documentação sobre o design
do mesmo.
De fato, a documentação dos métodos
pesados frequentemente se mostra inútil, pois não
reflete o verdadeiro design do software; por vezes, a
documentação não é atualizada durante a
implementação, tornando-se obsoleta
imediatamente.
Em contrapartida, substituir parte da
documentação pelos testes evita esse problema,
Chico Alff - 26

uma vez que os testes, para serem úteis, precisam
ser sempre atualizados.
Chico Alff - 27

Manifesto Ágil de 2001
A engenharia de software é uma atividade
com complexidade muitas vezes assustadora,
repleta de situações condicionantes em
imprevisíveis em seus processos, porém dinâmica e
criativa, repleta de desafios técnicos, organizacionais
e humanos.
Para enfrentar esses desafios, ao
longo dos anos, diversas
abordagens, metodologias e
práticas surgiram, todas voltadas
para orientar e simplificar o
processo de concepção, entrega e
manutenção de software de alta qualidade.
A agilidade no desenvolvimento de software
se fundamenta em valores e princípios que
enfatizam a colaboração, adaptação, satisfação do
cliente e entrega constante de software funcional.
Chico Alff - 28

A agilidade emergiu como resposta às
limitações e complexidades dos modelos
tradicionais de desenvolvimento, tidos como
burocráticos, inflexíveis e ineficazes.
O Manifesto Ágil, criado em 2001 por 17
profissionais que já praticavam métodos ágeis como
XP, Scrum, DSDM, FDD, entre outros, é um
documento que condensa os valores e princípios da
agilidade.
Ele representa não apenas uma declaração de
intenções, mas também uma proposta de
transformação na abordagem ao desenvolvimento
de software, fomentando uma cultura de
aprendizado, melhoria contínua e entrega de valor.
Este documento contém os valores
fundamentais e os princípios originais que delineiam
a abordagem ágil para o desenvolvimento de
software. Versão original do Manifesto para
Desenvolvimento Ágil de Software em inglês:
Manifesto for Agile Software Development
Chico Alff - 29

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
● Individuals and interactions over processes
and tools
● Working software over comprehensive
documentation
● Customer collaboration over contract
negotiation
● Responding to change over following a
plan
That is, while there is value in the items on the
right, we value the items on the left more.
A seguir reproduzimos a tradução em língua
portuguesa do Manifesto para Desenvolvimento Ágil
de Software de 2001, conforme disponibilizado no
próprio site oficial. Esta tradução oferece uma
compreensão direta e fiel dos princípios
fundamentais delineados pelos criadores do
Manifesto.
Manifesto para o Desenvolvimento Ágil de Software
Chico Alff - 30

Estamos descobrindo maneiras melhores de
desenvolver software, fazendo-o nós mesmos e
ajudando outros a fazerem o mesmo. Através
deste trabalho, passamos a valorizar:
● Indivíduos e interações mais que
processos e ferramenta
● Software em funcionamento mais
que documentação abrangente
● Colaboração com o cliente mais
que negociação de contratos
● Responder a mudanças mais que
seguir um plano
Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.
Os responsáveis pela criação do manifesto
foram 17 profissionais da área de tecnologia,
especificamente do desenvolvimento de software,
que se reuniram para discutir as melhores práticas,
processos e compartilhar impeditivos frequentes
durante o ciclo de vida de um projeto, produto ou
software. Os signatários do Manifesto Ágil de 2001
são:
Chico Alff - 31

1. Kent Beck
2. Mike Beedle
3. Arie van Bennekum
4. Alistair Cockburn
5. Ward Cunningham
6. Martin Fowler
7. James Grenning
8. Jim Highsmith
9. Andrew Hunt
10. Ron Jeffries
11. Jon Kern
12. Brian Marick
13. Robert C. Martin
14. Steve Mellor
15. Ken Schwaber
16. Jeff Sutherland
17. Dave Thomas
Chico Alff - 32

Esse grupo de 17 profissionais reconhecidos
notoriamente pela comunidade de desenvolvedores
ao redor do mundo, compartilhavam de uma
mesma visão: o desenvolvimento de software
deveria ser mais adaptável às mudanças, mais
focado nas necessidades dos clientes e mais
orientado a resultados. Por isso, eles elaboraram o
Manifesto Ágil, que contém quatro valores e doze
princípios que orientam a aplicação de métodos
ágeis como Scrum, Kanban, XP, entre outros.
Descubra todos os segredos para otimizar
seu fluxo de trabalho com Scrumban!
Explore exemplos práticos, um guia passo a
passo e aplicações do mundo real no artigo
exclusivo disponível no portal Análise de
Requisitos.
Acesse: https://analisederequisitos.com.br/scrumban
Chico Alff - 33

Princípios do manifesto ágil
Os autores do documento declaram
adicionalmente em seu site oficial 12 princípios que
direcionam e fundamentam a abordagem por eles
proposta.
Esses princípios definem uma forma
inovadora e adaptável de atender às necessidades
do cliente, priorizando a entrega frequente e
antecipada de software que gere valor.
A flexibilidade é um aspecto essencial, pois
reconhece que as mudanças nos requisitos são
inevitáveis e podem ocorrer mesmo em fases
avançadas do desenvolvimento.
Princípios por trás do Manifesto Ágil
Nós seguimos estes princípios:
1. Nossa maior prioridade é satisfazer o
cliente através da entrega contínua e
Chico Alff - 34

adiantada de software com valor
agregado.
2. 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.
3. Entregar frequentemente software
funcionando, de poucas semanas a poucos
meses, com preferência à menor escala de
tempo.
4. Pessoas de negócio e desenvolvedores
devem trabalhar diariamente em conjunto
por todo o projeto.
5. Construa projetos em torno de indivíduos
motivados. Dê a eles o ambiente e o
suporte necessário e confie neles para
fazer o trabalho.
6. O método mais eficiente e eficaz de
transmitir informações para e entre uma
equipe de desenvolvimento é através de
conversa face a face.
7. Software funcionando é a medida primária
de progresso.
Chico Alff - 35

8. Os processos ágeis promovem
desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e
usuários devem ser capazes de manter um
ritmo constante indefinidamente.
9. Atenção contínua à excelência técnica e
bom design aumenta a agilidade.
10. Simplicidade (a arte de maximizar a
quantidade de trabalho não realizado) é
essencial.
11. As melhores arquiteturas, requisitos e
designs emergem de equipes
auto-organizáveis.
12. Em intervalos regulares, a equipe reflete
sobre como se tornar mais eficaz e então
refina e ajusta seu comportamento de
acordo.
Nos 12 princípios que endossam o Manifesto
Ágil, fica claro o direcionamento defendido pelo
grupo: processo centrado no cliente, valorizando a
entrega contínua e antecipada de software de
qualidade.
Chico Alff - 36

A preocupação com a colaboração e
comunicação face a face entre uma equipe
genuinamente motivada, a aceitação de mudanças
nos requisitos mesmo em estágios avançados e a
busca pela excelência técnica são elementos-chave
que promovem um desenvolvimento sustentável e
adaptável.
Requisitos.
Chico Alff - 37


Chico Alff - 38

Scrum

O framework Scrum foi concebido em 1995
por Jeff Sutherland e Ken Schwaber e é o método
ágil que tem obtido mais sucesso entre as empresas
nos últimos anos. Duas características fundamentais
que contribuíram para seu sucesso são a distinção
de papéis e a escalabilidade.
Jeff Sutherland é um dos pioneiros do
desenvolvimento ágil de software e um dos
criadores do Scrum. Ele é formado em medicina pela
Universidade do Colorado e tem um doutorado em
biofísica pela Universidade de Stanford. Começou
sua carreira como piloto de caça na Força Aérea dos
Estados Unidos, onde aprendeu sobre liderança,
trabalho em equipe e processos complexos.
Ken Schwaber é outro co-criador do Scrum e
um dos fundadores da Agile Alliance, uma
Chico Alff - 39

organização sem fins lucrativos dedicada a promover
os princípios e práticas do desenvolvimento ágil. Ele
é formado em matemática e ciência da computação
pela Universidade de Rhode Island e tem mais de 30
anos de experiência em desenvolvimento de
software. Ele é autor de vários livros sobre Scrum,
como Agile Software Development with Scrum,
Agile Project Management with Scrum e The
Enterprise and Scrum.
Em 2010 publicaram a primeira
versão do Guia do Scrum, um
documento que define os
conceitos, papéis, eventos e
artefatos do método Scrum. Eles
continuam a atualizar o Guia do
Scrum periodicamente,
incorporando as melhores práticas e lições
aprendidas da comunidade ágil mundial.
De fato, as especificações do Scrum definem
papéis precisos para os participantes, facilitando
assim a adaptação da estrutura hierárquica de uma
empresa ao método Scrum. Modelos ágeis
alternativos, como o Extreme Programming (XP), são
mais livres de restrições e, portanto, mais
Chico Alff - 40

desafiadores de integrar a uma típica estrutura
hierárquica empresarial.
Uma discussão que provoca uma ligeira
divisão entre opiniões da comunidade ágil é a
escalabilidade do framework, mesmo que seja
comum definir o Scrum como uma metodologia
recomendado a times de pequeno porte
(aproximadamente uma dezena de pessoas), é
possível, com alguns ajustes, aplicar o Scrum
também a grupos de trabalho maiores.
Chico Alff - 41

Mecânica e Processos
Scrum é uma metodologia iterativa e
incremental baseada no controle empírico do
processo. Ele é incremental, pois o produto final
resulta de lançamentos contínuos, cada um dos
quais adiciona valor ao anterior.
É interativo, pois cada novo lançamento é
adaptado com base nas contingências do momento,
seus fundamentos incluem um processo de
desenvolvimento com fases bem caracterizadas,
uma definição precisa de papéis e uma série de
rituais.
O Scrum se caracteriza por uma fase inicial de
coleta de funcionalidades para o projeto, solicitadas
pelo cliente e apresentadas por meio de User Stories.
Uma User Story é uma breve descrição de como o
usuário pretende usar a funcionalidade desejada.
Chico Alff - 42

A decisão de quais User Stories aceitar é
exclusiva do Product Owner, que as insere no
Product Backlog.
Dentro do Product Backlog, as User Stories
podem ser subdivididas ainda mais pela equipe de
desenvolvimento para criar requisitos menores.
A intenção é tornar o esforço necessário para a
implementação de cada requisito adaptável aos
prazos das iterações.
Posteriormente, o Product Owner seleciona,
entre os requisitos identificados no Product Backlog,
aqueles que deseja desenvolver na próxima iteração
da fase de desenvolvimento.
Os requisitos relacionados a uma única
iteração são chamados de Sprint Backlog, e cada
iteração é definida como um Sprint: um período de
tempo geralmente entre duas e quatro semanas,
durante o qual os requisitos inseridos no Sprint
Backlog são desenvolvidos.
Cada Sprint inclui a implementação de novas
funcionalidades e seus respectivos testes. O Sprint é
a fase mais crítica para o desenvolvimento, portanto,
Chico Alff - 43

não são permitidas alterações no Sprint Backlog e no
Scrum Team até o seu término.
Ao final do Sprint, ocorre uma fase de revisão
chamada Sprint Review, onde os resultados obtidos
são analisados, incluindo o que deu errado durante a
fase de desenvolvimento.
O objetivo é melhorar o processo de
desenvolvimento para iterações futuras e garantir
que as expectativas do cliente tenham sido
atendidas. Além disso, compreender quanto valor foi
adicionado ao produto a cada iteração motiva os
Chico Alff - 44

membros da Scrum Team e aumenta o interesse no
projeto.
Nesta fase, a equipe verifica a qualidade da
versão por meio de testes, assegurando a
continuidade do funcionamento geral do software e
a correção do que foi produzido durante o Sprint.
Uma vez concluída a fase de Sprint Review,
retorna-se ao Product Backlog para selecionar os
requisitos a serem implementados no próximo
Sprint. Pode parecer que no Scrum há pouca
planejamento; no entanto, essa impressão é devida
ao fato de que o planejamento não é realizado de
forma completa antes de começar a implementar os
requisitos, mas é diluído ao longo do Sprint.
Um time típico do Scrum gasta 8 horas para
planejar a iteração e, em seguida, ajusta o
planejamento durante as Daily Meetings (15 minutos
por 30 dias).
Se considerarmos uma equipe de 5 pessoas,
descobrimos que o planejamento requer um esforço
de 40 horas-pessoa por iteração, além de outras 40
horas-pessoa de planejamento espalhadas nos
próximos 30 dias. O tempo dedicado ao
Chico Alff - 45

planejamento é significativamente maior em
comparação com outros métodos, considerando um
padrão hipotético de 30 dias de desenvolvimento
trabalhados pelo time.
Chico Alff - 46

Papéis do Scrum
Um time Scrum é estruturado de forma
colaborativa, composto por diferentes papéis, cada
um desempenhando funções específicas que
contribuem para a entrega eficaz e contínua de valor
ao cliente.
Essa metodologia favorece uma abordagem
flexível e adaptativa, priorizando a comunicação
transparente e a colaboração entre os membros da
equipe.
● Scrum Master: Atua como facilitador e
guardião dos princípios ágeis, removendo
obstáculos e promovendo a cultura de
melhoria contínua.
● Product Owner: Representante dos interesses
do cliente, é responsável pela definição de
prioridades e pelo alinhamento do produto
com as necessidades do cliente.
Chico Alff - 47

● Scrum Team: Desenvolvedores
multifuncionais que colaboram para a entrega
eficaz das funcionalidades, contribuindo para
uma abordagem iterativa, transparente e
centrada no valor entregue ao cliente.
Cada membro desse conjunto colaborativo
contribui de maneira única para a dinâmica do
desenvolvimento ágil, promovendo uma cultura de
melhoria contínua e adaptação às mudanças
.
Requisitos.
Chico Alff - 48

Scrum Master
O papel do Scrum Master em uma equipe
Scrum é crucial para garantir o bom andamento do
processo e a maximização do potencial da equipe.
Atuando como facilitador e guardião dos princípios
ágeis, o Scrum Master desempenha uma função
vital ao remover obstáculos que possam prejudicar o
progresso da equipe, indo além da gestão
tradicional.
Seu foco está na criação de um ambiente
propício à colaboração, promovendo uma cultura de
melhoria contínua que estimula a evolução
constante da equipe.
Ao contrário do Project Manager, o Scrum
Master é comparado a um "capitão do time" e não a
um técnico. Sua responsabilidade central é
assegurar que as engrenagens do processo
continuem funcionando adequadamente,
prevenindo ou solucionando problemas que possam
Chico Alff - 49

impactar a equipe e comprometer sua
produtividade e organização.
Além disso, o Scrum Master desempenha um
papel ativo no suporte ao Product Owner durante a
priorização e documentação das demandas,
promovendo a harmonia e fluidez no trabalho do
Scrum Team.
O Scrum Master também desempenha um
papel crucial na garantia da visibilidade das
informações sobre o desempenho da equipe e na
evolução do projeto.
Organizando e liderando as cerimônias do
Scrum, como a daily meeting, sprint planning e
sprint review, ele facilita a comunicação e a
colaboração dentro da equipe, contribuindo para um
ambiente transparente e eficiente que favorece o
sucesso do projeto.
Chico Alff - 50

Product Owner
No Scrum, o Product Owner se destaca como
o representante direto dos interesses do cliente. Sua
atuação é essencial na definição das prioridades do
produto, garantindo uma sintonia precisa entre o
desenvolvimento e as necessidades do cliente.
Essa interação contínua entre o Product
Owner e a equipe revela-se crucial, complementada
pela notável flexibilidade do Scrum em se adaptar às
mudanças. Sendo uma dinâmica fundamental para
assegurar a entrega de um produto que atenda de
maneira eficaz e precisa às expectativas do cliente.
A compreensão profunda do projeto por parte
do Product Owner é um elemento-chave para o
sucesso do empreendimento.
Ao responder às dúvidas do Development
Team em substituição ao cliente, o Product Owner
desempenha um papel decisivo na tomada de
decisões durante o ciclo de desenvolvimento. Sua
habilidade de avaliar se as funcionalidades
Chico Alff - 51

escolhidas são realizáveis dentro dos prazos
estabelecidos reflete diretamente na qualidade e na
eficácia do produto final.
Cabe destacar que o Product Owner possui
uma autoridade significativa no Scrum, incluindo a
capacidade de interromper um Sprint caso
identifique falhas no planejamento ou ocorram
mudanças que demandem intervenção imediata.
Essa prerrogativa é considerada um gesto
drástico, um evento excepcional que deve ser
empregado com cautela, evitando minar a confiança
no projeto tanto para os desenvolvedores quanto
para os stakeholders.
Chico Alff - 52

Scrum Team
O Scrum Team, também chamado
simplesmente por “time”, é normalmente composta
por profissionais multifuncionais, como
desenvolvedores, analistas e testadores, esse time
tem a responsabilidade de transformar os requisitos
do Product Backlog em incrementos de software
funcionais durante cada iteração, conhecida como
Sprint.
A importância do Scrum Team reside na
colaboração intensiva e na partilha de
responsabilidades, permitindo uma resposta ágil e
eficiente às mudanças nos requisitos do cliente.
A composição preferencial destaca-se pela
diversidade de habilidades e conhecimentos,
promovendo autonomia e agilidade.
Com desenvolvedores, analistas de negócios e
testadores trabalhando sinergicamente,
comprometidos com os princípios ágeis, o Scrum
Chico Alff - 53

Team se adapta rapidamente às exigências do
cliente, resultando em entregas frequentes e de
valor ao longo do projeto.
Essa característica do framework promove
não apenas a entrega eficiente de funcionalidades
do software, mas também a criação de um ambiente
no qual os membros da equipe se sintam
capacitados a inovar e contribuir ativamente para o
sucesso do projeto.
Chico Alff - 54

Cerimônias do Scrum
O Scrum adota uma abordagem dinâmica e
colaborativa por meio de suas cerimônias, encontros
estruturados que compõem a essência do
funcionamento da metodologia.
As cerimônias do Scrum,
também conhecidas como
"rituais", desempenham papéis
específicos, contribuindo para a
eficácia e a comunicação
dentro do Scrum Team. As
quatro cerimônias tradicionais
do framework Scrum são:
● Sprint Planning: Antes de cada iteração, o
Sprint Planning orienta o Development Team
na escolha dos requisitos a serem
implementados durante o Sprint. Este ritual é
crucial para alinhar as metas e garantir que a
Chico Alff - 55

equipe esteja ciente do caminho que o
projeto seguirá.
● Daily Scrum: Essa reunião diária, também
chamada de Stand-up Meeting, proporciona
uma oportunidade para que os membros da
equipe compartilhem atualizações rápidas
sobre o progresso, obstáculos e próximos
passos. Essa comunicação diária é essencial
para manter a agilidade e a eficiência.
● Sprint Review: Ao término de cada iteração, a
Sprint Review permite que o Scrum Team
demonstre o trabalho concluído ao Product
Owner e outros stakeholders. Essa cerimônia é
fundamental para garantir a transparência e a
conformidade com as expectativas do cliente.
● Sprint Retrospective: Após a conclusão de
cada Sprint, a Sprint Retrospective oferece
uma oportunidade para a equipe refletir sobre
o processo, identificar áreas de melhoria e
Chico Alff - 56

ajustar suas práticas. Essa cerimônia é
essencial para promover a aprendizagem
contínua e o aprimoramento do desempenho
do time.
A prática metódica e regular das cerimônias
do Scrum promove uma sinergia fundamental entre
os membros da equipe, resultando em um ciclo de
desenvolvimento iterativo e adaptativo.
Requisitos.
Chico Alff - 57

Chico Alff - 58

Sprint Planning
Sprint Planning é uma cerimônia essencial no
framework Scrum, desempenhando um papel
fundamental na preparação para cada iteração do
projeto.
Seu principal objetivo é
orientar o time de
desenvolvimento na seleção
dos requisitos ou tarefas a
serem implementados
durante o Sprint, garantindo
um alinhamento claro das
metas e uma compreensão compartilhada do
caminho a ser percorrido.
Durante essa reunião, a equipe tem a
oportunidade de colaborar na definição das
atividades que serão priorizadas, promovendo uma
abordagem coletiva na tomada de decisões.
Chico Alff - 59

A condução do Sprint Planning envolve
algumas indicações importantes. Em primeiro lugar,
é crucial que a equipe esteja totalmente presente e
engajada, promovendo a comunicação aberta e
eficaz.
O Product Owner desempenha um papel vital
ao compartilhar a visão do produto e esclarecer
dúvidas sobre os requisitos. Além disso, o Scrum
Master facilita o processo, garantindo que a reunião
seja focada e produtiva.
O tempo é uma variável crítica, e a equipe
deve manter um equilíbrio para evitar discussões
intermináveis, utilizando técnicas como o Planning
Poker para estimar o esforço necessário para cada
atividade.
Características distintivas da Sprint Planning
incluem a colaboração intensiva entre os membros
da equipe e a ênfase na entrega de valor ao cliente.
Durante a reunião, os requisitos são discutidos
detalhadamente, e a equipe trabalha para dividir as
tarefas de maneira eficiente, atribuindo
responsabilidades de acordo com as habilidades
individuais.
Chico Alff - 60

A organização dos itens do Product Backlog
em uma lista ordenada de prioridades facilita a
seleção durante o planejamento, contribuindo para
uma alocação eficaz dos recursos disponíveis.
Chico Alff - 61

Daily Scrum Meeting
O Daily Scrum, uma das cerimônias
fundamentais no Scrum, consiste em uma breve
reunião de aproximadamente 15 minutos.
Durante esse encontro diário, cada membro
do Development Team compartilha suas atividades
Chico Alff - 62

do dia anterior, expõe as tarefas planejadas para o
dia em curso e relata eventuais impedimentos
encontrados durante o desenvolvimento.
É importante entender que o propósito
principal do Daily Scrum não é solucionar problemas
instantaneamente, mas sim identificá-los para,
posteriormente, discutir sua resolução em reuniões
específicas que envolvem apenas os
desenvolvedores interessados, evitando bloqueios
para o restante da equipe em relação a outros
requisitos.
Durante essa reunião cada membro do time
deverá responder 3 perguntas simples da forma
mais objetiva possível:
1. O que fiz desde a última reunião?
Cada membro compartilha as tarefas
realizadas desde o último encontro.
2. O que planejo fazer hoje?
Os membros explicam suas próximas tarefas.
3. Existem impedimentos?
Chico Alff - 63

Se algum membro está enfrentando
obstáculos, este é o momento de
compartilhar para que a equipe possa ajudar
a resolver esses problemas.
A comunicação frequente promovida durante
o Daily Scrum mantém todos os integrantes
atualizados, facilitando a resolução imediata de
desafios e garantindo a coesão do time.
Chico Alff - 64

Sprint Review
No encerramento de cada ciclo de Sprint, é
conduzida a reunião de Sprint Review, reunindo
todas as partes interessadas no projeto (em um
cenário ideal), com destaque para o Product Owner,
o Scrum Master, key users responsáveis por
aprovações, stakeholders e o Scrum Team que
participou ativamente da Sprint.
Esta cerimônia representa a terceira etapa das
quatro previstas no Scrum e deve ser realizada no
último dia do ciclo. Seu propósito central é avaliar o
desempenho da equipe, proporcionar feedbacks
construtivos e discutir possíveis problemas ou
desafios encontrados durante a interação.
A Sprint Review visa apresentar e validar o
resultado final das atividades e entregas
desenvolvidas ao longo da Sprint.
Durante essa cerimônia, tanto o Scrum Master
quanto o Product Owner desempenham papéis
cruciais ao focar na identificação de eventuais
Chico Alff - 65

desvios que possam ter ocorrido durante o ciclo. A
realização da revisão da Sprint tem ainda como
objetivo garantir a transparência no processo e a
qualidade nas entregas realizadas.
Essa reunião representa um momento vital
para o Scrum Master, que utiliza este espaço para
fornecer feedbacks globais à equipe como um todo.
Nesse contexto, é importante destacar que
observações específicas sobre membros do Scrum
Team não devem ser realizadas na Sprint Review,
sendo reservadas para outros momentos mais
apropriados.
O foco está na avaliação coletiva, promovendo
um ambiente colaborativo e incentivando melhorias
que beneficiem a equipe como um conjunto coeso.
Chico Alff - 66

Sprint Retrospective
A última cerimônia do Scrum, a Sprint
Retrospective, desempenha um papel crucial no
processo de melhoria contínua.
Durante essa reunião, que
geralmente tem uma duração
média de 1 hora, a equipe
compartilha feedbacks e
experiências relacionadas às
dificuldades, problemas e
impedimentos enfrentados ao
longo da Sprint.
O objetivo central da Sprint Retrospective é
avaliar o desempenho do time de forma aberta e
construtiva, promovendo uma discussão franca
sobre os desafios enfrentados durante a interação.
Essa análise aprofundada permite a
identificação de gaps, riscos e deficiências no time,
no processo de trabalho ou no projeto como um
todo, fornecendo insights valiosos para o processo de
Chico Alff - 67

melhoria contínua ao longo do ciclo de vida do
Scrum.
A Sprint Retrospective se destaca por oferecer
um espaço dedicado à reflexão e ao diálogo,
proporcionando à equipe a oportunidade de discutir
ações que podem ser implementadas para otimizar
o desempenho nas próximas Sprints.
A cerimônia de retrospectiva não apenas
fomenta uma cultura de aprendizado contínuo, mas
também reforça a importância do
comprometimento coletivo com a busca constante
por aprimoramento e excelência no
Chico Alff - 68

Artefatos do Scrum
Os artefatos no Scrum são documentos ou
ferramentas visuais que ajudam a organizar, priorizar
e acompanhar o progresso do trabalho durante o
desenvolvimento ágil de software.
Eles desempenham um papel fundamental
na transparência e na comunicação eficaz dentro da
equipe e com as partes interessadas. Alguns dos
principais artefatos incluem:
● Product Backlog: Uma lista dinâmica de
funcionalidades, melhorias e correções
desejadas para o produto, priorizadas com
base no valor que agregam ao cliente.
● Sprint Backlog: Uma lista de tarefas
específicas selecionadas para uma Sprint,
derivada do Product Backlog e que
Chico Alff - 69

representa o foco da interação.
● Sprint Burndown Chart: Uma ferramenta
visual que exibe o progresso da equipe
durante a interação, mostrando a quantidade
de trabalho restante ao longo do tempo.
● Scrum Task Board: Uma ferramenta visual
que organiza o fluxo de trabalho diário da
equipe, dividindo as tarefas em colunas como
"A Fazer," "Em Andamento" e "Concluído."
Requisitos.
Chico Alff - 70

Os artefatos e ferramentas do Scrum
proporcionam uma compreensão clara das metas do
projeto, mantendo a equipe alinhada e permitindo
adaptações contínuas.
Eles contribuem para a agilidade da
metodologia, garantindo que todos os envolvidos
tenham uma visão compartilhada do trabalho a ser
realizado e promovendo a colaboração eficaz para
alcançar os objetivos estabelecidos para cada
iteração.
Chico Alff - 71

Product Backlog
O Product Backlog é um componente
essencial que abrange todas as User Stories
relacionadas ao produto em desenvolvimento.
A seleção de quais requisitos
podem ser incluídos no backlog e
com qual prioridade é uma
decisão exclusiva do Product
Owner, que atua como o membro
mais próximo do cliente e suas
necessidades dentro do Scrum Team.
Esse componente serve como uma lista
dinâmica que evolui continuamente, refletindo as
demandas e prioridades do cliente ao longo do
tempo.
A organização e funcionamento do Product
Backlog estão intrinsecamente ligados ao Sprint
Backlog.
Chico Alff - 72

Ao iniciar cada Sprint, o Product Owner
seleciona algumas User Stories do Product Backlog
e determina quais requisitos têm prioridade máxima
para serem concluídos durante a iteração.
Embora a palavra final esteja nas mãos do
Product Owner, suas decisões são influenciadas pelo
entendimento do carregamento de trabalho que o
Development Team e o Scrum Master consideram
apropriado para a Sprint.
Nesse sentido, o Development Team
é auto-organizado, sendo capaz de
determinar o esforço que pode
sustentar durante a Sprint e como
distribuir as tarefas de
desenvolvimento sem influências
externas.
Esse artefato atua como uma reserva
dinâmica de requisitos do produto, enquanto o
Sprint Backlog é derivado do primeiro,
representando uma seleção de User Stories para
uma Sprint específica, com base nas prioridades
definidas pelo Product Owner.
Chico Alff - 73

Essa abordagem proporciona flexibilidade e
adaptabilidade ao Scrum, permitindo ajustes
contínuos às necessidades do cliente e às
capacidades do Development Team ao longo do
desenvolvimento do produto.
Chico Alff - 74

Sprint Backlog
O Sprint Backlog é o segundo item em nossa
lista de artefatos do Scrum.
Esse componente pode ser conceituado como
uma lista específica de tarefas criteriosamente
escolhidas para compor uma determinada Sprint.
Esta lista é derivada dos itens, requisitos e
tarefas existentes no backlog do produto, sendo um
pacote que agrupa os itens priorizados para a
iteração em questão, concentrando-se no que é
essencial para a entrega das funcionalidades
acordadas previamente entre o time do projeto,
patrocinadores e stakeholders.
É possível destacar elementos que
determinam seu mecanismo de uso e
funcionamento, sendo suas principais características:
Chico Alff - 75

● Dinamismo e adaptabilidade: O Sprint
Backlog destaca-se pela sua capacidade de se
adaptar dinamicamente durante o Sprint,
permitindo ajustes à medida que novas
informações emergem ou as circunstâncias se
modificam.
● Flexibilidade crucial: A flexibilidade é um
elemento fundamental do Sprint Backlog,
assegurando que a equipe possa se ajustar
rapidamente a mudanças e responder de
maneira eficaz a novos insights ou requisitos
do cliente.
● Ajustes contínuos: Ao longo do Sprint, a
equipe tem a liberdade de realizar ajustes no
backlog para otimizar o direcionamento das
tarefas, garantindo que o foco permaneça
alinhado aos objetivos estabelecidos.
● Ferramenta de orientação: O Sprint Backlog
transcende sua função como uma simples
lista de tarefas, tornando-se uma ferramenta
Chico Alff - 76

dinâmica que orienta a equipe ao longo da
Sprint. Sua estrutura permite uma entrega
incremental de valor ao cliente, enfatizando a
importância da colaboração e da entrega
focada.
O Sprint Backlog é como um norte
direcionador para a equipe de desenvolvimento
durante a interação, fornecendo uma visão clara das
tarefas que precisam ser concluídas e dos requisitos
que deverão ser desenvolvidos para garantir a
entrega das funcionalidades ou recursos esperados.
Chico Alff - 77

Sprint Burndown
O gráfico de burndown da Sprint é uma
ferramenta de análise visual essencial para a eficácia
de um time Scrum, proporcionando uma
representação clara do progresso da equipe ao longo
da interação, além de servir como um indicador
importante para o entendimento da capacidade de
entrega da equipe durante o ciclo em questão.
Ao analisar a inclinação da linha no gráfico, os
membros da equipe podem antecipar o ritmo do
trabalho restante e tomar decisões informadas sobre
a necessidade de ajustes na abordagem ou na
distribuição de tarefas.
Essa previsibilidade é crucial para o Product
Owner, Scrum Master e demais stakeholders,
permitindo uma gestão eficiente das expectativas e
a identificação proativa de possíveis obstáculos que
possam impactar o sucesso da Sprint.
Chico Alff - 78

A construção do gráfico pode ser realizado de
maneira automatizada por meio de softwares e
ferramentas específicas ou ainda manualmente,
utilizando um quadro ou flipchart.
É mandatório que uma versão física seja
disponibilizada no ambiente de trabalho do time,
garantindo que todos os membros tenham acesso à
ele, isso reflete e ressalta a importância do
envolvimento, comprometimento e engajamento
contínuo por parte da equipe toda.
Chico Alff - 79

1. Eixos do burndown:
a. Abscissas (eixo horizontal): Este eixo
representa os dias designados à Sprint,
fornecendo uma linha do tempo clara.
b. Ordenadas (eixo vertical): Responsável
por medir o número de requisitos não
concluídos, oferecendo uma
representação visual da carga de
trabalho remanescente.
2. Movimento da linha:
a. A linha inicializa no número inicial de
requisitos e, ao longo do tempo,
desloca-se diagonalmente para baixo,
refletindo o progresso em direção à
conclusão da Sprint.
b. A busca é por uma trajetória que
alcance a entrega de todo o esforço
estimado ao término da Sprint,
Chico Alff - 80

indicando que todo o escopo planejado
foi executado.
3. Análise Sistemática da Inclinação:
a. A inclinação da linha é observada de
perto, sendo uma inclinação constante
e suave indicativa de um progresso
consistente.
b. Variações notáveis na inclinação podem
indicar mudanças no ritmo de trabalho,
sugerindo adaptações necessárias.
4. Consideração da Tendência ao Longo do
Tempo:
a. A avaliação da tendência geral da linha
ao longo dos dias oferece insights sobre
a previsibilidade do desenvolvimento.
b. Desvios repentinos na tendência
podem indicar eventos inesperados ou
ajustes necessários na abordagem.
Chico Alff - 81

5. Atenção a Marcadores Relevantes:
a. A adição de marcadores específicos
para eventos significativos, como
reuniões cruciais ou marcos no
desenvolvimento, permite uma
contextualização mais rica da narrativa
do gráfico.
A correta leitura e interpretação do gráfico
burndown de uma interação tem um papel
determinante para o aprimoramento da capacidade
de antecipação de cenários, tomar decisões
informadas e manter um controle preciso do
progresso durante a Sprint.
Essa prática fortalece a gestão interna da
equipe, e também contribui para a manutenção de
uma comunicação transparente com os
stakeholders e demais envolvidos.
A seguir, apresentaremos um gráfico
burndown hipotético, que servirá como exemplo
Chico Alff - 82

para explicar como interpretar e compreender cada
uma de suas informações e seus respectivos usos
para otimizar o desempenho do time.
O burndown proposto acima possui índices
ou indicadores adicionais que permitem uma
interpretação mais profunda do progresso de um
sprint.
Chico Alff - 83

● Eixo X representa os o total de dias úteis do
sprint, no exemplo 14.
● Eixo Y corresponde ao total de horas, stories,
ou pontos estimados para o sprint, no
exemplo 28.
● Barras laranja: representam o total de horas,
stories ou pontos ainda pendentes de
conclusão.
● Barras azuis: indicam a quantidade de esforço
concluídos em cada dia.
● Linha verde: representa a cadência de
entregas esperado, ou seja, o burndown ideal.
● Linha vermelha: indica a velocidade percebida
de entregas, ou seja, o burndown atual do
sprint.
● Linha azul: representa a quantidade de
entregas realizadas diariamente, seguida pela
tendência estimada (linha pontilhada azul) do
período restante considerando o período
anterior.
Chico Alff - 84

TaskBoard
A estrutura do Scrum Task Board é
convencionalmente composta por quatro colunas
padronizadas, que representam o status ou situação
atual de uma tarefa dentro do fluxo de execução,
sendo elas: estoque de user stories, to-do (a fazer),
in-progress (fazendo), waiting (aguardando definição
ou retorno externo) e done (concluído).
No exemplo representamos uma
configuração clássica de um Scrum Task Board,
composta por 5 colunas que representam situações
específicas de atribuição às tarefas.
Chico Alff - 85

“Estoque de user stories” (marcação A), coluna
onde ficam as demandas dos usuários, que são
escritas em forma de histórias de usuário,
descrevendo o que eles querem e por quê, utilizando
a visão de negócio e processo, não devem ser
descritas soluções tecnológicas.
Essas histórias são priorizadas pelo product
owner, e sua grandeza e complexidade estimadas
com a equipe durante o Sprint Planning.
Chico Alff - 86

“To-do” ou “a fazer” (marcação B), contém
todas as user stories que foram selecionadas para o
sprint atual, ou seja, o ciclo de trabalho que dura de
duas a quatro semanas. Essas histórias são divididas
em tarefas menores e mais específicas, que devem
ser realizadas pela equipe de desenvolvimento.
“Doing”, “In-progress” ou fazendo” (marcação
C), agrupa as tasks que estão sendo executadas pela
equipe, servindo como um importante indicador do
desempenho do time e do progresso do sprint.
Chico Alff - 87

Cada tarefa é atribuída a um membro da
equipe, que deve atualizar o status da mesma
conforme avança no trabalho.
“Done” ou “concluído” (marcação D): última
coluna do board clássico. Nela são inseridas as
tarefas finalizadas pela equipe, cumprindo os
critérios de aceitação definidos pelo product owner.
Essas tarefas devem ser validadas pelo stakeholder
aprovador, para garantir que atendem às suas
expectativas e necessidades.
A configuração de colunas desse quadro é
customizável para atender às necessidades
específicas de cada projeto, permitindo a inclusão de
colunas adicionais que atendam outros status que
possam existir no fluxo de trabalho de cada projeto,
contemplando assim suas particularidades
específicas.
Essa flexibilidade permite que o quadro seja
ajustado de acordo com os requisitos e
características particulares da equipe e do projeto
em questão.
Essas colunas extras podem abranger etapas
como Revisão, Testes ou Qualidade, proporcionando
Chico Alff - 88

uma representação visual com os processos reais
existentes no projeto ou adotados pela equipe.
Chico Alff - 89

TaskBoard vs Kanban Board
É comum haver confusão entre o Scrum Task
Board e o Kanban, essa confusão é justificada
principalmente pela similaridade visual e aplicação
na gestão ágil de projetos. Scrum Task Board e
quadro Kanban não são a mesma coisa: elas
possuem diferenças e aspectos únicos que são
fundamentais para garantir o respeito da natureza
conceitual e dos objetivos de cada uma das
metodologias.
Scrum Task Board
● Estrutura Padronizada: O Scrum Task Board
segue uma estrutura mais padronizada, com
colunas tradicionalmente predefinidas, como
To-Do, Doing e Done.
Chico Alff - 90

● Foco na Sprint: É especialmente projetado
para atender às necessidades da Sprint no
Scrum, refletindo o andamento das User
Stories e requisitos específicos escolhidos para
a iteração.
● Planejamento e Controle de Sprint: Seu
principal propósito é fornecer uma visão clara
e visual do progresso durante a Sprint,
auxiliando na organização e no planejamento
da equipe Scrum.
Quadro Kanban
● Flexibilidade na Estrutura: O Kanban é mais
flexível em termos de estrutura, permitindo a
customização das colunas de acordo com o
fluxo de trabalho específico da equipe.
● Visualização Contínua: Enquanto o Scrum
Task Board está mais relacionado à Sprint, o
Kanban é mais amplamente aplicável,
Chico Alff - 91

oferecendo uma visão contínua e fluida do
fluxo de trabalho sem limitações temporais.
● Ênfase no Fluxo de Trabalho: O Kanban
destaca-se por seu foco contínuo na eficiência
do fluxo de trabalho, otimizando a entrega de
valor sem a necessidade de iterações
temporais fixas.
Analisando as características de cada um dos
quadros, podemos assumir que, o Scrum Task Board
possui aplicação direcionada à gestão de tarefas de
um único ciclo ou interação, projetado para atender
às necessidades de planejamento e execução de
uma Sprint, enquanto o Kanban é mais flexível e
aberto, adequando-se a uma variedade de cenários e
enfatizando características de trabalho ou de
desenvolvimento adaptativo e evolutivo em um
único fluxo de trabalho contínuo.
Chico Alff - 92

Funcionamento do Scrum TaskBoard
O fluxo das tarefas e histórias de usuários em
um Scrum Task Board é estruturado de maneira a
refletir o ciclo de vida durante uma Sprint.
Inicialmente, user stories e tarefas são
visualmente representadas em post-its e dispostas
na coluna to-do, indicando que estão prontas para
serem abordadas durante a interação. Adjacente a
cada história, são elencados os requisitos específicos
relacionados, todos previamente escolhidos para
inclusão na Sprint.
Durante a realização da reunião diária (Daily
Scrum), cada integrante do time determina quais
histórias de usuário ou tarefas serão alocadas para a
execução no dia, movendo-os da coluna To-Do para
In-Progress.
Essa transição não apenas sinaliza o início da
implementação, mas também envolve a atribuição
dos responsáveis pelas respectivas tarefas.
Chico Alff - 93

Essa prática visa não apenas monitorar o
progresso, mas também promover a
responsabilidade individual e a colaboração eficaz
dentro da equipe Scrum.
A movimentação de uma tarefa
posteriormente ao seu início é influenciada pela
existência de colunas adicionais, fruto de
particularidades de cada projeto.
À medida que as tarefas transitam por essas
colunas específicas, a equipe pode concentrar
esforços em atividades como a revisão de uma
implementação, garantia de qualidade ou interações
com os stakeholders para validação.
A inclusão de colunas personalizadas amplia a
visibilidade sobre o estado atual das tarefas, e
oferece maior flexibilidade para ajustar o processo
conforme as demandas do projeto evoluem.
Ao concluir a implementação de um requisito,
user story ou tarefa, os desenvolvedores transferem
os itens correspondentes para a coluna Done.
A inclusão de um item nessa coluna serve
como indicação visual instantânea do progresso da
Chico Alff - 94

equipe em confronto com o planejado e uma visão
generalista do trabalho que ainda precisa ser
realizado.
É uma prática comum nos times Scrum, focar
em uma tarefa ou história de usuário por vez,
objetivando requisitos essenciais para as entregas e
a otimização da eficiência durante a execução das
tarefas, fortalecendo o comprometimento da equipe
com a entrega bem-sucedida de valor ao cliente no
contexto da Sprint.
Chico Alff - 95

Refinamento do backlog do produto
O refinamento de backlog é um processo
contínuo em que o product owner e a equipe de
desenvolvimento revisam, discutem e ajustam os
itens do backlog do produto.
O objetivo é garantir que os requisitos estejam
claros, completos e prontos para serem incluídos nas
próximas iterações. Essa atividade consiste em
preparar os itens que serão realizados, ou seja, é o
ato de detalhar, compreender com mais
profundidade, estimar, reordenar, priorizar e
gerenciar o backlog do produto.
O refinamento é realizado apenas para os
itens relevantes para os próximos sprints e evita o
emprego de tempo com detalhamentos de itens de
menor prioridade e sujeitos à mudanças.
Podemos definir o refinamento do backlog
como o processo de aprimorar e detalhar os itens
presentes no backlog do produto, de forma a
Chico Alff - 96

torná-los mais compreensíveis e prontos para serem
desenvolvidos. Entre os benefícios dessa prática,
destacam-se o aumento da eficiência no
desenvolvimento, a redução de retrabalho e a
melhoria da comunicação entre os membros do
time de desenvolvimento.
É necessário determinar uma frequência
apropriada para a realização da atividade de
refinamento, considerando a capacidade da equipe
e a dinâmica do projeto.
Para assegurar a eficácia do processo de
refinamento, é preciso definir a alocação de recursos
necessários, além da definição de limites de tempo
para sua realização.
Durante o refinamento, as histórias de
usuários são discutidas, esclarecidas e enriquecidas
com critérios de aceitação, que são condições
específicas que devem ser atendidas para que a
história seja considerada concluída.
É necessário adaptar o backlog conforme
novas informações, histórias de usuário, ou mesmo
ainda requisitos funcionais e não funcionais são
Chico Alff - 97

identificados, garantindo que o backlog continue a
ser relevante e atenda às necessidades do projeto.
A última edição do Glossário da Agile Alliance
recomenda que o product owner realize
constantemente uma review das histórias de usuário
do backlog, realizando a: remoção de histórias
obsoletas e a abertura imediata de histórias
documentando novas necessidades, features e
solicitações.
Muitas vezes, os itens do backlog podem ser
grandes e complexos, dificultando sua estimativa e
implementação em uma única iteração. A técnica de
splitting envolve a divisão de histórias maiores em
partes menores e mais gerenciáveis, que podem ser
trabalhadas em iterações menores.
A equipe pode identificar partes
independentes ou critérios de divisão para cada
história, criando histórias menores e mais granulares.
Isso permite um planejamento mais preciso e um
progresso mais visível do desenvolvimento.
Remover histórias de usuários que não
parecem mais relevantes é importante para manter
o backlog atualizado e garantir que o produto esteja
Chico Alff - 98

alinhado com as necessidades do cliente. Para isso, o
product owner deve avaliar constantemente as
histórias que compõem o backlog e remover aquelas
que não são mais relevantes ou que não agregam
mais valor ao produto.
A criação de histórias de usuário em resposta
às necessidades recém-descobertas é importante
para garantir que o produto atenda às necessidades
do cliente.
É preciso avaliar constantemente as
necessidades do cliente e criar histórias de usuário
que atendam a essas necessidades. Essas histórias
devem ser adicionadas ao backlog e priorizadas de
acordo com sua importância para o cliente.
Critérios de aceitação devem ser adicionados
às histórias de usuário para garantir que elas sejam
claras e testáveis. Eles são usados para definir as
condições que devem ser atendidas para que uma
história de usuário seja considerada concluída.
Os critérios de aceitação devem ser
específicos e mensuráveis. Eles devem descrever o
que é esperado da história do usuário e como ela
será testada. Eles também devem ser escritos em
Chico Alff - 99

linguagem simples e clara para que todos os
membros da equipe possam entendê-los.
É importante revisar regularmente os critérios
de aceitação durante o refinamento do backlog para
garantir que eles ainda sejam relevantes e atendam
às necessidades do cliente. Isso ajuda a garantir que
o produto final atenda às expectativas do cliente e
seja de alta qualidade.
O uso de diagramas e mockups é uma técnica
visual poderosa para refinar o backlog. Eles
permitem que a equipe visualize as funcionalidades
e interações do sistema de forma mais concreta.
Diagramas UML e fluxogramas como, diagramas de
classe ou diagramas de sequência, ajudam a ilustrar
o funcionamento do sistema. Diagramas podem ser
usados para representar fluxos de trabalho,
processos e arquitetura do sistema.
Já os mockups são usados para representar a
interface do usuário e o design do produto.
Chico Alff - 100

Backlog grooming
Backlog grooming é um processo de revisão e
manutenção do backlog do produto ou projeto.
Trata-se de uma atividade regular e periódica,
na qual a equipe revisa as tarefas, tasks e histórias de
usuário no backlog, clarifica detalhes, estima o
tempo necessário e prioriza sua relevância e
importância para o projeto.
De forma simples, direta e sem
delongas, podemos dizer que o
objetivo do Grooming é manter o
backlog do produto ou projeto
atualizado, organizado e alinhado
com as metas, e entregas
acordadas com os patrocinadores
e stakeholders, garantindo assim a qualidade das
entregas e o sucesso do projeto (ou pelo menos
contribuindo para isso).
Chico Alff - 101

A atividade pontual de reorganização e
priorização das atividades ajuda a equipe a se
concentrar nas tarefas mais importantes, evitando
atrasos e garantindo a entrega de valor ao cliente.
É possível identificar uma série de benefícios
ou vantagens para um projeto, diretamente
relacionados ao uso do backlog grooming,
selecionamos 6 desses benefícios, utilizando como
critério o impacto no desempenho de um time de
desenvolvimento rodando Scrum em um projeto de
novo produto:
1. Backlog atualizado: Garantir que o backlog
esteja sempre atualizado e organizado,
refletindo as últimas mudanças no projeto.
2. Tarefas priorizadas: Discutir e priorizar as
tarefas no backlog, levando em consideração
sua relevância e importância para o projeto.
3. Alinhamento com os objetivos: Verificar se o
backlog está alinhado com as metas do
Chico Alff - 102

projeto, garantindo que a equipe esteja
trabalhando nas tarefas corretas.
4. Requisitos claros e entendidos: Discutir e
clarificar detalhes das tarefas no backlog,
garantindo que todos tenham a mesma
compreensão do que precisa ser feito.
5. Maior assertividade das estimativas: Discutir e
estimar o tempo necessário para completar
cada tarefa, melhorando a precisão da
previsão de tempo do projeto.
6. Foco no que é importante: Ajudar a equipe a
se concentrar nas tarefas mais importantes,
evitando atrasos e garantindo a entrega de
valor ao cliente.
Como dito anteriormente, existem dezenas de
vantagens e benefícios que a realização do
grooming pode trazer podem ou não aplicar-se a
realidade de seu projeto.
Chico Alff - 103

SCRUM: Monitorando o desempenho
A conclusão de cada Sprint no Scrum marca o
início de um percurso constante em direção ao
aprimoramento contínuo do processo de
desenvolvimento. O propósito é elevar a qualidade
do software, atendendo, assim, aos requisitos
essenciais demandados pelos clientes.
Para avaliar o nível de qualidade atingido e
identificar áreas críticas no processo de
desenvolvimento, torna-se imperativo coletar dados
que retratem tanto os objetivos alcançados quanto
aqueles que não foram.
A principal ferramenta utilizada para
mensurar o esforço investido na conclusão de User
Stories e atividades ao longo do Sprint é o burndow
chart.
A forma gráfica desse instrumento,
previamente explicada, destaca agora sua função
em evidenciar a discrepância entre as expectativas
Chico Alff - 104

iniciais e a real capacidade da equipe em finalizar as
tarefas planejadas.
Se uma equipe não consegue concluir as
tarefas planejadas para a interação, pode ser
resultado da subestimação de algumas atividades
ou da introdução excessiva de tarefas durante a
Sprint.
Essa última situação muitas vezes ocorre
quando o Product Owner sobrecarrega a equipe, e o
Scrum Master não consegue mitigar o excesso de
estresse. A otimização da comunicação entre essas
duas funções se apresenta como uma estratégia
eficaz para evitar recorrências dessas situações.
Requisitos.
Chico Alff - 105

Por outro lado, a Release Burndown Chart
atua como uma ferramenta para mensurar a
velocidade com que a equipe libera atividades do
Product Backlog, ao mesmo tempo em que
monitora a quantidade de trabalho restante para a
conclusão do produto, representando o número de
Sprints no eixo horizontal e o esforço total necessário
para as atividades do Product Backlog no eixo
vertical, essa medida de esforço pode adotar
diversas formas, como a atribuição de pontuações
(chamado frequentemente de “peso”) às user stories,
dimensionamento de atividades ou ainda a
contagem de horas de trabalho, de acordo com a
realidade do projeto e das preferências da equipe.
Chico Alff - 106

Essa ferramenta é eficaz para rastrear o
andamento do projeto e manter um histórico do
número de funcionalidades introduzidas entre um
Sprint e outro ao longo do tempo, além de registrar
quantas foram concluídas.
Para assegurar a utilidade da Release
Burndown Chart, é essencial especificar o número
de releases a serem acompanhadas, incluindo as
datas de início e término de cada uma. Além disso, é
necessário definir as atividades no Product Backlog
e atribuí-las a cada Sprint, realizando uma estimativa
inicial da carga de trabalho para a release.
Ao término de cada Sprint, é crucial remover
as atividades que foram concluídas, garantindo
assim a precisão e a eficácia dessa ferramenta ao
longo do desenvolvimento do projeto.
Chico Alff - 107

Scrum Team Capacity
O Scrum Team Capacity, em tradução literal
‘Capacidade da Equipe Scrum’ diz respeito a
quantidade (capacidade) de trabalho ou esforço que
uma equipe é capaz de executar durante um único
sprint. Para calcular essa capacidade, multiplica-se o
número de membros da equipe pelo número de
dias úteis do ciclo.
Conhecer a capacidade de entrega real de um
time Scrum é fundamental para o planejamento das
tarefas da equipe, garantindo entregar o máximo
possível de valor ao cliente.
O objetivo é otimizar a entrega de valor em
um curto intervalo de tempo, possibilitando que a
equipe responda de maneira ágil às mudanças nas
necessidades do cliente e do mercado.
Chico Alff - 108

Quantidade de entregas
Ter sempre a visão clara da quantidade de
entregas realizadas por um time Scrum durante ao
longo da execução dos sprints possibilita entender e
gerenciar melhor as expectativas de stakeholders e
patrocinadores.
Saber o quanto de valor está sendo entregue
em cada sprint permite a identificação de incidentes
e ocorrências anômalas que provocaram as inflexões
no número total de entregas realizadas.
Chico Alff - 109

Velocidade atual e média do time
O cálculo da velocidade atual do time Scrum,
é respectivamente a quantidade de stories ou tarefas
entregues no sprint mais recente.
No caso do exemplo apresentado, no 5º sprint,
um total de 20 stories foram entregues, sendo assim,
a velocidade de entrega atual da equipe é de 20
stories (ou pontos, caso a equipe tenha adotado esse
termo/critério).
A velocidade média do time no intervalo das 5
sprints propostas no exemplo é calculada somando
todas as stories ou pontos entregues em todos os
sprints que serão considerados na análise, dividindo
então o resultado da soma pelo total de sprints do
período.
Chico Alff - 110

‘
Aplicando a fórmula padrão para o
cálculo da velocidade média do time (apresentada
anteriormente) teremos o seguinte cenário:
● Passo 1 - Identificar a quantidade de stories ou
pontos entregues em cada um dos 5 sprints
do período da amostragem, sendo
respectivamente 14, 17, 20, 18 e 20.
● Passo 2 - Somar a quantidade de stories
entregues em todos os sprints do período
Chico Alff - 111

analisado:
14 + 17 + 20 + 18 + 20 = 89
● Passo 3 - O último passo consiste na divisão
do total de pontos entregues no período pelo
total de sprints do período:
○ Entregas totais do período: 89
○ Total de sprints do período: 5
○ Velocidade média: 89/5 = 17,8
No exemplo que analisamos, a velocidade
média do time Scrum aferida no período dos 5 ciclos
considerados é de 17,8 stories (ou pontos) por sprint.
Isso significa que a capacidade média de entrega do
time por sprint é de 17,8 stories.
Chico Alff - 112

Velocity Chart
O Velocity Report e o Velocity Chart são outras
ferramentas úteis para o acompanhamento do
desempenho de um time Scrum.
Esse gráfico, assemelhando-se à Release
Burndown Chart, tem a distinção de registrar não o
número total de atividades no Product Backlog, mas
o esforço das tarefas concluídas a cada lançamento.
Esse artefato oferece a capacidade de estimar
uma média do esforço que a equipe pode sustentar
a cada Sprint, desde que os integrantes do time e a
duração das Sprints permaneçam constantes.
O gráfico proporciona uma visão imediata do
desempenho da equipe, tornando evidente
eventuais mudanças significativas que sugerem a
necessidade de uma revisão no processo de
desenvolvimento.
Chico Alff - 113

No exemplo fornecido, o gráfico apresenta
cinco sprints, indicadas no eixo horizontal (eixo x), e a
quantidade de story points ou tarefas planejadas e
concluídas, dispostas no eixo vertical (eixo y) que vai
de 0 a 22.
Os elementos que compõem o gráfico
incluem barras azuis e vermelhas. As barras azuis
representam os story points planejados para cada
sprint, enquanto as vermelhas indicam os pontos
efetivamente entregues.
Chico Alff - 114

É evidente uma variação discrepante na
quantidade de trabalho planejado e concluído em
cada sprint.
A ferramenta fornece uma visão panorâmica
do desempenho da equipe nas entregas ao longo
dos ciclos de desenvolvimento. Realizando a leitura
do gráfico fornecido como exemplo, podemos
identificar e compreender sem dificuldades os
valores nele representados:
● Sprint 1: Planejado - 16, Entregue - 14
Acima identificamos as duas informações
necessárias para a análise da velocidade da equipe: a
quantidade de tarefas ou pontos de história
planejados e o total entregue em cada um dos
Chico Alff - 115

sprints no intervalo de tempo analisado. No exemplo
esse período corresponde a 5 sprints..
Uma vez que possuímos as informações de
pontos estimados e entregues, podemos calcular
“delivered value time”, um indicador relevante ao
aferir a velocidade da equipe, a análise do DVT é
aplicada não apenas no framework Scrum, sendo
comum também em outras metodologias ágeis de
Ele se refere ao tempo que a equipe leva para
entregar valor ao cliente ou solicitante, ou seja, para
entregar um produto ou funcionalidade que atenda
às necessidades do cliente e gere valor para o
negócio.
O delivered value time permite maximizar o
valor entregue ao cliente em um curto espaço de
tempo com ações reativas e proativas, já que facilita
a identificação de mudanças na quantidade de valor
entregue de forma visual.
O delivered value time só pode ser
considerado confiável e verossímil se o conceito de
valor para o cliente estiver claramente definido,
entendido e aceito pelo time todo.
Chico Alff - 116

Ao evidenciar inflexões no gráfico, o Velocity
Report serve como um indicador claro das oscilações
no desempenho do time, indicando momentos
cruciais em que uma revisão aprofundada do
processo de desenvolvimento se faz essencial.
Chico Alff - 117

Gestão do Débito Técnico
A análise do débito técnico compreende
questões conhecidas e falhas incorporadas na
entrega ao término da Sprint. Tipicamente, essa
métrica quantifica não apenas o número de falhas,
mas também contempla outras informações, como
documentação e os meios empregados para a
entrega. As Histórias do Usuário categorizadas nesse
contexto podem ser consideradas como concluídas
em relação às expectativas do cliente, embora
tenham sido implementadas de maneira não ideal
para atender aos prazos de entrega.
Chico Alff - 118

Entusiasmo da Equipe
Monitorar o nível de entusiasmo da equipe
em relação ao projeto é crucial, pois sem esse
componente, nenhuma metodologia ou processo
seria capaz de salvaguardar a situação.
Essa métrica pode ser obtida observando os
resultados ao longo das Sprints ou consultando
diretamente os desenvolvedores quanto à satisfação
com o projeto e o nível de motivação.
A taxa de rotatividade da equipe também é
um parâmetro relevante, já que um índice elevado
pode indicar baixa motivação entre os membros.
Chico Alff - 119

Melhoria no Processo Retrospectivo
A capacidade de uma equipe Scrum em
revisar seu processo de desenvolvimento para
torná-lo mais eficaz na próxima Sprint é medida
através da métrica de Melhoria no Processo
Retrospectivo.
Essa análise conta quantas
atividades foram revisadas,
quantas a equipe se
comprometeu a resolver e
quantas foram efetivamente
solucionadas até o final da
Sprint.
Através da análise do processo retrospectivo
permite ao time aprimorar seu método de trabalho
para torná-lo mais eficiente no próximo ciclo de
interação.
Devem ser consideradas na interpretação
dessa informação a quantidade de processos e
execuções revisadas durante o período, a quantidade
Chico Alff - 120

de ocorrências ou incidentes que a equipe se
comprometeu a resolver e, por fim, quantas dessas
questões foram efetivamente solucionadas.
Chico Alff - 121

Sucesso nas metas dos sprint
Mensura o nível de êxito alcançado pela
equipe a cada Sprint. Para atingir uma taxa
satisfatória, não se exige a conclusão de todas as
atividades listadas no Sprint Backlog.
É necessário que uma quantidade predefinida
delas seja efetivamente considerada como completa,
incluindo testes, documentação e integração com
outras funcionalidades.
Suponhamos que uma equipe Scrum esteja
trabalhando em um projeto de desenvolvimento de
software para criar um aplicativo de gerenciamento
de tarefas:
● User Story 1: Cadastro de Tarefas: Esta história
de usuário inclui a implementação do
formulário de cadastro de novas tarefas no
sistema.
Chico Alff - 122

● User Story 2: Integração com Calendário: Essa
user story envolve a integração das tarefas
cadastradas com um calendário, permitindo a
visualização e organização por data.
● User Story 3: Testes e Documentação: Além
das funcionalidades, uma parte do Sprint
Backlog é dedicada à realização de testes
completos das novas implementações e à
documentação necessária.
Ao final do ciclo, analisando as entregas,
iremos considerar que a equipe tenha concluído a
implementação do cadastro de tarefas (User Story 1)
e a integração com o calendário (User Story 2), mas,
devido a algumas complexidades, os testes e
documentação (User Story 3) ainda estão em
andamento.
Neste cenário, o sucesso nas metas do Sprint
seria avaliado com base na conclusão satisfatória das
funcionalidades críticas (Cadastro de Tarefas e
Integração com Calendário), mesmo que parte do
escopo planejado (Testes e Documentação) ainda
Chico Alff - 123

esteja pendente. O importante é que as entregas
realizadas estejam em um estado funcional e pronto
para serem incorporadas ao produto, demonstrando
progresso tangível ao longo do Sprint.
Chico Alff - 124


Kanban
Antes de explorarmos mais a fundo os
princípios e características do Kanban, é
fundamental compreender que essa metodologia
ágil representa uma abordagem dinâmica e flexível
para o desenvolvimento de software.
Introduzida por David Anderson e originada
do contexto da produção, o Kanban focaliza-se na
melhoria contínua do processo, diferenciando-se de
outras metodologias, como o Scrum.
Ao invés de impor uma estrutura rígida, o
Kanban adapta-se à realidade de equipes e projetos,
promovendo a otimização incremental e
proporcionando uma visão holística para alcançar
eficiência e coerência no ciclo de desenvolvimento.
Nas palavras de David Anderson, o Kanban
não constitui uma metodologia autônoma para o
desenvolvimento de software nem uma abordagem
de gestão independente.
Chico Alff - 125

Ele pressupõe a existência de um processo
prévio, permitindo sua aplicação incremental para a
melhoria progressiva do processo subjacente. Essa
abordagem favorece a eficiência, possibilitando
ajustes graduais baseados nas necessidades e no
contexto específico da equipe.
Mais do que uma metodologia, o Kanban é
uma mentalidade. Apesar de possuir valores e
princípios, ele não estabelece práticas específicas.
Inspirado nos princípios Lean, o Kanban se destaca
por sete princípios fundamentais derivados do Lean,
visando à redução de desperdícios de recursos e
tempo no desenvolvimento de software.
Esses princípios incluem a eliminação de
desperdícios, a ampliação do aprendizado, a tomada
de decisões no último momento possível,
lançamentos frequentes, empoderamento da equipe
de desenvolvimento, construção de software
coerente e manutenção da visão geral do projeto.
Assim, o Kanban surge como uma abordagem
ágil que, ao incorporar os princípios Lean, busca
aprimorar continuamente o processo de
Chico Alff - 126

desenvolvimento, adaptando-se de forma flexível às
necessidades específicas da equipe e do projeto.
Além de requerer um sistema preexistente, o
Kanban oferece ferramentas valiosas para aprimorar
o processo de desenvolvimento da equipe. Um time
que adota o Kanban deve possuir uma compreensão
clara dos passos envolvidos na construção do
software, compreendendo como cada operação
impacta outros setores da empresa.
Devemos identificar onde
ocorrem desperdícios, quando e
como a ineficiência se
manifesta, e, sobretudo, como
aprimorar o processo
removendo suas causas. O
Kanban exemplifica como os
princípios ágeis podem ser aplicados para otimizar
um processo, tornando-o mais linear e simplificado
para a equipe.
O sucesso dessa metodologia reside na sua
capacidade de oferecer visibilidade e transparência
ao processo de desenvolvimento. Através da
identificação e remoção de ineficiências, as equipes
Chico Alff - 127

conseguem aprimorar continuamente seus
métodos, criando uma abordagem mais eficiente e
eficaz.
Ao proporcionar uma compreensão holística
das operações, o Kanban não apenas enfoca a
otimização do fluxo de trabalho, mas também
promove uma cultura de aprendizado constante,
onde as equipes podem se adaptar e evoluir de
acordo com as demandas do ambiente empresarial
dinâmico.
Ao adotar princípios ágeis para melhorar a
eficiência, destaca a importância de uma
abordagem centrada na colaboração e na resolução
proativa de problemas. Além de proporcionar uma
visão mais clara e transparente do processo de
desenvolvimento, o Kanban incentiva a
responsabilidade coletiva pela identificação e
eliminação de obstáculos.
Dessa forma, promove-se não apenas uma
melhoria contínua no processo, mas também uma
cultura de engajamento e cooperação, fundamentais
para enfrentar os desafios dinâmicos inerentes ao
Chico Alff - 128

Chico Alff - 129

Princípios Fundamentais do Kanban
Os princípios fundamentais do Kanban
orientam sua abordagem única no desenvolvimento
de software, proporcionando uma estrutura flexível e
adaptativa para otimizar processos.
Inicialmente, destaca-se a importância de
começar com o processo já existente, reconhecendo
e respeitando a realidade atual da equipe e do
projeto.
Em seguida, o Kanban enfatiza a colaboração
e o consenso de todos os membros da equipe para
embarcar em um caminho de melhoria incremental.
Esses conceitos refletem a natureza
pragmática e centrada nas pessoas do Kanban,
destacando-se por sua aplicação prática e orientada
à evolução constante.
Chico Alff - 130

Os 3 princípios fundamentais do Kanban:
● Começar pelo processo já em andamento.
● Consenso entre todos os membros da equipe
para empreender melhorias incrementais.
● Respeitar os papéis e responsabilidades
existentes, especialmente na fase inicial.
Estes princípios constituem a espinha dorsal
do Kanban, moldando a metodologia para se
adequar a situações diversas. Ao começar com o
processo atual, o Kanban reconhece a realidade da
equipe, incentivando uma evolução orgânica.
O consenso da equipe impulsiona a
colaboração e a responsabilidade coletiva, enquanto
o respeito aos papéis existentes proporciona uma
transição suave para a abordagem Kanban.
Em síntese, o Kanban busca aprimorar
continuamente o processo de desenvolvimento,
promovendo uma evolução natural e adaptativa,
com foco na colaboração e eficiência.
Chico Alff - 131

Na prática, quando uma equipe adota a
abordagem do Kanban, sua meta é trilhar um
caminho de aprimoramento passo a passo,
buscando identificar problemas recorrentes,
encontrar padrões comuns e desenvolver soluções
contínuas.
A etapa de identificação de problemas
destaca como uma equipe pode se acostumar a
lidar com situações que ocorrem frequentemente,
passando a encará-las não mais como erros, mas
como resultados inevitáveis.
O Kanban inicia seu processo exatamente
nesse ponto: compreendendo como o trabalho é
realizado para subdividir o processo em fases que
ocorrem repetidamente, mas que podem ser
adaptadas, denominadas "Policies" no contexto do
Kanban.
Essas "Policies" representam as diferentes
etapas do processo de desenvolvimento ou as regras
que a equipe segue. O primeiro passo envolve o
reconhecimento das práticas existentes, a
identificação das fases que se repetem na
Chico Alff - 132

construção de software e a documentação dessas
práticas.
Cada equipe possui um sistema, que pode ser
mais formal e compreendido por todos, como em
metodologias como o Scrum, ou mais informal,
baseado no conhecimento compartilhado pela
equipe.
O Kanban facilita melhorias graduais,
promovendo uma abordagem passo a passo. A
avaliação dos resultados, crucial para determinar a
eficácia das mudanças realizadas, é facilitada por
ferramentas fornecidas pela metodologia,
contribuindo assim para o constante aprimoramento
do processo de desenvolvimento de software.
Existe uma distinção fundamental entre o
Kanban e os métodos tradicionais de
aprimoramento do processo produtivo.
Nos modelos tradicionais, as decisões são
tomadas pelo gerente e comunicadas aos
subordinados, percorrendo a hierarquia
organizacional.
Chico Alff - 133

Scrum, Kanban e Scrumban: o minimo que voce precisa saber.pdf

Scrum, Kanban e Scrumban: o minimo que voce precisa saber.pdf

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Scrum, Kanban e Scrumban: o minimo que voce precisa saber.pdf

Semelhante a Scrum, Kanban e Scrumban: o minimo que voce precisa saber.pdf (20)

Mais de Francilvio Roberto Alff

Mais de Francilvio Roberto Alff (6)

Scrum, Kanban e Scrumban: o minimo que voce precisa saber.pdf