ESTIMATIVA EM SCRUM BASEADO EM PONTOS POR USER STORIES

Edimar Fernando Liberali1, Sérgio Akio Tanaka2

RESUMO: Cada vez mais os métodos ágeis têm despertado o interesse da comunidade de
Engenharia de Software como uma alternativa para o processo de desenvolvimento de
sistemas de uma maneira mais rápida, eficiente e que atenda as reais necessidades dos
clientes. Existem no mercado vários métodos disponíveis que utilizam a abordagem ágil e
que, por seguirem os princípios ágeis, apresentam uma série de atividades semelhantes no seu
processo de desenvolvimento. Este artigo apresenta os processos de estimativa pelo método
ágil Scrum baseado em pontos por user stories.

PALAVRAS-CHAVE: Métodos Ágeis, Scrum, User Stories.

1 INTRODUÇÃO

À medida que as organizações tornam-se cada vez mais dependentes da indústria do

software, ficam mais evidentes os problemas relacionados ao processo de desenvolvimento de
sistemas: alto custo, alta complexidade, dificuldade de manutenção, e uma disparidade entre
as necessidades dos usuários e o produto desenvolvido (SOMMERVILLE, 2003).
Acreditando que o processo utilizado é um dos motivos para a ocorrência desses
problemas, um segmento crescente da Engenharia de Software vem defendendo a adoção de
processos mais simplificados conhecidos como métodos ágeis, que visam à desburocratização
das atividades associadas ao desenvolvimento (FOWLER, 2001).

2 MÉTODOS ÁGEIS

A “indústria do software” sempre contou com métodos cujos processos de

desenvolvimento eram baseados em um conjunto de atividades predefinidas, descritas como
processos prescritivos (AMBLER, 2004), onde muitas vezes, o trabalho começava com o

1
Acadêmico do Curso de Pós Graduação em Engenharia de Software com Ênfase em Testes de Software da
Univel – Faculdade de Ciências Sociais Aplicadas de Cascavel.
2
Professor do Curso de Pós Graduação em Engenharia de Software com Ênfase em Testes de Software da
Univel – Faculdade de Ciências Sociais Aplicadas de Cascavel.
levantamento completo de um conjunto de requisitos, seguido por um projeto de alto-nível, de
uma implementação, de uma validação e, por fim, de uma manutenção (SOMMERVILLE,
2003).
A partir da década de 90, começaram a surgir novos métodos sugerindo uma
abordagem de desenvolvimento ágil onde os processos adotados tentam se adaptar às
mudanças, apoiando a equipe de desenvolvimento no seu trabalho (BECK, et. al., 2001).
Estes novos métodos surgiram como uma reação aos métodos tradicionais de
desenvolvimento de sistemas, ganhando com o passar dos anos um número cada vez maior de
adeptos.
Com o intuito de definir um manifesto para encorajar melhores meios de desenvolver
sistemas, em fevereiro de 2001 um grupo inicial de 17 metodologistas, entre eles, Robert C.
Martin, Jim Highsmith, Kent Beck e outros, formaram a Aliança para o Desenvolvimento
Ágil de Software, que formulou um manifesto contendo um conjunto de princípios que
definem critérios para os processos de desenvolvimento ágil de sistemas (AMBLER, 2004).
Os doze princípios (BECK, et. al. 2001), aos quais os métodos ágeis devem se adequar são:
a) A prioridade é satisfazer ao cliente através de entregas contínuas e freqüentes;
b) Receber bem as mudanças de requisitos, mesmo em uma fase avançada do projeto;
c) Entregas com freqüência, sempre na menor escala de tempo.
d) As equipes de negócio e de desenvolvimento devem trabalhar juntas diariamente;
e) Manter uma equipe motivada fornecendo ambiente, apoio e confiança necessários;
f) A maneira mais eficiente da informação circular através de uma conversa face-a-face;
g) Ter o sistema funcionando é a melhor medida de progresso;
h) Processos ágeis promovem o desenvolvimento sustentável;
i) Atenção contínua a excelência técnica e a um bom projeto aumentam a agilidade;
j) Simplicidade é essencial;
k) As melhores arquiteturas, requisitos e projetos provêm de equipes organizadas;
l) Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz.

3 SCRUM

O SCRUM é um framework utilizado para o desenvolvimento ágil de software de

forma iterativa e incremental, foi descrito por Ken Schwaber em 1996 (SCHWABER, 1996)
como um processo que aceita a imprevisibilidade do desenvolvimento de software e a
contorna através da adaptação constante, atingindo sucesso com numerosos desenvolvedores.
Scrum se destaca das demais metodologias ágeis por dar mais enfoque a área de
gerenciamento. O termo Scrum tem origem no esporte conhecido como Rugby (RISING,
2007). Neste esporte, “Scrum” ocorre quando jogadores de cada time colaboram entre si numa
tentativa de avançar juntos pelo campo adversário. (HIGHSMITH, 2002).
De acordo com seu criador (SCHWABER, 2004), Scrum foi criado a partir do
reconhecimento que desenvolvimento de software é muito complexo para ser planejado
corretamente desde o início. Baseando-se nos trabalhos de modelagem de processos de
Ogunnaike (OGUNNAIKE, et. al. 1992), Schwaber argumenta que quando o controle de
processos definidos não é aplicável, devido à complexidade das atividades intermediárias ao
alto custo ao corrigir produtos com defeito, processos empíricos devem ser aplicados.

3.1 SPRINTS

Projetos Scrum progridem em uma série de iterações chamadas Sprints, que ocorrem
num período de duas a quatro semanas. É recomendado que esse período se mantenha
constante ao longo do desenvolvimento do projeto, pois um período constante leva a um
melhor “ritmo”. O produto é projetado, codificado e testado durante o Sprint. A Figura 1
apresenta uma visão geral do Scrum em execução.
Através desta característica fixa, iterativa e incremental aonde a equipe "abraça" o
produto final aos poucos em partes iguais é que o Scrum triunfa sobre uma metodologia
tradicional onde de início (quando menos se conhece a mente do cliente) tenta-se "abraçar"
tudo. Também, através do Scrum se está sempre planejando junto ao cliente, o que diminui os
riscos de que a equipe não entenda o projeto. Chegando assim no final com algo que não gera
valor e sim desgaste e retrabalho.
 Figura 1 – Visão Geral do Andamento do Projeto com o Scrum.

3.2 PAPÉIS

De acordo com (SCHWABER, 2004), o Scrum é dividido em 3 papéis: Product

Owner, ScrumMaster e o Time. Sendo as responsabilidades divididas da seguinte forma:
Product Owner (PO) – Define as funcionalidades do produto; decide datas de lançamento e
conteúdo; é o responsável pelo controle do Retorno de Investimento (ROI - Return On
Investment) do projeto; é ele quem prioriza funcionalidades de acordo com o valor de negócio
(importância) do requisito; aceita ou rejeita o resultado dos trabalhos desenvolvidos pelo
Time.
Scrum Master – É responsável pelo processo, para treinar os envolvidos no projeto e aplicar
os valores do Scrum. Ele representa a gerência para o projeto, removendo obstáculos e
garantindo a plena funcionalidade e produtividade da equipe. Também, garante a colaboração
entre os diversos papéis e funções.
Time – É a equipe responsável por desenvolver as funcionalidades. Os times para o Scrum
são auto-organizados e multifuncionais. Os membros do time são coletivamente responsáveis
pelo sucesso de cada iteração e do projeto como um todo. É recomendado um Time com no
máximo 9 pessoas.

4 FERRAMENTAS E ARTEFATOS DO SCRUM

4.1 PRODUCT BACKLOG

 É o "coração" processo do Scrum. Trata-se de um documento de alto-nível (que não se
aprofunda nos mínimos detalhes) que contém todas as funcionalidades do projeto através das
"user stories", estimativas "cruas" de prazo e importância de cada (fora outros parâmetros que
podem ser incluídos para uma melhor adaptação à realidade da empresa). Este documento é
de propriedade do Product Owner (ele que descreve as "user stories" e dá a importância de
cada uma), mas deve poder ser visto por todos os membros da equipe (normalmente está
compartilhado em um local da rede interna ou em uma planilha online).
O formato visual do documento trata-se de uma simples planilha, como pode ser visto
na Tabela 1.

Estimativa
ID Título Importância História (Descrição)
Inicial
O usuário deve encontrar no site um formulário que
perguntará se ele já tem cadastro para fazer
Cadastro 8 (story
1 120 compras. Se for cadastrado deve autenticar com seu
de usuário points)
e-mail e senha. Caso contrário deve aparecer um
formulário com os seguintes dados...
2 ... ... ... ...
Tabela 1 – Exemplo de uma Planilha do Product Backlog

ID:
Trata-se de um código numérico seqüencial que serve para ajudar a identificar
unicamente uma "user story".

Título:
Um nome ou frase que descreva claramente de qual "user story" está se falando. O
nome deve estar na linguagem do negócio e não em linguagem e detalhes técnicos.

Estimativa inicial:
Como o nome já diz é uma estimativa inicial de quanto tempo a funcionalidade poderá
levar. Note também que a unidade são "story points" que corresponde a dias de trabalho de
um profissional. Exemplo: Se com três membros (vamos dizer 2 programadores e 1 designer)
sem interrupções, em um bom ambiente uma funcionalidade deverá ficar pronta em 3 dias
então temos 9 story points (3x3 = 9).
 Tal abordagem oferece uma visão de impactos no prazo, mas se trata de uma
estimativa inicial e não deve ser encarada como uma verdade absoluta e, outro fator é que
antes de ocorrer um "sprint" (um período fixo de trabalho da equipe), o tempo de
desenvolvimento necessário para cada funcionalidade incluída se torna mais refinado e com
adição de margens de risco de atraso.

Importância:
O nível de importância recebe números correspondentes ao quanto aquela
funcionalidade é crucial. Isso ajuda quais devem ser feitas logo nas primeiras sprints e a
depender do ambiente na empresa aquelas que têm importância máxima podem se beneficiar
de técnicas como a programação em par que aumenta o foco e reduz bastante a possibilidade
de erros. Também os intervalos normalmente são dados de 10 em 10. Isso facilita a inserção
de outras funcionalidades que são "um pouquinho" mais ou menos importantes. Exemplo:
História A = 120; História B = 119.

História:
É aqui que o Product Owner descreve em alto nível como deve se comportar a
funcionalidade. Quando se diz "alto nível", é que deve estar na linguagem do Product Owner,
ou seja, mais regra de negócio do que um texto técnico para programadores.

4.2 SPRINT BACKLOG

Se o Product Backlog é considerado o "coração" de onde brota o projeto, o Sprint

Backlog é de aonde brotam o movimento e detalhes para se percorrer uma jornada. Trata-se
de uma saída detalhada onde estão as "user stories" do Product Backlog que são escolhidas
para desenvolver-se em uma sprint. As "user stories" escolhidas são quebradas em tarefas e as
durações de cada uma são refinadas. Dentro deste documento também deve estar à meta da
sprint. Exemplo: "Criar o mecanismo de vendas online beta". A criação deste documento tem
a participação de toda a equipe e deve ser guiada pela conversa franca e crítica a fim de que se
chegue ao que realmente é necessário.
O formato visual do documento que ficará visível para todos tanto deve ser em uma
planilha ou documento de texto (que fique compartilhado na rede) como deve também estar
disponível em um mural (task board ou kanban) na forma de "index cards".
4.3 BURN DOWN CHART

Trata-se de um gráfico que demonstra o andamento de uma sprint ao longo do tempo

definido para esta, como pode ser visto na Figura 2.

Figura 2 – Demonstração do gráfico Burn Down Chart

No eixo X temos os dias até o fim da sprint. Exemplo: Os dias úteis desde 01 de
fevereiro até 15 de fevereiro (data quando o resultado da sprint deverá ser demonstrado ao
Product Owner).
No eixo Y temos o quanto falta (seja em % ou story points) para que se completem
todas as funcionalidades separadas para a sprint.
A cada reunião "relâmpago" diária da equipe (daily scrum meeting) o gráfico é
atualizado dando a visão de como está indo o trabalho.

5 REUNIÕES E EVENTOS DO SCRUM

5.1 SPRINT PLANNING

Como o nome sugere, é nesta reunião periódica com todos os membros (equipe,
ScrumMaster e product owner) em que são definidas quais funcionalidades do "product
backlog" vão ser escolhidas para que a equipe desenvolva em uma sprint. Aparentemente é
simples, mas trata-se da reunião mais demorada e crucial em um projeto ágil com Scrum.
Abaixo são descritas as atividades da reunião:
1. Definir a meta da sprint. Por exemplo: "criar a central de ajuda do site". Uma sprint não
deve nunca começar sem uma meta definida em uma linguagem de alto nível.
2. As funcionalidades são escolhidas, divididas, discutidas e priorizadas o quanto for
necessário para que as estimativas de tempo e importâncias se encaixem na sprint.
3. As "histórias" (funcionalidades) são quebradas em tarefas e o tempo para cada uma
estimado. Essa informação sobre as tarefas não necessariamente precisa estar com o Product
Owner, pois detalhes técnicos são de encargo da equipe, deixando o Product Owner
preocupar-se com aquilo que é realmente importante para ele, ou seja, as funcionalidades.
Então, como funciona a reunião? Provavelmente a primeira coisa que vem em mente é
colocar todo o pessoal em volta de uma mesa de reunião com um projetor e alguém com uma
planilha Excel ou qualquer documento de texto. A planilha realmente ajuda, pois realmente a
reunião deverá ser documentada, mas se for somente por este caminho a reunião se tornará
um marasmo de "tédio", pois esta não é, nem de longe, a melhor forma de estimular a
participação de todos da equipe.
Algumas técnicas que ajudam muito a resolver este problema são:

Index Cards:
Trata-se de cartões ou post-its onde se coloca o nome da história (funcionalidade), ou se
necessário mais informações como descrição, estimativa, etc. Durante a reunião de sprint
planning, estes cartões são colocados sobre uma mesa ou quadro branco e ao longo da reunião
são organizandos de acordo com a importância que vai sendo atribuída a cada história pelo
Product Owner. Veja o exemplo na Figura 3 a seguir:

Figura 3: Exemplo de um Index Card

Tal técnica é importante e melhor do que somente o conjunto "mesa+planilha+projetor"

porque estimula às pessoas se levantarem e movimentarem-se. Quando decidido que alguma
funcionalidade é mais importante do que a outra, simplesmente alguém se levanta e muda a
posição. Isso estimula o movimento e que as pessoas circulem mais pela sala criando um
ambiente mais descontraído. Com isso se tem a ordem de importância pela qual a equipe terá
um norte ao desenvolver as funcionalidades da sprint.

Planning Poker:
O que acontece quando se tem uma funcionalidade e durante o "sprint planning" se
pergunta quanto tempo deve levar para que seja desenvolvida? Provavelmente aquele que
sabe, ou acha que sabe, vai responder. Muitas vezes funciona, mas em excesso isso pode ser
altamente prejudicial, pois não existe debate entre a equipe e ficam presos à opinião de uma
só pessoa. E se ela estiver errada ou se, aquela opinião aplique-se somente a ela sem levar em
conta os outros membros da equipe? Para evitar isto, sempre que necessário é utilizado o
"Planning Poker", que funciona da seguinte forma:
1. O ScrumMaster pergunta à equipe quanto tempo ("story points") é necessário para
desenvolver-se uma funcionalidade x.
2. Cada um pensa durante um tempo "quanto dias um profissional precisaria para
desenvolver", escolhe o cartão com o número mais aproximado e quando o tempo acaba
coloca sobre a mesa.
3. Aqueles que colocam o maior e menor número devem explicar porque e com isso busca-se
chegar a um consenso.
4. Existe também uma carta para dúvida e outra para sugerir uma pausa (o desenho de uma
xícara de café).
Esta técnica faz com que todos participem e torna o ambiente mais leve e descontraído.

3 CONCLUSÕES

No método Scrum como em qualquer outro método de gerenciamento, torna-se

importante a aplicação de métricas para medir a produtividade, qualidade, prazo e custo.
Assim a implantação de uma dessas métricas aumenta essas estimativas qualificando o
projeto.
Este artigo apresentou a utilização de estimativas em Scrum utilizando pontos por user
stories para demonstrar como controlar de uma forma visual o projeto de desenvolvimento de
software. Desta forma é possível gerir em termos de custo um projeto ágil sem perder os
conceitos que o Scrum prega, trazendo ganhos de produtividade e melhorando ainda mais os
sistemas e produtos desenvolvidos.

REFERÊNCIAS

AMBLER, S. Modelagem ágil: práticas eficazes para a Programação Extrema e o Processo

Unificado. Porto Alegre: Bookman, 2004.

BECK, K. et al. Agile Manifesto. 2001. Disponível em: <http://www.agilemanifesto.org>. Acesso

em: dez. 2010.

FOWLER, M. et al. The New Methodology. 2001. Disponível em:

<http://www.martinfowler.com/articles/newMethodology.html>. Acesso em: dez 2010.

LEVENFELD, Eduardo. Uma Breve Introdução ao SCRUM. Disponível em

<http://www.gati.inf.br/sitev2/news/view/35>. Acesso em: dez. 2010.

OGUNNAIKE, B.A. & Ray, W. H., et al. Process Dynamics, Modeling and Control. Oxford
University Press, 1ª Edição, 1992

RISING, L. et al. The Scrum Software Development Process. 2007. Disponível em:
<http://members.cox.net/risingl1/articles/IEEEScrum.pdf>. Acesso em: dez 2010.

SCHWABER, Schwaber, Ken. et al. Controlled chaos: living on the edge. 1996. Disponível em:
<http://www.controlchaos.com/old-site/ap.htm>. Acesso em: dez de 2010.

SCHWABER, Schwaber, K. et al. Agile Project Management with Scrum. Microsoft Press. 1ª
Edição, 2004.

SOMMERVILLE, I. Engenharia de software. São Paulo: Addison-Wesley, 2003.

SILVEIRA, A. Carlos. Cone da incerteza e SCRUM. Disponível em:

<http://www.acarlos.com.br/blog/tag/scrum/page/3>. Acesso em: dez 2010.