Apostila do curso

Scrum em 1 hora
Heitor Roriz, MSc, CST
Conteúdo
Heitor Roriz, MSc, CST ............................................................................................................... 1
Introdução à Agilidade e ao Pensamento Lean............................................................................. 4
Manufatura Lean ....................................................................................................................... 4
A máquina que mudou o mundo .............................................................................................. 4
Os diversos Métodos Ágeis ....................................................................................................... 4
O Manifesto Ágil ........................................................................................................................ 4
Os 12 Princípios do Manifesto Ágil ........................................................................................... 5
Para ter Agilidade é preciso trabalhar de forma empírica ........................................................ 5
Origens do Scrum .......................................................................................................................... 6
The New New Product Development Game ............................................................................. 6
Valores e Pilares ........................................................................................................................ 6
O Framework Scrum hoje.......................................................................................................... 7
A Linguagem de Padrões Scrum .................................................................................................... 8
Histórico .................................................................................................................................... 8
Objetivo dos Patterns................................................................................................................ 8
Dicas de utilização ..................................................................................................................... 8
Composição de um pattern ....................................................................................................... 8
Os 3 papéis do Scrum .................................................................................................................. 10
Product Owner ........................................................................................................................ 10
Desenvolvedores ..................................................................................................................... 10
ScrumMaster ........................................................................................................................... 11
Os 5 eventos do Scrum ................................................................................................................ 12
Sprint Planning ........................................................................................................................ 12
Daily Scrum.............................................................................................................................. 13
Sprint Review .......................................................................................................................... 13
Retrospectiva do Sprint ........................................................................................................... 13
Sprint ....................................................................................................................................... 13
Os 3 artefatos do Scrum .............................................................................................................. 14
Product Backlog (PBL) ............................................................................................................. 14
Sprint Backlog (SBL) ................................................................................................................. 14
Incremento .............................................................................................................................. 15
As Definições de Pronto e Preparado ......................................................................................... 16
Acordos de Trabalho ............................................................................................................... 16

2
 Definition of Done ................................................................................................................... 16
Definition of Ready.................................................................................................................. 16
Estimativas em Scrum ................................................................................................................. 17
Separando tamanho de duração ............................................................................................. 17
Incerteza em projetos ............................................................................................................. 17
Medindo tamanho em Scrum ................................................................................................. 17
Story Points ............................................................................................................................. 17
Ideal Days ................................................................................................................................ 18
T-Shirt Sizes (tamanhos de camiseta) ..................................................................................... 18

3
Introdução à Agilidade e ao Pensamento Lean

Agilidade significa flexibilidade no processo de gestão ou produtivo. Ser Ágil significa ter Agilidade
nos seus processos e gestão. Essa necessidade vem desde a década de 60 e temos até hoje. Em
fevereiro de 2011 foi criado o Manifesto Ágil.
As organizações de hoje nasceram e floresceram no decorrer do século XVIII, XIX e XX, durante os
quais precisávamos entender a natureza do trabalho e da gestão. O século XXI traz novos desafios!

Manufatura Lean
Diferenciando-se da Manufatura Tradicional nascida na primeira década do século XX, a
Manufatura Lean ensina conceitos como a eliminação de desperdício (waste) e foco nos indivíduos
que produzem. Tais conceitos tornaram-se populares após a criação do Sistema de Produção da
Toyota (TPS) em 1962 por Taiichi Ohno.

A máquina que mudou o mundo

O livro "The Machine That Changed the World", publicado inicialmente em 1990 pelo autor James
Womack, foi o primeiro livro a revelar o sistema de produção lean da Toyota. Nesse livro Womack
forneceu uma descrição abrangente de todo o Sistema de Manufatura Lean e popularizou seus
conceitos no Ocidente.

Os diversos Métodos Ágeis

Com a popularização dos princípios e conceitos Lean, profissionais da indústria de software
passaram a incorporar tais ideias naquilo que faziam: desenvolvimento e gestão de projetos de
software. Isso levou ao surgimento dos Métodos Ágeis que temos hoje.

O Manifesto Ágil
Os criadores dos primeiros Métodos Ágeis eventualmente identificaram que seus métodos tinham
algo em comum e em 2001 se reuniram e descreveram o denominador comum entre todos os
métodos: o Manifesto Ágil e os 12 Princípios da Agilidade.

4
Os 12 Princípios do Manifesto Ágil

Para ter Agilidade é preciso trabalhar de forma empírica

Dividimos o trabalho em iterações, no Scrum chamamos de Sprints. A cada Sprint entrega-se um
incremento do produto ou solução para se receber feedback do cliente e assim ajustar
continuamente o produto.

5
Origens do Scrum

O Scrum nasceu em no final dos anos 80 a partir de pesquisas realizadas por Jeff Sutherland nos
laboratórios Bell, nos Estados Unidos. O nome Scrum foi utilizado para descrever o método por
causa da metáfora utilizada em um artigo escrito pelos pais da Gestão do Conhecimento, Takeuchi
e Nonaka. Esse artigo foi uma inspiração para o Scrum, de acordo com Jeff Sutherland. Atualmente
consideramos Jeff Sutherland e Ken Schwaber como os co-criadores do Scrum.

The New New Product Development Game

Nesse artigo publicado em 1986 na revista HBR (Harvard Business Review), Takeuchi e Nonaka
buscaram as empresas mais inovadoras da época para tentar descobrir o que elas tinham em
comum. Eles descrevem que as equipes nessas empresas (Honda, Xerox, etc.) tinham as seguintes
características:
1. Instabilidade inerente
2. Auto-organização
3. Fases de desenvolvimento sobrepostas
4. Controle sutil
5. Transferência organizacional de conhecimento

Valores e Pilares
Scrum tem 5 valores e 3 pilares, na figura abaixo. Não confunda os valores do Scrum com as 4
declarações de valor do Manifesto Ágil.

6
O Framework Scrum hoje

Na figura acima vemos os 11 elementos do Scrum. Desses 11 elementos, 3 são responsabilidades

do Time Scrum (Scrum Master, Product Owner e Developers), 5 são eventos (Sprint, Sprint
Planning, Daily Scrum, Sprint Review, Sprint Retrospective) e 3 são artefatos (Product Backlog,
Sprint Backlog, Incremento).
Jeff Sutherland se refere a esses 11 elementos como Scrum 3-5-3. Esse é o Core do Scrum, o
conteúdo descrito pelo Guia do Scrum. O Refinamento do Backlog não faz parte desse 3-5-3, mas
está descrito no Guia do Scrum como uma atividade recorrente sob responsabilidade do Product
Owner. Veja abaixo como seria a agenda de um Sprint de 2 semanas e as durações sugeridas das
reuniões.

7
A Linguagem de Padrões Scrum
Histórico
Os Padrões Organizacionais surgiram como uma técnica de modelagem organizacional durante os
anos 90 nos Laboratórios Bell sob a direção de Jim Coplien, Neil Harrison e Brendan Cain. Na
mesma época, Jeff Sutherland estava fazendo pesquisas e trabalhos empíricos para construir o
framework que conhecemos hoje como Scrum. Pequenos pedaços da pesquisa original no Bell Labs
se misturaram aos esforços de criação do Scrum, incluindo a noção de reuniões diárias que hoje
chamamos Daily Scrums. No final dos anos 90, Mike Beedle reuniu-se com alguns co-autores que
incluíam os fundadores de Scrum, Jeff Sutherland e Ken Schwaber, para escrever a primeira
Linguagem de Padrões Scrum.

Objetivo dos Patterns

Os patterns devem ser utilizados como soluções para os problemas do cotidiano. Pense nos
patterns como uma extenção do Guia do Scrum, uma ótima referência para resolver problemas.
Para quem está começando com Scrum, você ainda vai experienciar problemas, para ter uma ideia
de quais eles são e só então você irá usar os patterns. Geralmente quem não tem experiência, fica
confuso para que servem e como usar.
Um pattern é um problema seguido de uma solução, cuja efetividade já foi comprovada, com o
objetivo de resolver problemas recorrentes em organizações. Alguns exemplos:

Dicas de utilização
Existem hoje muitos patterns escritos e em utilização (de forma consciente ou não) por diversas
equipes e profissionais pelo mundo. Como Scrum Master ou profissional Scrum, ao enfrentar um
problema, não tente reinventar a roda, faça o seguinte:
1. Visite a base de conhecimento dos patterns em scrumplop.org
2. Busque pela categoria que mais se adequa ao seu problema, por exemplo, organização de
produto, melhoria de processo, etc.
3. Pesquise nessa categoria por um ou mais patterns que possam ajudar. Verifique a descrição do
contexto do pattern.
4. Realize um experimento e observe os resultados.

Composição de um pattern
Todo pattern começa com uma contextualização, de forma a se descrever o problema que ele se
propõe a resolver. Após isso, temos a descrição do pattern e geralmente um exemplo de utilização.
Veja abaixo:

8
Comece a usar Scrum em seus projetos e quando começar a identificar problemas e interferências
à sua forma de trabalho, revisite os patterns e experimente implantá-los na prática.

9
Os 3 papéis do Scrum

O Scrum tem apenas uma unidade de trabalho, o Time Scrum.

Dentro do Time Scrum temos três responsabilidades:
• Scrum Master
• Product Owner
• Developers (Desenvolvedores)
O que cada um faz diariamente é uma questão que depende da função da pessoa na empresa e da
sua experiência com o Scrum. O processo tem como sustentação os papéis, sendo assim, se um dos
papéis não opera de acordo, o processo não funcionará.

O Product Owner fala o quê deve ser feito;

Os Desenvolvedores determina como pode ser feito;
O Scrum Master garante que todos trabalham como um time coeso;
O Time Scrum possui as seguintes características de acordo com o Guia do Scrum:
• Auto-gerenciável: precisam apenas de uma direção e com isso são capazes de estabelecer
o necessário para realizar seu trabalho e cumprir suas metas;
• Pequeno: o Time Scrum deve ter um máximo de 10 pessoas. Um Scrum Master, um
Product Owner e oito Developers;

Product Owner
Uma pessoa apenas precisa ser responsável pelo Product Backlog (PBL). Esta pessoa precisa de
conhecimento de domínio profundo, visão de negócio, compreensão da tecnologia do produto,
dependências técnicas e a autoridade para forçar a classificação do backlog de forma a maximizar o
valor de negócio. Esse é o PO. Ele é responsável pelos seguintes conjuntos de atividades:
‣ Análise de negócio: criação e gestão do Product Backlog, dirimir duvidas do time sobre
funcionalidades, responder perguntas sobre critérios de aceitação, etc.
‣ Gestão de stakeholders: identificação e alinhamento de expectativas, report de progresso,
entrega de valor, calculo de ROI, etc.
Se a criação do PBL levar muito tempo ou requerir mais experiência que uma pessoa pode
fornecer, o Product Owner deve formar um Product Owner Team. Nesse caso, o PO atuará como
Chief Product Owner (CPO), mantendo a palavra final sobre a classificação e priorização do Product
Backlog.

Desenvolvedores
Não podemos alcançar a excelência em grandes desafios através apenas do esforço individual, pois
o maior poder na produção vem do trabalho em equipe. Desenvolvimento aqui se refere ao
desenvolvimento do produto ou serviço, não apenas desenvolvimento de software. Os
Desenvolvedores são aqueles responsáveis por implementar os itens de trabalho elencados e
priorizados no Product Backlog. Sendo assim, eles devem ter a capacidade e habilidade técnicas
para entregar o que for necessário.

10
ScrumMaster
O profissional que for o Scrum Master é responsável por garantir que o Scrum seja entendido e
corretamente aplicado. O ScrumMaster faz isso para garantir que o Time Scrum esteja aderente à
teoria, práticas e regras do Scrum.
O Scrum Master é um líder servidor para o Time Scrum. Ele(a) opera como facilitador(a) do
processo Scrum e do processo de trabalho da equipe, ajudando a organização, PO e
Desenvolvedores a compreenderem a filosofia kaizen, gerando e aplicando conhecimento Sprint
após Sprint. Ele sempre busca melhorar seu auto-conhecimento, pois é um Líder Ágil.
Como atividades do SM temos:
• Planejamento da agenda de um Sprint;
• Criação das agendas das reuniões;
• Remoção de impedimentos de todo o time;
• Suporte à organização, no que for preciso;
• Suporte aos gestores da empresa;
• Treinamento da equipe quando necessário;
Para mais informações sobre as responsabilidades do Scrum, leia o Guia do Scrum.

11
Os 5 eventos do Scrum

Todos os eventos do Scrum acontecem limitados a um timebox (intervalo pré-definido de tempo),

com data e hora pra começar e terminar. Isso significa que o ScrumMaster precisa planejar bem
cada evento facilitado por ele. Esse é seu papel como o facilitador do processo Scrum. O Sprint é o
evento principal, durante o qual o Time constrói o Incremento do Produto. Os 5 eventos do Scrum
são: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Retrospectiva do Sprint.

A figura acima apresenta o ciclo de vida de um projeto com Scrum. O Core do Scrum, descrito no
Scrum Guide não contempla tudo. Por exemplo, Preparação e Release Planning não estão no
Scrum, mas são momentos nos quais os profissionais precisam preparar a infraestrutura necessária
para que o Time Scrum comece a entregar valor no primeiro Sprint.

Sprint Planning
O Sprint Planning é o Planejamento do Sprint. Seu propósito é estimar a quantidade de atividades
que oos Desenvolvedores conseguem entregar até o final do Sprint, estando todos os membros do
time ocupados. Para preparar a agenda desse evento, o Scrum Master precisa pensar em
responder 3 perguntas:
1. Por que realizaremos esse Sprint? Aqui o Product Owner precisa informar como ele planeja
aumentar o valor do produto ou solução com esse Sprint. Assim, uma meta é estabelecida.
2. O que será feito para entregar valor? Aqui o Time Scrum seleciona de forma colaborativa
os PBIs que deverão cumprir a Meta do Sprint.
3. Como realizaremos o trabalho? Nesse ponto os Desenvolvedores pensam em que
atividades técnicas devem ser realizadas para que os PBIs sejam implementados.
O Sprint Planning possui como duração inferida 2 horas para cada semana de Sprint. Participantes
do evento: todo o Time Scrum.

12
Daily Scrum
O Daily Scrum é a ferramenta mais poderosa do Scrum contra o problema da má comunicação. É
um evento informal onde todos os Desenvolvedores se encontram de pé, com duração máxima de
15 minutos. O Daily Scrum ajuda o Time Scrum a se auto-gerenciar durante o Sprint,
compartilhando informação sobre o que foi feito, o que pode ser feito e identificando eventuais
impedimentos.
O ScrumMaster pode rastrear os impedimentos criando um Backlog de Impedimentos para que ele
possa controlar e ajudar a removê-los. Durante o evento, apenas são identificados eventuais
impedimentos, mas a remoção dos mesmos deve ocorrer após o Daily Scrum, a qualquer
momento.

Sprint Review
Durante o Sprint Review os Desenvolvedores e o Product Owner colaboram no sentido de aprender
mais sobre o produto em construção. Para isso, os Developers apresentam os PBIs que passaram
pela DoD (Definition of Done). Essa é a reunião na qual aprende-se sobre a solução ou produto em
construção. Participantes: Time Scrum. Duração inferida a partir do Guia do Scrum: 1 hora para
cada semana de Sprint.

Retrospectiva do Sprint
Essa talvez seja a reunião mais importante do Scrum. Trata de kaizen de processo e de pessoas.
Durante essa reunião o ScrumMaster, estando bem preparado, deve utilizar dinâmicas de grupo e
atividades colaborativas de forma a elencar pontos de melhoria e criar o seu Backlog de Melhorias,
que é um lista de kaizens a serem implementados pelo Time Scrum. Um kaizen é um item de ação
de melhoria de processo.
Uma Retrospectiva Agile não é uma simples reunião de lições aprendidas, sendo assim, evite
apenas discutir o que foi bom e o que foi ruim. Utilize patterns como por exemplo Happiness
Metric, Scrumming the Scrum e elabore e distribua uma agenda clara para alinhar a expectativa de
todos os participantes. Participantes: Time Scrum. Duração sugerida: 2 a 3 horas.

Sprint
O Sprint é o evento que dá o ritmo no Scrum. Seu timebox máximo é de um mês. Geralmente as
empresas trabalham com Sprints de 2 semanas. A duração do Sprint deve ser estabalecida e não
deve ser mais alterada, em raras exceções. A ideia desse evento é criar um ritmo de planejamento
e entrega. Com isso o Time Scrum se acostuma mais com o trabalho e entende melhor sua
capacidade de trabalho e entrega.

13
Os 3 artefatos do Scrum

Scrum tem apenas três artefatos: o Product Backlog, o Sprint Backlog e o Incremento (do produto
ou solução em construção).
Dependendo da necessidade organizacional, podemos adicionar mais artefatos ao projeto, pois
como o Scrum não é uma metodologia de gerenciamento de projetos, temos apenas esses três
artefatos.

Product Backlog (PBL)

O PBL é a fonte única de trabalho no Scrum. A descrição de todo o trabalho desejado e necessário a
ser realizado para a construção, manutenção ou extensão de um produto deve ser armazenada na
forma de PBI (Product Backlog Items) dentro do PBL. O PO gerencia o PBL e não se deve alterar o
conteúdo do PBL sem alinhamento prévio com o PO.
Os itens dentro de um PBL chamam-se PBIs (Product Backlog Items), que são os itens de trabalho.
Os PBIs próximos ao topo do backlog devem ter alta prioridade e são bem granulares, pois já serão
trabalhados no proximo Sprint. À medida que nos afastamos do topo, os PBIs tornam-se cada vez
menos granulares. Estes serão refinados no decorrer dos Sprints. Os PBIs mais próximos do fundo
do PBL são pouco granulares, porém granulares o suficiente para terem seu esforço de
desenvolvimento estimado em story points.

Os itens mais ao topo tem mais

prioridade e devem esta refinados.

Os itens mais ao fundo tem menos

prioridade e vão sendo refinados
de acordo com a necessidade,
durante os Sprints.

O Product Backlog deve ser criado antes de se começar a sprintar, seja na preparação (sprint zero)
ou no primeiro release planning (planejamento de entregas). Um vez criado, o PBL inicial deverá
ser refinado durante os Sprints, à medida que o desenvolvimento progride. O curso CSPO (Certified
Scrum Product Owner) dá detalhes iniciais de planejamento do projeto, criação e refinamento do
PBL.

Sprint Backlog (SBL)

Este artefato contém todas as atividades técnicas que o time estima poder fazer no decorrer de um
Sprint. É o plano de trabalho para um único Sprint apenas. Enquanto o PBL contém PBIs, o Sprint
Backlog contém SBIs, ou tarefas (tasks). O SBL é criado durante o Sprint Planning. O Sprint Backlog,
por ser um plano de trabalho, contém a Meta do Sprint, os PBIs que serão trabalhados e as tasks
pertencentes a cada PBI.

14
Incremento
O Time Scrum é responsável por entregar no final de cada Sprint (desde o primeiro até o último)
um incremento potencialmente entregável do produto ou solução sendo construído.
Isso significa que o incremento é funcional, ou seja, o cliente e o PO podem validá-lo, pois podem
ver algo funcionando, para que o cliente possa prover feedback ao Time Scrum.
Um incremento é algo que comporá uma entrega maior, uma vez que incrementos suficientes
sejam entregues. O Incremento é o artefato mais importante do Scrum, pois é aquele que permite
aos Desenvolvedores validar suas hipóteses (requisitos) no decorrer dos Sprints. Lembre-se que
requisitos de projeto são hipóteses que precisam ser validadas. O cliente só sabe o que ele
realmente PRECISA depois de ver algo funcionando. As ideias então começam a fluir e com isso o
Time Scrum aprende cada vez mais. Requisitos são hipóteses que precisam ser validadas
CONSTANTEMENTE.

15
As Definições de Pronto e Preparado
(Definition of Done e Definition of Ready)

Acordos de Trabalho
Essas definições são acordos de trabalho. A criação de acordos de trabalho é um técnica bastante
utilizada em Agile. Os acordos são criados com a ajuda do ScrumMaster em conjunto com os
Desenvolvedores e o Product Owner. O objetivo dos acordos é evitar atrito além do necessário
entre membros da equipe do projeto, tendo os acordos definindo o que se pode e o que não se
pode fazer, ou ainda, o que se espera de algo ou algum membro da equipe. Os acordos mais
comuns são: Definição de Pronto (DoD), Definição de Preparado (DoR).

Definition of Done
A Definição de Pronto (DoD) ou Definition of Done é um acordo de trabalho utilizado para
promover a construção do produto incorporando os pontos que determinam a qualidade de
construção, ou seja, é um checklist de qualidade do Time Scrum.
A ideia é não esperar acabar a construção dos incrementos do produto e então fazer uma inspeção
de qualidade, ao invés disso, constroem-se os incrementos planejando-se de forma sistemática
passar no controle de qualidade. A DoD deve ser criada antes de se começar os Sprints, seja
durante o Release Planning ou no primeiro Sprint de uma entrega. Uma vez criada, não deve ser
alterada por pelo menos uma entrega, a não ser que seja uma necessidade identificada pelo Time
Scrum. A DoD deve ser construída com inputs do Desenvolvedores (visão técnica) e inputs do
Product Owner (visão de negócio). O ScrumMaster deve facilitar a criação da DoD, mediando
ambas perspectivas e criando um checklist.

Definition of Ready
Esse acordo de trabalho serve para identificar se um PBI (Product Backlog Item) está preparado
para ser planejado e entregue em um Sprint, de acordo com a perspectiva dos Desenvolvedores.
Itens que náo cabem num [unico Sprint sáo chamados de Épicos. A DoR serve como uma checklist
para ajudar o Time Scrum a identificar se um PBI cabe ou não em um Sprint. Sua criação deve
ocorrer de preferência durante o primeiro Release Planning do projeto e receber ajustes para
torná-la mais restrita e mitigar os riscos de não entregar um PBI durante um Sprint.
A DoR funciona como um checlist para saber se um item de trabalho cabe ou não em um Sprint. Se
não couber, deve ser refinado. Utilize a DoR durante os Sprints para refinar os itens de trabalho do
Sprint subsequente.

16
Estimativas em Scrum
Separando tamanho de duração
Em Scrum não estimamos duração, estimamos tamanho para depois derivar a duração de um
conjunto de itens de trabalho.
Tamanho é uma qualidade inerente a qualquer produto, sendo definido pelas características de
cada produto. Por exemplo, na Engenharia de Software, tamanho está para o software assim como
o peso está para a massa, ou seja, é uma característica intrínseca ao software. Separamos tamanho
de duração para que possamos reduzir o impacto do Cone da Incerteza em nossas estimativas. A
incerteza estará sempre presente e a única forma de removê-la é adquirindo experiência com o
tempo, coletando feedback do que se produz à medida que o projeto progride.

Incerteza em projetos

Essa figura nos mostra que as estimativas (seja de custos ou duração) variam de acordo com a
quantidade de informação que temos no momento que estamos estimando. Só não temos variação
depois que entregamo o trabalho.

Medindo tamanho em Scrum

De forma a reduzir o impacto das incertezas em projetos, foi criada para o software uma
característica chamada tamanho. Essa característica foi replicada para projetos em geral e devido a
isso falamos hoje acerca de tamanho do projeto. Em Scrum, medidas de tamanho reduzem o
impacto da incerteza devido ao fato de que as unidades de medida levam em consideração a
incerteza do momento em que o produto é estimado e possuem como referência sempre o
Desenvolvedores em questão. Como medidas de tamanho tradicionais temos Pontos de Função
(PF), Pontos de Caso de Uso (UCP), Linhas de Código (KLOC). Em Scrum geralmente usamos Story
Points (Pontos de História). Duração é uma medida direta do tempo que se leva para implementar
algo (seja em horas ou dias ou semanas), enquanto o tamanho é o esforço para implementar algo.
Em Scrum, estimamos tamanho e derivamos a partir dele, a duração de um projeto ou de
determinada quantidade de escopo.

Story Points

Os Story Points são uma medida relativa do quanto uma História de Usuário (User Story) é maior ou
menor que outra. Quando medimos tamanho em Engenharia de Software, nos referimos ao
esforço de implementação. É uma unidade adimensional, pois trata apenas de proporção.

17
Considere dois PBIs: um PBI com 8 story points e outro com 2 story points. A pontuação de cada
um analisada individualmente não significa nada, pois como é uma comparação relativa,
precisamos de ao menos dois PBIs para que a pontuação faça sentido. Neste exemplo, o PBI de 8
story points possui 4 vezes mais esforço de implementação que o PBI de 2 story points, apenas isso.
Lembrando que temos como fatores de esforço: habilidade (que determina o tempo),
complexidade e risco. Para se medir em Story Points usamos a chamada Sequência do Planning
Poker (não confundir com a sequência de Fibonacci), veja abaixo.

Ideal Days
Um outra unidade de medida de esforço em Agile são os chamados Ideal Days. Um Ideal Day
equivale a um dia perfeito ininterrupto de trabalho, onde um membro da equipe não faz nada além
de trabalhar 100% focado. Como é uma unidade de medida direta ligada ao tempo, é mais fácil de
se começar a utilizar.

T-Shirt Sizes (tamanhos de camiseta)

Os Camanho de Camiseta também podem ser usado para medir tamanho. A diferença entre eles e
story points é que eles não informam quanto um PBI é maior ou menor que outro. Geralmente
variam entre XS, S, M, L, XL, XXL.

18