Ferramentas e Práticas que complementam o Scrum; Confira

O Scrum é propositalmente incompleto, no Guia Scrum (2020) está definido o mínimo necessário para praticar o framework. Então, é possível acoplar a ele novos processos, ferramentas e técnicas que ajudem a alcançar os objetivos do projeto.

O Scrum é propositalmente incompleto, no Guia Scrum (2020) está definido o mínimo necessário para praticar o framework. Então, é possível acoplar a ele novos processos, ferramentas e técnicas que ajudem a alcançar os objetivos do projeto.

As ferramentas e práticas ágeis mais utilizadas são:

Design Thinking
Project Model Canvas
Roadmap do Produto
Caixa da Visão do Produto (Product Vision Box)
História de Usuário (User Story)
Técnicas de Priorização: MoSCoW, Valor para o Cliente e de Mapeamento de História
Técnicas de Estimativas: Planning Poker e T-Shirt Sizing
Velocidade e Capacidade do Time Scrum
Quadro Kanban
Jira
Quadro Scrum (Scrum Board)
Gráfico de Burndown
Técnicas de Retrospectiva

Design Thinking

O desenvolvimento de produtos ou serviços está longe de ser uma tarefa simples. Então, considerando um projeto complexo que vai passar pelo processo ágil completo, suas etapas iniciais podem ser iniciadas com o Design Thinking. Sendo que suas etapas são:

Imersão
1. Pesquise sobre o produto que se deseja desenvolver, além de analisar mercado e a concorrência. Usualmente são utilizadas ferramentas já conhecidas como Análise FOFA (SWOT), feedback de clientes, benchmarking, etc.

Ideação
1. Realize reunião de brainstorming. Durante a reunião de brainstorming a ideia de produto começa a ganhar forma e se identificar alguns requisitos que precisam ser detalhados posteriormente.
Prototipação
1. Terceira etapa do processo, onde são gastas horas em testes e experimentação.
2. É o momento onde o time escolhe quais ideias têm maior probabilidade de dar certo, e que será desenvolvida na última etapa de implementação.
Implementação
1. A última etapa do Design Thinking é desenvolver o produto e, por fim, levar a solução ao público, lançando-o no mercado de acordo com a estratégia de marketing previamente definida.

No mundo ágil, o Design Thinking é largamente utilizado na “Sprint Zero“. Deve ser utilizado quando o Time Scrum está entendendo o escopo do projeto, conhecendo os requisitos, definindo quais tecnologias serão usadas, etc. O trabalho fruto da técnica do Design Thinking pode ser revisado continuamente durante as Sprints.

2. Project Model Canvas (PMC)

Outra ferramenta muito utilizada na fase inicial do projeto é o Project Model Canvas. O PMC é uma metodologia de gestão de projetos que de forma visual mostra as diversas áreas de conhecimento de um projeto para facilitar a compreensão de todos os envolvidos. Essa metodologia facilita a identificação de problemas e aumenta a objetividade na comunicação.

Conforme demonstrado no Canvas anterior, o Projeto é abordado em duas etapas: GP e Pitch.

GP
1. Justificativa – Liste os problemas que justificam o projeto;
2. Objetivo SMART – Defina os objetivos do projeto utilizando a técnica SMART;
3. Benefícios – Liste quais benefícios a empresa vai alcançar após a implantação do Projeto;
4. Produto – Informe qual será o produto ou serviço final do projeto;
5. Requisitos – Quais requisitos o Projeto deve atender, seja de qualidade ou de valor ao cliente.

Pitch
1. Stakeholders – Identifique quais são os intervenientes do projeto;
2. Equipe – Informe quem será parte da equipe do projeto;
3. Premissas – São as suposições que favorecem o projeto;
4. Restrições – São as limitações que limitam o trabalho dentro do projeto;
5. Grupos de Entrega – Liste os grupos de entregas ou features do projeto;
6. Riscos – São as suposições que se ocorrerem impactarão no projeto;
7. Linha do Tempo – Defina quando os grupo de entrega vão ocorrer;
8. Custos – Liste os custos previstos para o projeto.

A ferramenta cria um planejamento de projeto mais simples de entender e é elaborado de forma colaborativa com o time.

O PMC é de responsabilidade do(a) Dono(a) do Produto. Também é largamente utilizada na “Sprint Zero” e revisada sempre que necessário durante as Sprints.

3. Roadmap do Produto (Product Roadmap)

O Roadmap do Produto é uma demonstração gráfica de alto nível das entregas do produto, mostrando através de um quadro que mapeia a evolução do produto ao longo do tempo. O Product Roadmap funciona como um guia estratégico para o Time Scrum planejar a evolução do produto ao longo do tempo.

Por exemplo, no modelo abaixo mostra roteiro estratégico que divide o projeto em times e suas tarefas individuais.

O Roadmap do Produto é de responsabilidade do(a) Dono(a) do Produto, que tem objetivo de comunicar estratégias de execução do do produtos para todo Time Scrum e partes interessadas.
Usualmente é realizado na “Sprint Zero”, quando o Time Scrum está entendendo o escopo do projeto, os requisitos, definindo quais tecnologias serão usadas, qual prazo de cada feature, etc. Deve ser revisado pelo(a) Dono(a) do Produto frequentemente durante as Sprints, desta atualização se obtém os desvios em relação ao planejamento inicial.

4. Caixa da Visão do Produto (Product Vision Box)

O Vision Box é uma técnica simples, bem visual e lúdica, promovida por Jim Highsmith, que pode ser usada pelo Time Scrum como ferramenta de apoio para desenvolvimento da Visão do Produto.

O Vision Box é desenvolvido em colaboração com o Time Scrum, podendo envolver outros intervenientes do projeto através de workshops para explanar sobre o projeto e desenhar na caixa os atributos do produto.

Passos adaptados e simplificados para implantar o Vision Box:

Preparação
1. Apresente uma caixa quadrada para o Time. Esta não deve apresentar qualquer informação ou marca, preferencialmente, de cor branca para facilitar ao escrever nela.
Frente da Caixa
1. Nome do Produto – escreva o nome do produto ou serviço;
2. Características do produto ou serviço – para quê o produto ou serviço servirá e quais principais características. Por exemplo, “Saas vendido por usuário ou multi-usuários”;
Laterais da Caixa
1. Gráfico – desenhe um gráfico do produto ou serviço
2. Escreva três ou quatro palavras-chaves para “vender” o produto;
Verso da Caixa
1. Uma descrição detalhada da função do produto;
2. Liste requisitos operacionais.

Também devem ser discutidos temas que não cabem na caixa, como por exemplo: escopo, cronograma, custo, benefícios e prioridades; Missão do Produto, Principais necessidades dos clientes; Critérios de medição da satisfação do cliente; Limitações do produto em relação a desempenho, facilidade de uso, etc., e indicadores financeiros, ROI esperado e critérios de lançamento de MVP, dentre outros tópicos relevantes.

O Vision Box é de responsabilidade do(a) Dono(a) do Produto. Pode ser utilizada pelo Time Scrum na “Sprint Zero” como ferramenta de apoio para desenvolvimento da Visão do Produto.

5. História de Usuário (User Story)

Um Épico é um conjunto amplo de funcionalidades ou requisitos. Trata-se de uma História de Usuário grande demais para ser concluída em uma única Sprint, por isso deve ser decomposta em Histórias menores (realizar o breakdown), pois do tamanho em que se encontra é impossível iniciá-la, desenvolvê-la e concluí-la em uma Sprint. Ao quebrar Épicos em Histórias de Usuário, facilita entendimento sobre o que deve ser desenvolvido, aumenta a percepção de progresso, reduz o risco ao tempo de uma Sprint, fica mais fácil de estimar sua complexidade e prever quanto tempo para finalizá-la.

“Uma história de usuário é uma promessa para uma conversa.”

– Cockburn, 1998

Indo mais além, uma História de Usuário é uma descrição sucinta de funcionalidades ou requisitos do produto na visão do usuário, buscando sempre descrever a necessidade de uma forma simples e objetiva. A História do Usuário descreve “o quê”, o “por quê” e “quem” em relação ao desenvolvimento de uma funcionalidade ou requisito. Neste aspecto a História do Usuário tem o mesmo objetivo dos Casos de Uso do UML (Unified Modeling Language).

5.1 História de Usuário INVEST

Para garantir a qualidade de uma História do Usuário deve seguir o modelo INVEST, acrônimo de Independent, Negotiable, Valuable, Estimable, Small e Testable, sendo que:

Independent (Independente) – As Histórias de Usuário podem ser implementadas em qualquer ordem, visto que não são dependentes uma das outras e não podem virar gargalo ou bloquear outras.
Negotiable (Negociáveis) – As Histórias de Usuário não são contratos com itens pré-definidos e inflexíveis. Os detalhes podem ser negociados com o(a) Dono(a) do Produto (PO) a qualquer momento. Sempre que os Desenvolvedores tiverem dúvidas podem convocar o(a) Dono(a) do Produto (PO) para elucidá-las.
Valuable (Valiosa) – As Histórias de Usuário devem gerar valor ao cliente. Se for considerado sem valor, ou “perfumaria”, não deve ser implementada.
Estimable (Estimável) – A complexidade de todas as Histórias de Usuário devem ser estimadas, podem usar por tamanho T-Shirt Sizing ou por pontos de complexidade, seguindo a sequência de Fibonacci (1,2,3,5,8,13, 21…).
Small (Pequena) – Histórias de Usuário menores, são mais fáceis de serem estimadas. Existe uma boa prática de criar Histórias de Usuário de no máximo três dias de duração, além disso, ficará complicado garantir que siga o modelo INVEST.
Testable (Testável) – Uma boa história de usuário deve ser testável para garantir que foram implementadas conforme esperado.

Abaixo apresento um exemplo utilizando o padrão mais conhecido de História de Usuário, originado do XP, também referenciado como “Eu como… eu quero… para que…”, para uma aplicação de consulta de pesquisa de discos on-line:

Título	Pesquisa on-line de Discos
História de Usuário	Eu, como um usuário do sistema de pesquisa on-line, quero pesquisar discos para comprá-lo com meu cartão de crédito.
Descrição	Eu sou um roqueiro que estou utilizando um site de empresa que vende vinil e quero pesquisar discos de forma fácil e precisa. Eu quero pesquisar em diferentes critérios, como nome da banda, categoria, álbuns e músicas. Gostaria de ter a possibilidade de ordenar por álbuns, ano, preço e avaliações de outros usuários, para refinar ainda mais minha busca. Além disso, gostaria de salvar meus favoritos para compras futuras.
Definição de Pronto	Esta História de Usuário passou em todos os testes previstos.A documentação foi elaborada ou revisada.Esta História de Usuário está integrada e validada.Esta História de Usuário foi revisada pelo PO.

Complementarmente, pode-se acrescentar a Definição de Preparado (DoR) e o Critério de Aceitação:

Definição de Preparado

A interface do usuário foi aprovada antes de iniciar o desenvolvimento. Esta História do Usuário foi priorizada pelo Dono(a) do Produto. Esta História do Usuário foi estimada pelos Desenvolvedores. Esta História do Usuário é pequena suficiente para ser implementada em uma Sprint. Todas as dependências foram sanadas antes de iniciar o desenvolvimento. Documentação necessária estão disponíveis para os Desenvolvedores.

Critério de Aceitação

O usuário pode adicionar os discos selecionados ao carrinho de compras. O usuário é capaz de verificar um resumo do carrinho, com quantidade de itens e o preço total. O usuário consegue digitar na barra de pesquisa e obter resultados precisos. O Usuário consegue salvar os discos favoritos para compras futuras. Aparecem recomendações à medida que for digitando na barra de pesquisa. Deve ser responsivo para outros dispositivos. A tela para pagamento com cartão de crédito é um sítio seguro com medidas de segurança.

As Histórias de Usuário devem ser criadas pelo(a) Dono(a) do Produto ou pelos Desenvolvedores, quando delegado pelo(a) PO, e devem ser discutidas, estimadas, decompostas em partes menores (subtarefas), detalhadas pelos Desenvolvedores durante o decorrer da Sprint.

Não confunda Definição de Pronto com Critérios de Aceitação ou Definição de Preparado (DoR). Esta é uma questão usualmente feita em exames e em entrevistas técnicas para agilistas.

5.2 História de Usuário Spike (User Story Spike)

As Spikes são um tipo especial de História de Usuário utilizada para pesquisas, design, prototipação, etc. São Provas de Conceito (Proof of Concept – POC) para reduzir riscos, entender melhor os requisitos, aumentar a precisão das estimativas, fazer testes com novas tecnologias, dentre outras possibilidades. Produzem informação útil para o projeto e não é necessariamente um incremento valioso do produto. Usualmente, o resultado de uma Spike é conhecimento. As Spikes são estimadas e fazem parte do Backlog do Produto, normalmente são menores que uma Sprint, podem variar de 1 a 5 dias.

Prompts I.A.

– Sugerir História de Usuário

“Por favor, atue como um experiente Dono(a) do Produto e faça a decomposição do Épico [Informe o detalhes do Épico]para um projeto de [Informe o objetivo e detalhes de seu projeto].

A história do usuário deve ser clara, concisa e descrever uma funcionalidade ou requisito específico. Deve representar as necessidades e expectativas dos usuários e fornecer um contexto relevante para o desenvolvimento do produto.

Sua história de usuário deve seguir o formato: “Como um (usuário), eu quero (realizar uma ação) para (alcançar um objetivo)”.

Certifique-se de criar a História de Usuário utilizando a técnica INVEST (Independent, Negotiable, Valuable, Estimable, Small e Testable) e incluir detalhes suficientes para que os Desenvolvedores entendam facilmente o que é necessário para implementá-la.

Considere os requisitos do usuário, os objetivos do projeto e as restrições técnicas ao criar a história do usuário”.

– Aprimorar História de Usuário

“Por favor, atue como um experiente Dono(a) do Produto e aprimore a descrição da história de usuário [informe a História do Usuário detalhada], fornecendo mais detalhes, contexto e clareza.

Sua descrição revisada deve comunicar claramente os objetivos, motivações e resultados desejados do usuário de maneira concisa e compreensível. Observe que sua descrição revisada deve ser específica e prática, fornecendo uma orientação clara para a equipe de desenvolvimento implementar a história do usuário de maneira eficaz”.

6. Técnicas de Priorização

As seguintes técnicas mais utilizadas para priorizar o Backlog do Produto são: MoSCoW, Valor para o Cliente e de Mapeamento de História (Story Mapping).

6.1 Técnica de Priorização MoSCoW

MoSCoW é uma técnica utilizada para priorização dos Itens do Backlog do Produto (PBI). MoSCoW é um acrônimo, que significa:

Deve ter (M – Must Have) – São requisitos obrigatórios que devem ser entregues, caso contrário o projeto será considerado um fracasso.
Deveria ter (S – Should Have) – Estes são requisitos que também são críticos para o sucesso do projeto, mas não são necessários para Sprint mais recentes.
Poderia ter (Co – Could Have) – Requisitos que poderiam ser entregues, mas são menos críticos.
Não terá (W – Won’t Have) – São requisitos menos críticos e de menor retorno financeiro e de valor para o cliente ou que não são apropriados naquele momento.

O MoSCoW é usualmente realizado pelo(a) Dono(a) do Produto em reunião específica para priorização dos Itens Backlog do Produto (PBI) em colaboração com os Desenvolvedores. O Backlog do Produto Priorizado deve ser revisado continuamente durante as Sprints.

Prompts I.A.

– Priorização com MosCoW

“Por favor, atue como um experiente Dono do Produto e priorize o Backlog do Produto utilizando a técnica de MoSCow [informe o Backlog do Produto, com esforço e estimativas].

Certifique-se em separar o Backlog do Produto por Must Have, Should Have, Could Have e Won’t have”.

6.2 Técnica de Priorização por Valor ao Cliente

Esta técnica concentra-se no valor que cada Épico oferece ao cliente. Os Épicos com maior valor para o negócio do cliente é decomposta em Histórias de Usuário e são desenvolvidos primeiro. Desta forma, ao priorizar por valor ao cliente o(a) PO garante que os incrementos mais valiosos sejam desenvolvidos e entregues mais antecipadamente, trazendo benefícios ao negócio mais cedo.

Exemplo de Priorização por Valor ao Cliente:

Épicos	# Histórias de Usuário	Valor
Melhorias de Interface do Usuário	Aprimorar a usabilidade do aplicativo	Alto
Melhorias de Interface do Usuário	Adicionar tema escuro	Baixo
Integração de Notificações por E-mail	Notificar usuário por e-mail lembrando-o sobre as tarefas	Alto
Integração de Notificações por E-mail	Alterar preferência de notificação	Médio
Compartilhamento de Atividades	Compartilhar tarefas com outros usuários	Alto
Compartilhamento de Atividades	Alterar permissões de compartilhamento	Médio

De acordo com a priorização acima, a sequência de trabalho de desenvolvimento das Histórias de Usuário será:

História do Usuário 1 – Aprimorar a usabilidade do aplicativo – Alto valor ao cliente;
História do Usuário 3 – Notificar usuário por e-mail lembrando-o sobre as tarefas – Alto valor ao cliente;
História do Usuário 5 – Compartilhar tarefas com outros usuários – Alto valor ao cliente;
História do Usuário 4 -Alterar preferência de notificação – Médio valor ao cliente
História do Usuário 6 – Alterar permissões de compartilhamento – Médio valor ao cliente
História do Usuário 2 – Adicionar tema escuro – Baixo valor ao cliente

Para aplicar esta técnica o(a) PO usualmente utiliza aplicações on-line ou planilhas eletrônicas.

6.3 Técnica de Mapeamento de Histórias (Story Mapping)

O mapeamento de Histórias de Usuário é uma técnica usada por times ágeis para ajudar no planejamento e entendimento do fluxo de trabalho, criando um mapa de desenvolvimento.

No exemplo a seguir, fica claro quais Histórias de Usuário devem ser desenvolvidas primeiro (da release 1), de quais features e de quais Épicos:

Resumidamente, a seguir um passo-a-passo adaptado de como criar um Mapeamento de Histórias:

Crie os Épicos
1. Colabore com os Desenvolvedores, identifique os Épicos e cole-os no primeira linha do mapa;
Identifique as Features
1. Colabore com os Desenvolvedores, identifique as Features dos respectivos Épicos e cole-os na segunda linha do mapa;
Crie as Histórias de Usuário
1. Colabore com os Desenvolvedores e decomponha as Features em História de Usuário menores;
2. Se em qualquer momento o Time Scrum identificar que a História de Usuário está muito grande para caber em uma Sprint esta deve ser decomposta em outra História de Usuário menor.
Defina as Release
1. Colabore com os Desenvolvedores e identifique na horizontal as Releases das respectivas Histórias do Usuário;
Repita
1. Colabore com os Desenvolvedores, revise o mapa, decomponha ou crie novas Histórias de Usuário sempre que necessário.

O Mapeamento das Histórias é de responsabilidade do(a) Dono(a) do Produto com objetivo de comunicar o Backlog do Produto Priorizado para o Time Scrum e partes interessadas. Este mapeamento é usualmente criado na “Sprint Zero” e atualizado frequentemente durante as Sprints, desta atualização se obtém os desvios em relação ao planejamento inicial.

7. Técnicas de Estimativas

As técnicas que são mais utilizadas pelos times ágeis são: Planning Poker e T-shirt Size.

7.1 Planning Poker

O Planning Poker é a técnica para estimar complexidade das Histórias de Usuário amplamente usada pelas organizações ágeis.

Na estimativa de Pontos de Complexidade é atribuído um valor para cada História de Usuário. Por exemplo, um total de 100 pontos são distribuídas em 3 Histórias de Usuário A, B e C, cujas complexidades foram definidas pelos Desenvolvedores como: 20 pontos para História de Usuário A, 40 para a B e 40 para a C.

Conclui-se que de acordo com o entendimento dos Desenvolvedores as Histórias B e C têm complexidades similares e são mais complexas que a A.

Vale ressaltar que a técnica de definir Pontos não é determinístico, é uma técnica de estimativa análoga, ou seja, trata-se de comparação das complexidades entre as Histórias de Usuário.

Essa ferramenta utiliza um baralho com cartas baseadas na sequência de Fibonacci (1, 2, 3, 5, 8, 13, 21…). Usualmente são apresentadas cartas até a complexidade 21 para evitar que as Histórias do Usuário fiquem com complexidades muito díspares. Além dos números existem as cartas de “?” e de xícara de café (☕), cujos significados são, respectivamente: “Necessidade de maior esclarecimento” e “Pausa de 5 minutos na discussão”.

Para esta técnica existem infinidade de aplicativos e sítios na internet que oferecem este tipo de serviço. Faça uma pesquisa na internet e escolha o que melhor atende a sua necessidade.

Passos para estimar utilizando o Planning Poker:

Preparação
1. O Time Scrum define o maior número de carta que será utilizado para estimar as Histórias de Usuário, então as Histórias maiores que o número máximo não devem ser estimadas e voltam para o Backlog do Produto para serem mais detalhadas até chegar a uma granularidade ideal; Time Scrum
2. Escolha duas Histórias de Usuário, uma de menor complexidade, por exemplo de 1 story point, e outra de maior complexidade possível, por exemplo de 21 story points. Estes serão as Histórias nas quais os Desenvolvedores se nortearão para definir a complexidade das demais Histórias; Desenvolvedores do Produto
Jogue as cartas
1. Apresente as Histórias dos Usuários e, em seguida, questione os Desenvolvedores quanto a estimativa da complexidade; Dono(a) do Produto
2. Escolha uma carta de acordo com seu entendimento. Sendo que, quanto maior o número da carta mais complexo será o desenvolvimento;
3. Se houver consenso, ou seja, se todas as cartas tiverem o mesmo número, então a complexidade é esta que foi apresentada, então, comece a estimar a complexidade de uma nova História de UsuárioDesenvolvedores do Produto
4. Se houver divergência, quem apresentou o menor e o maior valores de complexidade devem explicar o motivo da escolha. Desenvolvedores
5. Após as explicações, faça uma nova rodada de estimativa de complexidade.
6. Se houver consenso, ou seja, se todas as cartas tiverem o mesmo número, então a complexidade é esta que foi apresentada, então, repita os passos anteriores com uma nova História de Usuário. Desenvolvedores do Produto
7. Caso contrário, o(a) Scrum Master pode incentivar a discussão até chegar ao consenso ou atribuir à História de Usuário em questão a maior complexidade sugerida pelos Desenvolvedores. Scrum Master
8. Se algum membro do time achar necessário pode lançar mão da carta de “?” para dirimir qualquer dúvida que porventura exista com o(a) Dono(a) do Produto ou apresentar carta de café ☕ para uma parada obrigatória, caso a discussão não esteja sendo produtiva ou o Time Scrum esteja cansado.
Encerre o jogo
1. Realize estimativa de todos os itens do Backlog da Sprint. Desenvolvedores do Produto
2. Se sobrar tempo realize estimativa das próximas Sprints, caso o timebox da reunião se esgote, finalize o jogo. Desenvolvedores do Produto

O(A) Scrum Master deve ficar atento(a) para não deixar que o Time Scrum perca o foco principal que é estimar a complexidade de todas as Histórias de Usuário do Backlog da Sprint. Também, deve ficar atento(a) às regras que muitas vezes são criadas, como limitar a três rodadas por História de Usuário, se não houver consenso na segunda rodada, a terceira rodada será considerada a complexidade mais votada, dentre outras. As regras são criadas antes da Reunião de Planejamento da Sprint pelo Time Scrum.

É normal que as primeiras estimativas não sejam precisas. No decorrer do das Sprints o time se tornará mais experiente e começará a dominar a técnica, se tornando especialistas em estimativas ágeis.

O Planning Poker acontece nas reuniões de Planejamento da Sprint e de Refinamento do Backlog do Produto.

7.2. T-Shirt Sizing

A complexidade das Histórias de Usuário é definida como o tamanho de camisas: P (Pequeno), M (Médio), G (Grande) e GG (Muito Grande).

Após esse primeiro refinamento utilizando esta técnica, as Histórias de Usuário podem ser decompostas de acordo com cada tamanho, podendo ser utilizadas outras técnicas para refinar a estimativa.

Esta técnica é usualmente utilizada para estimar Épicos, que ainda não temos muitos detalhes, mas que por experiência sabemos que são P (Pequenos), M (Médios) ou G (Grandes). Ela acontece nas reuniões de Planejamento da Sprint e de Refinamento do Backlog do Produto.

8. Velocidade e Capacidade do Time Scrum

Tanto a Velocidade quanto a Capacidade do Time Scrum são métricas opcionais, mas são bastante difundidas no mundo ágil. Veremos-as com mais detalhes a seguir:

8.1 Velocidade

🎯 A Velocidade é a quantidade de Backlog do Produto transformada em incremento durante a Sprint.

A velocidade e a Capacidade estão inter-relacionadas. Por exemplo, se um time entrega 256 pontos durante Sprints anteriores, podemos inferir que a sua capacidade é 256 pontos por Sprint. Logo, se durante o Planejamento da Sprint subsequente houver mais pontos que 256 os Desenvolvedores podem recusar as histórias de menor prioridade para evitar se comprometerem com mais trabalho além de sua capacidade.

Conhecer estas métricas auxilia na previsibilidade do Backlog do Produto, garantindo previsões de entregas em futuro próximo mais assertivas. Por exemplo, se a Sprint é de 1 mês (ou 4 semanas), se o Backlog do Produto soma 1.536 pontos, e a velocidade do time é de 256 por Sprint, significa que a estimativa para “queimar” todo o Backlog do Produto é de 6 Sprints (1.536 / 256 = 6) ou 6 meses de desenvolvimento, se não houver qualquer oscilação em relação ao escopo, tamanho do time, mudança tecnológica, etc.

Vale ressaltar que qualquer mudança no time, na tecnologia utilizada, etc. irá, sem dúvidas, provocar variações na velocidade. Por exemplo, quando entra um novo desenvolvedor no time é muito provável que a velocidade do time reduza até que o novo elemento seja treinado e trabalhe de forma autônoma, no mínimo será necessário alocar um outro desenvolvedor mais experiente para ensiná-lo os processos e forma de trabalho.

Não é salutar comparar a velocidade entre dois times, visto que os times normalmente possuem perfis e experiência diferentes, desta forma é como se comparar banana com maçã, ambos são frutas, mas com atributos completamente diferentes.

Quando o time não possui uma velocidade definida, deve selecionar Histórias de Usuário que os Desenvolvedores acreditam que podem iniciar, desenvolver e finalizar durante a Sprint. Ao final da Sprint deve-se analisar se a estimativa inicial ocorreu conforme planejado, caso contrário, deve-se ajustar conforme a velocidade realizada. A partir dessa primeira experiência, será obtida uma velocidade inicial, que será ajustada continuamente nas subsequentes Sprints.

O Time Scrum normaliza a sua velocidade após algumas Sprints, normalmente após a terceira, que será utilizada como base para as próximas Reuniões de Planejamento da Sprint e previsões do futuro.

8.2. Capacidade

A Capacidade do Time Scrum pode ser utilizada como uma métrica complementar a Velocidade para fins de planejamento. A Capacidade é encontrada através da soma de todas os dias ou horas ideais dos Desenvolvedores durante o período da Sprint, se o(a) Scrum Master e/ou o(a) Dono(a) do Produto desenvolvem, então seus dias/horas devem ser consideradas também.

No exemplo em que temos:

5 Desenvolvedores;
Sprint de 2 semanas (10 dias úteis);
– 1 dia de feriado no meio da Sprint;
Sem férias no período da Sprint.

A capacidade do time é calculada da seguinte forma:

(5 * 10) – (5 * 1) = 50 – 5 = 45 dias ou 360 horas, considerando 8 horas diárias de expediente).

Normalmente, não consideramos os 45 dias na Reunião de Planejamento da Sprint, isso porque sabemos que nelas estão incluídas horas improdutivas, que não são usadas para o Desenvolvimento, mas que invariavelmente ocorrem durante a execução da Sprint, com por exemplo, pausas no expediente para o cafezinho, ir ao banheiro, socialização entre colegas de trabalho, horas para resolver problemas pessoais, lentidão de recursos tecnológicos, etc.

Em relação às horas improdutivas, existe uma convenção de descontar -20% do dia/hora ideal da capacidade do Time Scrum. Sendo assim, ainda considerando o exemplo acima, temos uma nova capacidade de 36 dias (ou 288 horas úteis), sendo:

(5 * 10 * -20%) – (5 * 1) = 40 – 5 = 40 dias (ou 320 horas).

No exemplo anterior, 40 dias úteis deve ser o valor máximo de Capacidade do time a ser considerado na Reunião de Planejamento da Sprint.

Desta forma o Time Scrum assegura que o que for planejado para Sprint atual é realmente exequível. Esta técnica mostrou-se útil para redução de horas extras e para evitar sobrecarga no time.

8.3. Cálculo de Produtividade

Descontar -20% do dia ideal é uma convenção, uma informalmente utilizada para descontar a média das horas de improdutividade da Capacidade do Time. Alternativamente, os desenvolvedores podem ratificar o valor de produtividade/improdutividade utilizando em seu dia-a-dia um aplicativo de time tracking para medir o tempo real de desenvolvimento de dois ou mais membros do time e, assim, encontrar a média de horas produtivas/improdutivas que devem ser consideradas para fins de planejamento.

9. Quadro Kanban

Kanban significa Quadro Visual (*Kan = visual | ban = quadro*). É uma ferramenta muito utilizada por organizações ágeis.

Originalmente construído usando um quadro em branco, ele é dividido em colunas. Cada coluna representa uma etapa do fluxo de trabalho, por exemplo, “em Backlog”, “Planejado”, “Desenvolvendo”, “Testando”, “Feito”.

Quando uma tarefa entra no seu fluxo de trabalho, ele é colocado no Quadro Kanban, que à medida que é desenvolvido passa por cada coluna ou etapa do quadro, seguindo o fluxo previamente definido, como exemplificado anteriormente.

Deve ser utilizado para monitorar o fluxo de trabalho durante a Sprint. Sua atualização é diária até o término do projeto e é de responsabilidade dos Desenvolvedores. O(A) Scrum Master deve orientar e acompanhar a atualização diária do quadro.

10. Jira

Em todas as pesquisas, o Jira é de longe a ferramenta mais poderosa e utilizada pelos times ágeis. Nela pode-se configurar quadros Scrum e Kanban, dentre outros métodos, inclusive metodologias mistas.

Se bem utilizada você pode gerenciar facilmente KPIs ágeis, Backlog da Sprint, Roadmaps, Gráficos de Burndown/Burnup, etc. Com ela você pode planejar, acompanhar e gerenciar o Backlog do Produto em diversas visões.

Ela apoia o(a) PO no controle do Backlog do Produto, facilita a priorização dos Itens do Backlog do Produto, Versões de Releases e acompanhando o progresso do projeto através dos já citados radiadores.

Os Desenvolvedores se beneficiam da visualização do fluxo do trabalho, bem como informações de quem vai fazer o quê, detalhes das Histórias de Usuário, de DoD, de DoR, dependências, Critérios de Aceitação, de estimativas e priorização em um único local.

11. Quadro Scrum ou Scrum Board

Os Quadros Scrum (Scrum Boards) permitem que você visualize facilmente todas as atividades da Sprint, além disso, eles podem ser customizados ao projeto, criando-se colunas específicas do fluxo de trabalho, tal como feito no Quadro de Atividades Kanban. Os status de cada História de Usuário é facilmente mostrado nas colunas:

Também é possível criar raias com nome de cada desenvolvedor, por status, etc. O exemplo a seguir está por Épicos:

Um Quadro Scrum é um radiador de informação que garante a transparência nas informações. Ele “irradia” informações do projeto para os intervenientes do projeto, portanto, um radiador de informação bom é aquele que está atualizado. O Time Scrum deve definir o processo para mantê-lo atualizado, é desejável que a periodicidade seja diária logo após a reunião diária.

12. Gráfico de Burndown

🎯 O Gráfico de Burndown é o mais conhecido Radiador de Informação utilizado no mundo ágil. Ele apresenta graficamente o trabalho restante de uma Sprint, da Release, ou do Projeto distribuído no tempo.

O trabalho pode ser medido por pontos de complexidade que faltam para concluir o trabalho. A vantagem do gráfico é a simplicidade e poder mostrar o progresso da Sprint ou de etapas do Projeto.

Além de mostrar graficamente o trabalho restante, o Gráfico Burndown indicas antipadrões que podem ocorrer na fase de desenvolvimento e que devem ser analisados com mais atenção pelo Time Scrum, por exemplo:

O gráfico indica que o time está finalizando o trabalho mais cedo do que o previsto, Sprint após Sprint.

Deve ser porque ela está se comprometendo com menos atividades do que sua capacidade.

O gráfico indica que o time não está finalizando o trabalho conforme previsto, Sprint após Sprint.

Provavelmente o time está se comprometendo com mais atividades do que sua capacidade ou bloqueios estão ocorrendo durante a Sprint ou as Histórias de Usuário estão subestimadas, dentre outros.

O gráfico indica variações bruscas no realizado em vez de uma “queima” estável ou com pouca variação.

Deve ser porque o trabalho não foi “quebrado”, decomposto em partes menores como deveria ou as Histórias de Usuário estão sendo adicionadas/retiradas da Sprint ou as estimativas estão sendo revisadas com muita frequência durante a Sprint.

O Gráfico de Burndown é um radiador de informação que garante a transparência, portanto, um radiador de informação bom é aquele que está atualizado. O Time Scrum deve definir o processo para mantê-lo atualizado, é desejável que a periodicidade seja diária logo após a reunião diária.

Deve ser disponibilizado em local de fácil acesso a todos os intervenientes do projeto. Pode ser com representação gráfica em linhas ou em barras.

13. Técnicas de Retrospectivas

13.1 Retrospectiva do Veleiro (Sailboat retrospective)

A técnica de Retrospectiva de Veleiro é uma metáfora visual através da qual o Time Scrum deve identificar colaborativamente o que está ajudando ao time, qual seus objetivos, o que os está atrasando e quais os riscos que eles veem no futuro.

Ao passar por cada tópico o Time Scrum vai colando os as notas adesivas (post-its) no respectivo tópico que está sendo tratado no momento. Após todos colaborarem o Scrum Master revisa as notas adesivas e seleciona os mais relevantes para serem discutidos em grupo.

A Retrospectiva do Veleiro é uma excelente ferramenta, pois trás um pouco de diversão para a reunião através desta metáfora tornando-a mais agradável, menos formal.

“O que correu certo”, “o que correu errado” e “o que devemos melhorar”

Nesta técnica, durante a reunião, o(a) Scrum Master ou o facilitador pode abordar:

O que correu bem na atual Sprint

Por exemplos, todos timeboxes foram cumpridos e todas as Histórias de Usuário previstas na Sprint foram concluídas;

O que correu não tão bem

Exemplos: bloqueios de acesso, quedas de servidores, treinamento lentos, interrupções externas, etc; e

O que deve ser melhorado

Sugestões do time que deve ser melhorado em relação ao processo técnico, ao processo Scrum, pessoas e etc.

Ao término da reunião de Retrospectiva o Time Scrum deve apontar os detalhes da reunião e tomar as providências necessárias de acordo com o que foi conversado, inclusive discutir e decidir se um ou mais pontos podem ser transformados em História de Usuário para entrar nas próximas Sprints, garantindo a melhoria contínua.

Se quiser se aprofundar no Scrum, compre o livro Scrum Path+ : Seu caminho para agilidade, ou faça o curso Completo de Scrum. Escolha através dos botões abaixo:

Livro SP+

Curso SP+