Projetos Ágeis com scrum - teorico 4

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Projetos Ágeis com Scrum
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
Responsável pelo Conteúdo:
Prof. Me. Artur Ubaldo Marques Júnior
Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
Nesta unidade, trabalharemos os seguintes tópicos:
• Introdução;
• Sprint Review;
• Sprint Retrospective;
• Release Burndown;
• Release Burnup;
• Métricas Ágeis;
• Comunicação de Progresso em uma Release de 
Data Fixa no Scrum;
• Gestão Visual – Kanban;
• Visão Geral do Produto – Kanvas;
• Roteiro de Produtos Ágeis.
Fonte: iStock/Getty Im
ages
Objetivos
• Conhecer a parte pós-execução, as técnicas de visão geral e os controles.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
UNIDADE 
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
Contextualização 
O SCRUM não é, em hipótese alguma, um framework que preza pela anarquia!
Os controles são muito apurados e trabalham muitas vezes nas duas pontas (visão 
do que entregamos e visão do que falta entregar). Isso é importante porque mantém o 
povo de negócios alinhado e junto com o Time de Desenvolvimento e querendo ver o 
que já fizeram.
Da mesma forma, as famosas lições aprendidas são feitas como nas boas práticas 
de Projetos que em SCRUM podem ser vistas nas oportunidades de rituais, tais quais o 
Sprint Retrospective e o Sprint Review.
Em SCRUM também se conta com ferramentas poderosas como, por exemplo, a 
possibilidade de entendimento do escopo e do trabalho geral a ser feito no Projeto, usan-
do a visão geral do produto via KANVAS ou, até mesmo, a gestão visual do Backlog do 
sprint via quadros visuais do KANBAN.
Dessa forma, SCRUM se transforma num framework poderoso e completo para uso 
em Projetos de Software, obrigatório para o Analista de Sistemas, para o Programador 
ou para o Gerente de TIC, para acompanharem os novos tempos e se manterem com-
petitivos, com alto grau de empregabilidade e, claro, atualizados!
6
7
Introdução
Todos os rituais e artefatos SCRUM possuem intrinsecamente uma prática de con-
vergência de esforços. 
Essa convergência, muitas vezes, manifesta-se de maneira sutil, quase imperceptível, 
devido a ser um framework coletivo em que a construção do software é de todos. Toda-
via, quando estamos dentro de um Projeto SCRUM, percebemos que há controle, que 
há métricas e que há organização. 
Os rituais têm tempo certo, normas e comportamentos desejados; seus atores conhe-
cem seus papéis e o que se aguarda de suas performances. Para aqueles que acreditam 
que Metodologia Ágil ainda é anarquia, vamos apresentar logo mais como esses controles 
são realizados de forma que essa sensação de desordem desaparecerá completamente.
Vamos agora conhecer como e quais são os artefatos para controlar um Projeto 
SCRUM e mantê-lo nos trilhos, se for o caso.
Sprint Review 
A revisão do sprint é uma reunião envolvendo o Time scrum, o scrum master, o 
Product Owner, os clientes, os negócios e o gerenciamento de linha para apresentar o 
status do sprint executado e compará-lo ao compromisso assumido no início do sprint.
A revisão do sprint é uma sessão que fecha o sprint (entre 10 a 20 dias cada itera-
ção), na qual a funcionalidade proposta foi concluída e é demonstrada ao cliente ou aos 
seus representantes. 
Para o negócio, isso é definitivamente diferente em relação ao processo cascata, tipo 
waterfall. Eles veem os resultados com muita frequência e regularidade, o que ajuda a 
adotar o produto de acordo com as mudanças no Mercado.
Segundo o SCRUM DESK (2018) essa reunião tem alguns objetivos bastante claros; 
dentre eles, informar ao cliente de forma transparente sobre o trabalho que:
• Tem sido feito;
• Não foi feito;
• Foi adicionado;
• Foi removido do sprint.
Os clientes também são solicitados a fornecer um feedback dos resultados da Equipe. 
O que se espera que seja falado numa Reunião de Revisão de Sprint?
7
UNIDADE 
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
Tabela 1 – O que falar na Revisão de Sprint? 
O que falar na revisão de um sprint
Quando o sprint começou e terminou?
Quem trabalhou nos resultados?
Qual foi o objetivo do sprint?
O que foi planejado?
O que foi feito e o que não?
O que foi adicionado e o que foi removido do sprint?
Quais riscos e problemas foram descobertos?
Demonstração da funcionalidade desenvolvida.
Feedback dos participantes.
Informações sobre o próximo sprint.
Fonte: https://goo.gl/tMr5co
Como se trata de um ritual no SCRUM, os envolvidos, além de papéis, possuem 
comportamentos específicos que se espera deles.
Por exemplo:
• Product Owner – Espera-se que ele abra a reunião recordando os objetivos de 
sprint, apresente os requisitos principais que foram planejados e que a equipe 
scrum se comprometeu a entregar; aproveita, também, para passar uma visão 
geral do status de sprint e dá informações sobre melhorias realizadas e defeitos 
resolvidos durante o sprint focado na melhoria da qualidade;
• Scrum Master – Espera-se dele a organização da reunião, convidar os participantes 
e os participantes especiais se houver; atuar moderando tanto a reunião quanto os 
ânimos dos participantes e evidenciar a importância do feedback do cliente perante 
a Equipe;
• Time Scrum – Espera-se prontamente a informação dos status do sprint e a 
apresentação ao vivo da funcionalidade nele produzida.
É uma reunião para durar 60 minutos; não mais do que isso. Deve ser focada, pro-
dutiva, direta e eficaz.
Além disso, como dito, deve-se apresentar a funcionalidade em funcionamento; para 
tanto, recomenda-se uma apresentação seguindo a regra 10-20-30, a saber:
• Máximo de 10 (telas + fotos + vídeos + slides); menos é mais;
• Máximo 20 minutos. Isso inclui o tempo para perguntas, respostas e feedback;
• Fonte tamanho 30, pelo menos. Não use letras minúsculas, nem textos dificilmen-
te legíveis.
Se você mostrar melhorias de desempenho, compare-as com a versão anterior. Nos 
slides, trabalhe com títulos e subtítulos, não uma explicação completa dos problemas; 
fale sobre detalhes, mas não o escreva.
8
9
Há 5 dicas interessantes do SCRUM DESK (2018) para demonstrar a funcionali-
dade construída:
• Descreva o problema, a dor ou o ganho;
• Mencione quem é a pessoa (cliente ou usuário) fazendo esse trabalho; “sentindo a dor”;
• Explique o que é esperado como resultado correto;
• Demonstre a funcionalidade, de maneira simples, sem o uso de jargões técnicos ou 
palavras tecnológicas;
• Peça feedback imediatamente.
Sprint Retrospective
Diferentemente dos processos tradicionais que trabalham retrospectiva quando o 
Projeto acaba, normalmente chamados de “lições aprendidas”, para os que trabalham 
em frameworks ágeis como SCRUM, XP, TDD e outros, esse tipo de retrospectiva 
tradicional é chamada de post mortem, porque elaacontece no fim do Projeto, quando, 
realmente, não podemos tomar nenhuma atitude.
SCRUM lida com uma cerimônia específica para isso, chamada de Retrospectiva de 
Sprint. Nela, queremos melhorar nossa maneira de trabalhar enquanto o desenvolvi-
mento de Projeto ainda está ativo.
O SCRUM INSTITUTE (2018) relata que: “A retrospectiva é uma reunião regular 
da equipe para práticas de melhoria contínua, processos e também sentimentos dos 
membros da equipe”.
Nesta reunião, todos os membros da equipe refletem sobre o sprint passado e veri-
ficam três coisas: 
• O que foi bem durante o sprint; 
• O que não funcionou; 
• Quais melhorias poderiam ser feitas no próximo sprint. 
A reunião deve ter um horário pré-estabelecido, por exemplo, 2 horas. Sua impor-
tância está em que, sem ela, a Equipe nunca conseguirá melhorar sua produção geral e 
não poderá se concentrar no desempenho geral; portanto, sugestões para melhorar o 
desempenho do Projeto devem estar disponíveis no final da reunião.
Uma vez que este é um evento regular, os membros da equipe podem pensar em blo-
queadores e ideias continuamente e melhorar a maneira de trabalhar constantemente.
Uma dica importante é utilizar o modelo de SATIR para implementar uma mudança 
na intenção de não desmotivar a Equipe. 
Veja a seguir um exemplo desse modelo:
9
UNIDADE 
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
Figura 1 – Exemplo do Modelo de SATIR de uma mudança
Nesse caso, uma grande mudança é dividida em várias pequenas mudanças que 
podem se tornar realidade, melhorando a motivação e o envolvimento da equipe. 
Lembre-se de que qualquer alteração desacelera as pessoas. A retrospectiva regular 
ajuda a ter essa trincheira de mudança superficial e estreita.
Da mesma maneira que a revisão do sprint, a retrospectiva possui objetivos bastante 
claros; o SCRUM DESK (2018) nos informa da seguinte maneira:
• Identifique as restrições e os desperdícios do Sistema;
• Obtenha ideias para melhorias;
• Identifique o que funciona corretamente;
• Priorize propostas;
• Elabore um plano de ação para implementação de ideias selecionadas e preferidas.
O que se espera dos atores dessa reunião:
• Product Owner – Participará como um membro do Time, porque o que afeta o 
Time scrum, afeta todos;
• Scrum Master – Deverá organizar e moderar a reunião, identificar qual o tópico da 
retrospectiva, utilizar ou selecionar uma técnica para ideias, informar status quanto 
a problemas anteriores já solucionados e, é claro, acompanhar as propostas e a 
resolução dos problemas ativos;
• Time Scrum – Deverão propor ideias de solução e abordagem, votar as ideias 
que serão implementadas, chegar a um acordo de como implementar as propostas 
votadas e escolhidas.
Estamos tratando aqui de uma reunião que varia entre 1h10min e 2h, no máximo.
10
11
A seguir, um exemplo de técnica muito usada no SCRUM DESK (2018) para você 
poder utilizar em seu dia a dia em Projetos SCRUM.
Tabela 2 – Dinâmica para coleta de dados numa reunião de retrospectiva de sprint
DINÂMICA DA REUNIÃO DE RETROSPECTIVA
O Scrum Master identifica um tema da retrospectiva. 
O tema é selecionado com base na vida da equipe ágil nos últimos sprints.
A equipe está silenciosamente pensando em ideias e escrevendo-as no post-it.
Um post-it por ideia, para que possamos trabalhar com eles mais tarde. 
O tempo não é rigoroso, o Scrum Master deve observar se não é necessário mais tempo para fornecer um 
espaço para os membros da equipe darem um feedback.
A equipe lerá ideias e agrupará ideias semelhantes em grupos.
A equipe vota em ideias (grupos). 
Cada membro da equipe tem três pontos como um orçamento que pode ser distribuído em ideias.
Uma vez que a votação é feita, o Scrum Master prioriza as ideias baseadas num número de votos.
A equipe, então, discute as primeiras 1 até 3 ideias.
Propõe tarefas de implementação que podem ser adicionadas ao quadro Kanban para o próximo sprint.
O que se espera extrair como resultado de uma reunião de retrospectiva de sprint:
• Uma lista prioritária de novas propostas;
• O estado atualizado da solução de propostas de Sprints anteriores;
• Os itens de ação identificados para solução de design;
• As tarefas que serão atribuídas aos membros da equipe com os prazos definidos.
Por fim, o SCRUM DESK (2018) propõe o uso do Lean Change Management, de 
Jason Little, para implementar ideias e recomenda os seguintes passos durante a reu-
nião de retrospectiva de sprint:
• Insight – Análise do problema sob diferentes perspectivas;
• Opções – Identificação de múltiplas opções que devem ser consideradas; é até su-
gerido tentar várias opções e escolher a melhor (semelhante ao teste A/B);
• Experimento – O objetivo do experimento é validar os resultados esperados defi-
nidos pelas opções.
INSIGHTS
(START HERE)
EXPERIMENT
OPTIONS
PREPARE
INTRODUCE
REVIEW
Figura 2 – Modelo de mudança Lean
11
UNIDADE 
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
Release Burndown
O progresso em um Projeto Scrum pode ser rastreado por meio de um Gráfico de 
conclusão de lançamento (Burndown Chart). 
Trata-se de um Gráfico simples, contendo 2 eixos: o vertical para a quantidade de 
trabalho logo no início do sprint (em pontos de história, dias ideais, dias da equipe etc.), 
e o horizontal em número de sprints.
St
or
y 
Po
in
ts
360
270
180
90
0
0 654321
Sprints
Figura 3 – Exemplo de Gráfi co de Burndown
No Burndown mostrado acima, a equipe iniciou um Projeto que foi planejado para 
ser seis sprints. Eles começaram com 360 pontos de história. Para terminar em 
seis sprints, eles planejaram uma média de 60 pontos por sprint. O primeiro sprint 
correu bem e completaram 90, deixando 270. As coisas continuaram a progredir 
bem durante o segundo sprint, mas durante o terceiro sprint, o trabalho estimado 
restante realmente foi queimado. Isso pode ter ocorrido porque o trabalho foi 
adicionado ao projeto ou porque a equipe alterou algumas estimativas do trabalho 
restante. Depois disso, as coisas correram bem novamente.
Portanto, cada ponto no Gráfico mostra quanto trabalho foi deixado para fazer no 
final desse sprint (dia, semana, mês ou outro período de tempo que você escolher). 
A revisão regular pelo Scrum Master dos Gráficos de Progresso pode identificar pro-
blemas imediatamente e permitir que você os controle antecipadamente. 
Identificar os problemas precocemente e destacar a ação corretiva que você tomou 
impressionará seus clientes e lhe dará confiança como líder de Projeto ou Scrum Master.
0
5
10
15
20
25
Burn Down
1/0
1/2
013
2/0
1/2
013
3/0
1/2
013
4/0
1/2
013
5/0
1/2
013
6/0
1/2
013
7/0
1/2
013
8/0
1/2
013
9/0
1/2
013
10/
01/
201
3
11/
01/
201
3
12/
01/
201
3
13/
01/
201
3
14/
01/
201
3
Ahead of scheadule
Behind schedule
Remaing Tasks
Figura 4 – Exemplo de Gráfi co de Burndown
12
13
Nesse caso, há uma linha ideal, há também um eixo horizontal onde o período de 
avaliação é dado em dias. Qualquer ponto acima da linha ideal significa que foi feito 
menos trabalho do que se previa e qualquer ponto a seguir da linha significa que 
foi entregue o trabalho antes do estipulado. Lembrando-se de que no eixo vertical 
a escala pode ser dada em pontos de história, itens do sprint, ou qualquer outra 
medida acordada entre a Equipe Scrum.
A quantidade de trabalho restante num Gráfico de Burndown é geralmente estimada 
pelo número de tarefas restantes a serem concluídas. Isso se deve à simplicidade e a 
menor quantidade de volatilidade nos números em comparação às estimativas de tempo 
associadas às tarefas.
Os Gráficos de Burndown são utilizados porque usam um conceito visual simples e 
que permite a visualização do número de tarefas que faltam para tentar atingir a data 
definida com nenhuma tarefa a ser desenvolvida.
Clarios (2016 relata) que “[...] alguns gerentes também consideram os Gráficos Burn-
down como tendoum valor motivacional. Ver a linha cada vez mais próxima de zero 
encorajará e motivará os participantes do Projeto e demonstrará claramente que o pro-
gresso está sendo feito.”
Release Burnup
 O Gráfico de Burnup rastreia o progresso em direção à conclusão de um Projeto. Na 
forma mais simples de Gráfico de Gravação, existem duas linhas: a linha de trabalho total, 
também conhecida como linha de escopo do Projeto, e outra linha de trabalho concluído.
Burn Up
1/0
1/2
013
2/0
1/2
013
3/0
1/2
013
4/0
1/2
013
5/0
1/2
013
6/0
1/2
013
7/0
1/2
013
8/0
1/2
013
9/0
1/2
013
10/
01/
201
3
11/
01/
201
3
12/
01/
201
3
13/
01/
201
3
14/
01/
201
3
Completed
0
10
20
30
40
5
15
25
35
Total
Client addes work
Work removed to
meet deadline
Figura 5 – Exemplo de Gráfi co Burnup
Um Gráfico de Burnup mostra claramente o trabalho concluído e o escopo do projeto. 
O projeto será concluído quando as linhas se encontrarem. O eixo vertical é a quanti-
dade de trabalho e é medido em unidades personalizadas para o seu próprio projeto.
13
UNIDADE 
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
Algumas unidades comuns são o número de tarefas, as horas estimadas ou os pon-
tos de história (em metodologias ágeis de gerenciamento de projetos). O eixo hori-
zontal é o tempo, geralmente medido em dias. A cada dia, você pode ver a quanti-
dade de trabalho concluído e a quantidade total de trabalho. A distância entre as 
duas linhas é, portanto, a quantidade de trabalho restante. Quando as duas linhas 
se encontrarem, o projeto estará completo.
Esses Gráficos podem permitir que você identifique instantaneamente certos ti-
pos de problemas, como um desvio de escopo ou um desvio do caminho planejado 
do Projeto. 
Esses problemas podem ser discutidos e ações corretivas podem ser tomadas num 
estágio inicial, e isso é visto como a marca positiva de um Gerente de Projetos eficaz. 
Compartilhar esses Gráficos com os clientes também pode gerar confiança na sua admi-
nistração e no progresso do Projeto como um todo. 
Como sabemos, o Gráfico de Burnup, a exemplo do de Burndown, não são enges-
sados e permitem que sejam inseridas outras linhas. A preferida é a linha de progresso 
ideal; nesse caso, baseada no escopo total distribuído uniformemente no Gráfico.
Veja o exemplo a seguir.
Burn Up
1/0
1/2
013
2/0
1/2
013
3/0
1/2
013
4/0
1/2
013
5/0
1/2
013
6/0
1/2
013
7/0
1/2
013
8/0
1/2
013
9/0
1/2
013
10/
01/
201
3
11/
01/
201
3
12/
01/
201
3
13/
01/
201
3
14/
01/
201
3
Completed
0
10
20
30
40
5
15
25
35
Total
Ahead of schedule
Behind schedule
Ideal 
Figura 6 – Exemplo de Gráfi co de Burnup com linha ideal inserida
Um Gráfico de queima com uma linha ideal, mostrando onde o projeto está adian-
tado e onde está atrasado. O que está acima da linha pontilhada verde está adian-
tado; o que está a seguir está atrasado. A linha vermelha do total do trabalho sofreu 
acréscimos de escopo. A linha azul demonstra como foi o comportamento do time 
para alinhar as entregas e vencer o desafio.
14
15
Métricas Ágeis
Aqui apresentaremos alguns outros tipos de Gráficos e Medidas importantes para que 
o Gestor de Projetos Ágil possa utilizar, principalmente, num Projeto SCRUM.
Clarios (2016) descreve como sendo composto de uma série de linhas ou áreas repre-
sentando a quantidade de trabalho em diferentes estágios de progressão.
Por exemplo, no desenvolvimento de software, os estágios típicos para o desenvol-
vimento de um recurso são:
• Não foi iniciado;
• Design;
• Codificação/Desenvolvimento;
• Teste e controle de qualidade;
• Completo.
Num diagrama de fluxo cumulativo, o número de recursos em cada estágio de desen-
volvimento é plotado para cada dia no Gráfico.
0
2
4
6
8
10
12
14
16
18
1/
01
/2
01
3
10
/0
1/
20
13
9/
01
/2
01
3
8/
01
/2
01
3
7/
01
/2
01
3
6/
01
/2
01
3
5/
01
/2
01
3
4/
01
/2
01
3
3/
01
/2
01
3
2/
01
/2
01
3
Not Started
Testing
Complete
Coding
Design
Figura 7 – Diagrama de Fluxo Acumulativo
Um diagrama de fluxo cumulativo é confuso, à primeira vista. No entanto, as principais 
conclusões do Gráfico são as seguintes: o projeto será finalizado quando a área com-
pleta (azul escuro) for mesclada com a área não iniciada (azul clara). A altura vertical 
de cada área mostra quanto trabalho está atualmente nesse estágio. Um alargamento 
vertical de uma área específica mostra um gargalo no seu processo de desenvolvimen-
to que deve ser investigado caso seja necessária uma ação corretiva (a área vermelha é 
um exemplo disso – teste é gargalo, nesse projeto). A distância horizontal da linha não 
iniciada até a linha concluída é o lead time do projeto. O lead time é o tempo médio de 
uma solicitação de recurso para uma implementação ser concluída. 
15
UNIDADE 
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
Esse tipo de diagrama pode ser muito útil no planejamento de ações corretivas, como a 
reatribuição de recursos, desde o desenvolvimento, até o teste, para que a entrega do Projeto 
volte aos “trilhos” do cronograma; portanto, são muito úteis para o Scrum Máster, o Product 
Owner e a Equipe do Projeto porque permitem um bom feedback e correção do Projeto.
Comunicação de Progresso em uma 
Release de Data Fixa no Scrum
Esse conceito é interessante porque, quando uma Empresa utiliza o recurso de libera-
ções com data fixa, é porque ela sabe o número de sprints para cada liberação.
“Lembre-se de que uma liberação é quando o que foi desenvolvido vai para a produ-
ção; isso pode ser em um sprint ou se juntam alguns sprints e libera-se de uma vez. Isso 
depende do estilo da Empresa e do gestor em acordo com o Time scrum”.
Bom, como escrevemos, há organizações que usam um release de data fixa e seu 
objetivo é comunicar o intervalo variado de recursos que eles esperam concluir e o pro-
gresso de sprint para sprint em direção ao fim.
Para isso, podemos usar uma versão modificada do Gráfico de Burnup, de forma 
mais intuitiva e direta, ou seja, com um backlog do produto invertido (pilha de trabalho 
invertida) mostrado como eixo vertical e o número de sprints como o eixo horizontal 
(veja como fica isso no exemplo da Figura 8, logo a seguir). 
Figura 8 – Progresso em uma release de data fi xa no scrum
Conforme os sprints vão sendo executados, a organização pode ver de forma macro 
qual dos ‘must-have’ (os que precisam estar no software) foram entregues, os que 
permanecem no backlog, e onde eles serão alcançados, baseando-se, é claro em 
uma linha de tendência projetada na velocidade real da equipe.
16
17
Gestão Visual – Kanban
Agregar valor é um dos maiores objetivos de um Projeto Ágil com SCRUM e muitas 
técnicas são utilizadas para realizar essa missão. Este “fluxo para apresentar valor” co-
meça com um conceito inicial e, lógico, a sua previsibilidade, move-se por vários está-
gios, incluindo o desenvolvimento, indo até a liberação final e a sustentação.
Uma das formas de agregar valor é a transparência e o quadro KANBAN é ideal para 
ser usado com SCRUM. Isso ocorre por meio da utilização de um quadro (físico: lousa ou 
virtual: Software Trello) para o gerenciamento visual do trabalho de uma Equipe scrum 
e para melhorar a entrega de produtos e serviços em termos de previsibilidade, qualida-
de e desempenho e time-to-market.
O Kabanize (2018) descreve que um quadro Kanban é uma ferramenta para mapear 
e visualizar seu fluxo de trabalho como auxiliar do framework SCRUM, que ajuda em: 
• Visualizar os gargalos e os pontos fracos do fluxo de trabalho;
• Concentrar-se no trabalho atualmente disponível;
• Eliminar em parte a necessidade de reuniões básicas de atualização de status.
A palavra Kanban, de origem japonesa, quer dizer registro ou placa visível. O Kan-
ban foi originalmente construído usando um quadro branco; ele é dividido em colunas e 
raias. Cada coluna representa um estágio do fluxode trabalho, enquanto as raias sepa-
ram diferentes tipos de atividades. Quando uma tarefa entra em seu fluxo de trabalho, 
ela é colocada num cartão Kanban, que passa por cada coluna do quadro.
Há várias formas de se nomear as colunas, mas as preferidas em SCRUM são:
• Requisitadas;
• Em progresso;
• Teste/Liberação;
• Feita.
Exemplos de quadros Kanban utilizados em projetos de sistemas no SCRUM: 
https://goo.gl/ttzK5y e https://goo.gl/VsAqex
O quadro Kanban é uma ferramenta perfeita para visualizar problemas potenciais 
em seu processo. A lógica é simples: se você vir uma coluna na qual as tarefas che-
gam mais rápido do que elas saem, o trabalho começará a se acumular e o problema 
ficará visível para toda a Equipe. Isso pode ser causado por um problema temporário 
ou por um gargalo no seu processo.
Como você pode observar na Figura, para um mapeamento mais detalhado do seu 
processo, há a liberdade de criar quantas subseções forem necessárias para visualizar seu 
fluxo de trabalho com a máxima precisão.
17
UNIDADE 
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
Para usar é simples: a cada sprint, coloque as tarefas na caixa (a fazer) e o Time 
Scrum vai pegando esses cartões e movendo pelas colunas existentes. 
Você delimita quantos cartões cada um pode pegar e quanto o Time pode pegar para 
evitar gargalos e concentração de trabalho numa única pessoa. A partir daí, monitore e 
verifique os tempos que levam essas fichas para se deslocarem de uma coluna a outra, 
até sua liberação final em “Feito”.
Faças as correções necessárias no fluxo, elimine os impeditivos e gargalos e mante-
nha o foco de aprendizagem de sua Equipe.
Visão Geral do Produto – Kanvas
Ramos (2016) descreve de forma simples a possibilidade de usar um quadro de apoio 
para o Time Scrum ter uma visão macro de uma necessidade de negócio usando a Téc-
nica Project CANVAS. 
É uma técnica visual que exibe de forma direta o que precisa ser feito e qual a visão 
do produto. 
O Product Owner pode utilizar esse artefato de apoio para explicar as ideias do Pro-
jeto para o Time Scrum e o Scrum Master.
Sua utilização é direta e intuitiva.
Tabela 3 – Exemplo de Quadro Kanvas para a visão macro do Produto 
que será produzido num Projeto de Software gerenciado pelo SCRUM
THE PRODUCT VISION BOARD
Visão Conceder acesso aos amantes de música a um acervo de qualidade com diversos artistas de renome
Público Necessidades Produto Metas de Negócio
Homens e Mulheres que 
curtem música de diver-
sos ritmos
• Tenha Acesso à Internet;
• Tenham o desejo de co-
nhecer novas músicas;
• Preferem uma grande 
variedade de músicas.
• Acesso a grande varie-
dade de músicas sem 
ter que comprá-las;
• Descoberta de novos 
artistas e novos ritmos;
• Acesso a artistas que 
estão na moda.
• Serviço de Streaming 
de Música
• Entregue por meio de 
Mobile App e Web;
• Recomendações Au-
tomáticas de Músicas 
com base em perfil;
• Compra de músicas 
para tocar Off-line.
• Receita com assinatura 
recorrente;
• Receita com Comissão 
de Venda por Músicas;
• Ser uma marca de des-
taque orientada pelo 
comportamento do con-
suminador.
Algumas dicas importantes para que o Product Owner possa aproveitar junto à Equi-
pe Scrum seriam, conforme Mindmaster (2018):
• Definir com clareza a necessidade do usuário ou a oportunidade de Mercado que o 
seu produto visa a resolver;
• Identificar o perfil médio do usuário do seu produto;
• Identificar potenciais concorrentes que eventualmente possam estar no Mercado;
• Discutir como o produto pode gerar receitas.
18
19
Roteiro de Produtos Ágeis
Pichler (2016) descreve um roteiro de produtos ágeis como sendo “Um roadmap 
de produto, uma ferramenta para descrever como um produto pode crescer, alinhar os 
interessados e obter um orçamento para o desenvolvimento do produto do projeto”. 
Todavia, ele alerta que a criação de um roteiro eficaz não é fácil, particularmente num 
contexto ágil em que as mudanças ocorrem com frequência e inesperadamente.
Esse roteiro se baseia em alguns princípios que deverão ser seguidos para que sejam 
eficazes. Isso é muito útil para um Product Owner que deseja ser claro e convincente ao 
Time Scrum e ao Scrum Master:
• Focar nos objetivos e benefícios do Projeto;
• Realizar um bom trabalho de preparação em que se descreve e valida a estratégia 
do produto;
• Contar uma história coerente e convincente, sem muitas voltas e minúcias, princi-
palmente, sobre o provável crescimento do produto do Projeto de Software;
• Manter o roteiro do produto o mais simples, sem detalhamento excessivo. Isso 
ocorrerá naturalmente no decorrer da execução do Projeto Scrum e nas reuniões 
para se criar o backlog do Projeto. Atenção, os detalhes, incluindo épicos, histórias 
de usuários, cenários e designs de interface do usuário, pertencem ao backlog do 
produto e não ao seu roteiro;
• Assegurar um forte buy-in, ou seja, o melhor roteiro é inútil se as pessoas neces-
sárias para desenvolver, comercializar e/ou consumir o produto do software não 
comprarem a ideia. A melhor maneira de criar um acordo é colaborar com os prin-
cipais interessados; fazendo isso, você envolverá a todos;
• Ter coragem de dizer não quer dizer que você não deve dizer sim a todas as ideias e 
solicitações que façam a você. Isso transformaria seu mapa de produto numa sopa 
de recursos, uma coleção aleatória na qual tudo terá alta prioridade e tudo será 
necessário. Cuidado!;
• Saber quando mostrar as datas, isso significa que, se for um roteiro externo que 
é mostrado aos clientes e usuários e frequentemente usado como uma ferramenta 
de vendas do Projeto, recomenda-se fortemente que não sejam mostradas datas ou 
prazos. Isso faz parte de outro momento do Projeto junto ao Time de Desenvolvi-
mento, que poderá se comprometer com datas porque, afinal de contas, são eles 
e não você que farão o Projeto de Software. Ao invés de atribuir datas, atribua a 
prioridade dos desejos, quem deve ser o primeiro etc.;
• Tornar o roteiro mensurável, orientar o roteiro por metas, como explicado no item 
anterior; ouse, declare um alvo ou alvos;
• Determinar o custo top-down; afinal, você está ofertando uma visão macro. Até por-
que, é praticamente impossível derivar as epopeias e as histórias de usuário corretas dos 
recursos do roteiro, obter estimativas corretas de sua equipe e antecipar com precisão 
a velocidade e a taxa de alteração no backlog do produto. Como já expliquei, há o 
19
UNIDADE 
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
momento certo para isso: quando o Time estiver debruçado sobre o backlog do pro-
duto. Monte uma sugestão de Time, que pessoas, que habilidades, que quantidade...;
• Rever constantemente o roteiro e o ajustar para mantê-lo atualizado e a visão de 
todos alinhada. O motivo é simples: Projeto para produto novo de software com 
Mercados/negócios dinâmicos precisarão de revisões mensais, outros mais está-
veis, a cada trimestre, por exemplo.
Tabela 4 – Exemplos de “GO Product Roadmap” com o template original de Pichler (2016)
THE GO PRODUCT ROADMAP
DATE
The realease date or 
timeframe
Date or timeframe Date or timeframe Date or timeframe
When will the realease be available?
NAME
The name of the new 
realease
Name/Version Name/Version Name/Version
What is it called?
GOAL
The reason for creating the 
new realease
Goal Goal Goal
Why is it developed? Witch benefit does it offer?
FEATURES
The high-level features 
necessary to meet the goal
Features Features Features
What are the 3-5 key features?
METRICS
The metrics to determine if 
the goal has been met
Metrics Metrics Metrics
How do we know that the goal is met?
THE GO PRODUCT ROADMAP
DATA DO 
REALEASE
Q1 2016 Q2 2016 Q3 2016 Q4 2016
NOME V 1-0 V 1-5 V 2-0 V 2-5
META
Lançar o serviço no 
mercado
Aumentar utilização dos 
usuários
Introduzir serviço de 
recomendação de 
músicas por perfil
Iniciar faturamentorecorrente
FUCIONALIDADES
• Biblioteca de Músicas;
• Criação de conta de 
usuários;
• Busca;
• Compra de músicas;
• Playlist personalizada;
• Botão like/deslike 
para músicas;
• Ranking de Populari-
dade;
MÉTRICAS
• Qtde de novas con-
tas criadas;
• Usuários que retor-
naram após 7 dias 
de inscrição;
• Qtde de compra de 
músicas;
Agora que você já aprendeu os rituais, os artefatos, as técnicas de controle das entre-
gas e da evolução do Projeto SCRUM, bem como as ferramentas de apoio, você pode-
rá, utilizando todo esse material, realizar a atividade final prática para criar um Projeto 
SCRUM pronto para rodar.
A atividades está explicada no fórum desta Unidade.
20
21
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Planejando uma Sprint
https://youtu.be/gyMa7L34xoA
Visão de produto no SCRUM
https://youtu.be/vg1S1WYZa6o
 Leitura
A utilização do Scrum em um sistema web: um estudo de caso
https://goo.gl/7kUWgr
Análise de Gerenciamento de Projeto de Software utilizando Metodologia Ágil XP e Scrum: um 
estudo de caso prático.
https://goo.gl/wDdLgz
21
UNIDADE 
Reuniões de Revisão, Retrospectiva, Métricas, 
Projetos de Larga Escala e Visão de Case de Projeto
Referências
CLARIOS. What is a burndown chart? 2016. Disponível em: <http://www.
clariostechnology.com/productivity/blog/whatisaburndownchart>. Acesso em: 30 
jul. 2018.
KANBANIZE. What Is a Kanban Board? 2018. Disponível em: <https://kanbanize.com/
kanban-resources/getting-started/what-is-kanban-board/>. Acesso em: 30 jul. 2018.
MINDMASTER. Como Planejar um Projeto Ágil: A Estratégia dos 3 Níveis, 2018. 
Disponível em: <http://www.mindmaster.com.br/como-planejar-um-projeto-agil/>. 
Acesso em: 30 jul. 2018.
PICHLER, R. The Go Product Roadmap. 2013. Disponível em: <http://www.
romanpichler.com/blog/goal-oriented-agile-product-roadmap/>. Acesso em: 30 jul. 2018.
RAMOS, C. Agile Adoption Canvas. SCRUM.ORG, 2016. Disponível em: <https://
www.scrum.org/resources/blog/agile-adoption-canvas>. Acesso em: 30 jul. 2018.
SCRUM DESK. Sprint Retrospective. 2018. Disponível em: <https://www.scrumdesk.
com/start/manual-for-scrumdesk-start/sprint-retrospective/>. Acesso em: 30 jul. 2018.
______. Sprint Review Meeting. 2018. Disponível em: <https://www.scrumdesk.
com/start/manual-for-scrumdesk-start/sprint-review/>. Acesso em: 30 jul. 2018.
SCRUM INSTITUTE. Sprint Retrospective Meeting. 2018. Disponível em: <https://
www.scrum-institute.org/Sprint_Retrospective_Meeting.php>. Acesso em: 30 jul. 2018.
22