InfoQ

InfoQ

Notícias

Meus Favoritos

Faça oLogin ou Cadastre-se para ativar o recurso de favoritos por tempo ilimitado.

O conteúdo foi adicionado aos favoritos!

Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.

O que são os "Story Points"? Eles são necessários?

Postado por Mark Levison , traduzido por Felipe Torres em 08 Mar 2010

Seções
Processos e Práticas
Tópicos
Agile ,
Técnicas Ágeis
Tags
Planejamento

Michael de la Maza se perguntou sobre o que exatamente é um Story Point. Ele estava procurando por uma resposta e encontrou muitas: "Story Points representam unidades de tempo obscuras." ou "Story Point é uma unidade relativa de medida usada por times Scrum. Isso e usado para mensurar a quantidade de esforço necessário para implementar uma história." ou "...um story point é uma junção da quantidade de esforço envolvido no desenvolvimento de uma feature, a complexidade desse desenvolvimento, o riso contido nele, e por aí vai." [Mike Cohn, Agile Estimation and Planning].

Michael passa a documentar como eles são utilizados: "Verdade seja dita, velocidade é realmente uma forma de medir a produtividade..." contra "O uso de story points ou ideal days para medir a produtividade é uma má idéia, pois isso levará gradualmente o time a inflar o significado de um ponto..."

Com toda essa confusão, Michael quer saber o que são Story Points. Como introduzir isso para pessoas iniciantes em Agile e Scrum?

Dan Rawsthorne, responde: 

  1. Um time usualmente QUER velocidade para ser uma métrica de produtividade ao invés de ficar falando para o mundo externo sobre o quão rápido ele é.
  2. Velocidade somente é uma forma de medir se os Story Points permancem constantes durante a vida do projeto. Para isso, o time deve usar uma ou duas histórias que não se alteram durante a duração do projeto.
  3. Se "a história não somente é coerente dentro de um time, mas entre times, então a velocidade não medirá a produtividade, mas também pode ser um fator de comparação entre eles e isso só tem a acrescentar dentro de uma organização" entretanto este repórter argumenta fortemente contra esta prática: "Desvio de velocidade em projetos ágeis ".
  4. Uma vez que os times tem Story Points estáveis, então eles podem ser usados em sessões futuras de planejamento para se obter uma melhor estimativa sobre quanto trabalho será possível concluir com sucesso.

Ron Jeffries replica: "Story Points são uma forma relativa de medir o tempo necessário para se implementar uma história (termo emprestado do XP, bem como sua definição). Destinam-se a ser uma forma de estimar a dificuldade sem se comprometer com uma duração de tempo específico, de modo que as variações no tamanho da equipe ou tempo na tarefa não afete isso" e "Sim, eles medem o tamanho e complexidade. Os termos 'tamanho' e 'complexidade' são usados com o significado de 'quão difícil é em termos de quanto tempo será usado para fazermos'.". Finalmente, Ron nota que ele (e outros experts) não veem necessidade nos Story Points.

Veja também esse artigo sobre Story Points vs Horas na InfoQ.com (em inglês).

E você leitor, qual a importância dos Story Points para o seu time?

 

Pois é por Luis Junior Enviado
  1. Voltar ao topo

    Pois é

    por Luis Junior

    Meu time usa SP e estamos bem encaixados nisso, ou seja, isso é útil e nós conseguirmos seguir o mesmo numero de SP em todas as sprints. Com isso posso concluir que:
    - Não entendo SP, mas funciona
    - Não acho que é uma medida clara, mas funciona
    - Eu não consigo convencer as pessoas de como isso funciona, mas funciona
    - Isso funciona pq usamos, mas não sei como funciona

    Complexo... não entendo, mas o time se dá bem com isso, mas não parece muito lógico.

    Uma vez vi um comentários, crio que era do pai do Scrum: Uma tarefa é feita no tempo que tem disponível, sempre!

    Se pensarmos nisso, SP não funciona exatamente, simplesmente o time termina as tasks/estórias pq tem 2 semanas para entregar.


    Eu ainda vou dominar este assunto =)
    []s
    LCG

Conteúdo Educacional

Formando equipes de alto desempenho, parte 1: Início e fases de evolução

Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.

Business Model Canvas, passo a passo

O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.

Google Apps Script, Parte 2: Google Docs, triggers e envio de emails

Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.

Serviços de cloud computing PaaS: um guia para desenvolvedores Java

Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.

Canvas de Modelo de Negócios: uma contribuição para o sucesso de Startups

O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.

Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.

Entrevista com Rebecca Parsons Parte 1: Agile nas Empresas e Arquitetura Evolucionária

Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.