Estimar quanto tempo os desenvolvedores completarão os recursos de um produto é um jogo difícil. Sem mencionar que estimativas erradas podem se traduzir em uma carga de trabalho avassaladora e até mesmo em falhas de projeto posteriores. Portanto, a preocupação primordial entre os membros da equipe ágil é descobrir uma maneira de fazer uma linha do tempo realista. É quando algumas técnicas de estimativa com maior precisão entram em jogo. Um deles são os pontos da história. Neste artigo, o Designveloper fornecerá uma compreensão mais profunda dos pontos da história no ágil e como aplicá-los para estimativas eficazes.
O que são pontos de história em metodologias ágeis? #
Esta terminologia é desenvolvida com base na frase “user stories” emmetodologia ágil. Consequentemente, uma história, conhecida como item do backlog do produto, é uma explicação concisa da funcionalidade de uma entrega do ponto de vista do usuário final. Por exemplo, abaixo está normalmente o que um cliente deseja de um aplicativo de comércio eletrônico:
“Prefiro receber notificações sobre descontos personalizados com base no meu histórico de compras.”
Com base nessa história de usuário, os desenvolvedores planejam criar notificações por push no aplicativo. Para estimar o esforço geral necessário para realizar o trabalho, eles podem atribuir valores relativos de um a dez ou mesmo de 1.000 a 5.000. O intervalo de valores que você usa não é tão importante quanto a forma como você avalia a dificuldade de uma história de usuário. Em uma escala de 10 pontos, por exemplo, as tarefas que recebem um são mais fáceis, enquanto aquelas com seis se mostram muito mais exigentes.
Por que sua equipe deve usar pontos de história no desenvolvimento ágil? #
Tempo (por exemplo, horas, dias ou meses) é uma abordagem de estimativa tradicional emdesenvolvimento de software. No entanto, mostra-se um pouco antiquado e ineficaz porque eventos como entrevistas ou reuniões diárias levam a atrasos em seu trabalho. Isso dificilmente garante a entrega pontual de recursos de um produto que os membros da equipe se comprometeram a concluir em um período predeterminado.
Sem mencionar que as estimativas baseadas no tempo possivelmente vêm de opiniões subjetivas e emocionais. Isso significa que os membros da equipe podem superestimar sua quantidade de trabalho ou planejar demais os itens do backlog do produto.
Várias equipes ágeis voltam seu foco para os pontos da história. Essa técnica de medição os ajuda a resolver os problemas acima. Para o proprietário do produto, os valores do ponto de história o ajudam a entender melhor as incertezas técnicas relativas aos preços superdimensionados do trabalho. Além disso, o proprietário pode avaliar o ROI de uma história de usuário e prever melhor o tempo de lançamento no mercado.
Enquanto isso, os pontos da história ajudam as equipes de desenvolvimento a fazer uma estimativa razoável dos itens do backlog do produto que são capazes de desenvolver. Assim, eles podem construir uma estratégia de execução confiável, elaborar um plano adequado e trabalhar de forma sustentável para implementar esses itens em uma iteração.
Como calcular pontos de história no Agile? #
As equipes ágeis usam maneiras diferentes de identificar valores abstratos de pontos da história. Designveloper sugere vários sistemas de pontos comuns como segue:
- A Sequência de Fibonacci: Cada número é uma soma de dois dígitos anteriores – 1, 3, 5, 8, 13, 21, 33.
- A Sequência Linear: O padrão numérico padrão – 1, 2, 3, 4, 5, 6, 7, 8.
- A Sequência de Duplicação: Cada número é o resultado de um dígito anterior – 1, 2, 4, 8, 16, 32, 64
- T-Sizing: Este método usa tamanhos de camisetas como XS, S, M, L, XL e 2XL.
Quaisquer que sejam os métodos aplicados, a questão mais importante é como os membros da equipe podem basear a dificuldade de cada item nesses valores.
Portanto, para estimá-los com a maior precisão possível, todos os membros devem considerar variáveis externas como carga de trabalho, complexidade ou riscos. Além disso, os valores dos pontos de história devem ser baseados em fatores internos, como suas habilidades ou recursos disponíveis. As perguntas a seguir darão a eles uma visão mais clara de como essas variáveis afetam suas estimativas:
- Quão complexo é um recurso? Ou Quão difícil é construir um item?
- Quais são os riscos potenciais? (por exemplo, demandas ambíguas, dependência de terceiros ou partes incertas de um projeto)
- O trabalho é repetitivo? Ou Quão familiarizados os desenvolvedores se sentem com um item?
- Quanto trabalho é necessário para concluir um recurso?
- Qual a capacidade técnica da equipe?
- Quão disponíveis estão os recursos para desenvolver um item? (por exemplo, humano, financeiro ou ferramentas)
Durante o processo de estimativa, os membros da equipe não devem atribuir valores a pequenos trabalhos que podem ser implementados em um cronograma específico. Além disso, eles devem evitar que um fator impacte todo o processo de estimativa porque os pontos da história são decididos por vários fatores.
Um processo típico de estimativa de pontos de história #
Caso você se pergunte quando ocorre a estimativa do ponto da história, a resposta é durante a preparação do backlog do produto. Em particular, os membros da equipe conduzem esta sessão no início de uma iteração para revisar se os itens do backlog foram claramente refinados.
Estimar os pontos da história é o principal trabalho daqueles que se envolvem diretamente no trabalho de desenvolvimento. Mas o proprietário do produto, um líder de equipe/scrum master e outras partes interessadas podem participar do processo para evitar mal-entendidos inesperados.
Leitura recomendada: O que é SCRUM e como funciona?
Abaixo está como uma sessão de estimativa típica ocorre:
- Um líder de equipe/scrum master realiza a reunião de refinamento do backlog do produto. Ele/Ela assume a responsabilidade de monitorar a sessão e preparar o gráfico de burndown para um projeto.
- O proprietário do produto informa os itens do backlog do produto (PBIs) para estimativa. Os membros da equipe então fazem perguntas e examinam possíveis suposições ou incertezas.
- Os membros da equipe constroem uma matriz de estimativa para os pontos da história. Eles então extraem a calibração do PBI para identificar o que causa incertezas, complexidade e repetitividade mínimas.
- Cada membro compara o tamanho de um item com a calibração predefinida. Os membros usam cartões do Planning Poker que exibem os números disponíveis para mostrar suas estimativas.
- O proprietário do produto pode perguntar por que os membros de desenvolvimento escolhem números específicos. Se o proprietário e o líder da equipe reconhecerem estimativas incomuns, eles podem reexplicar os PBIs e discutir e resolver problemas. Depois que os membros entenderem os problemas e removerem mal-entendidos, eles podem modificar essas estimativas.
- As etapas acima serão repetidas até que todos os membros concordem com os resultados finais.
As 3 dicas para fazer uma estimativa de pontos de história de forma eficaz #
Fazer as estimativas corretas também contribui para o sucesso da construção de recursos de alta qualidade. Mas nem todos os membros se destacam neste trabalho. Portanto, abaixo estão algumas dicas críticas para ajudar a estimar os pontos da história de forma eficaz:
1. Considere a estimativa ágil como um trabalho em equipe #
Apenas as equipes de desenvolvimento estimam os pontos da história no ágil porque são as únicas pessoas que mais entendem a implementação do trabalho.
Enquanto isso, o proprietário do produto é responsável por receber os requisitos dos clientes, construir o backlog do produto e explicar os itens nele contidos. O proprietário nem sempre sabe exatamente como a obra é executada. Mas isso não significa que o proprietário deva ficar de fora do processo de estimativa.
Admite-se que a estimativa ágil não é um jogo de uma pessoa, mas um trabalho em equipe. Por que é que? Na realidade, os membros da equipe não compreendem os requisitos de entrada do negócio, consequentemente superestimando ou subestimando os itens do backlog. É quando o proprietário e o líder da equipe intervêm para esclarecer as expectativas de negócios e explorar e discutir assuntos. Enquanto isso, o próprio proprietário do produto pode ter conhecimento sobre a complexidade do PBI e a execução do trabalho. Ele então fará uma lista razoável de itens mais refinados.
2. Faça uma estimativa inteligente, não difícil #
Um erro durante o processo de estimativa é que alguns membros da equipe estão se esforçando para estimar os pontos da história. Isso parece impossível porque os requisitos podem ser alterados e as estimativas anteriores podem se mostrar incorretas posteriormente.
Supondo que o trabalho mais duro de um membro nunca chegue ao valor estimado de mais de 20, por exemplo. Eles acharão difícil fornecer números exatos para um trabalho maior do que isso.
Portanto, ao estimar os pontos da história, as equipes de desenvolvimento devem fornecer ao proprietário do produto números aproximados. Ao mesmo tempo, esses números devem ser úteis na construção de um roteiro de produto adequado.
3. Aprenda com a experiência passada #
Noretrospectiva do sprint, todos os membros da equipe irão refletir sobre o que foi feito e como fazer melhorias. Mas o Designveloper aconselha você a olhar para as estimativas anteriores também. Isso ajuda a determinar se essas estimativas são precisas e se os PBIs devem ser divididos em incrementos menores para atender à sua equipe.
Conclusão #
Estimar pontos de história em ágil pode estar entre as partes mais difíceis do seu trabalho. No entanto, também requer prática regular para aperfeiçoar. Além disso, equipes ágeis, digamos,desenvolvedor de designtambém cria um ambiente harmonioso e colaborativo para que os membros da equipe forneçam suas estimativas de trabalho de forma construtiva.
FAQs
O que são pontos de História Scrum? ›
O que são pontos de história? Pontos de história são uma medida comumente usada para estimar o tamanho de uma pendência em equipes Scrum. Durante uma sessão de planejamento típica, uma solução de bug trivial pode ser estimada como 1 ou 2 pontos de história, e um recurso maior pode chegar a 12.
O que são pontos de história? ›Os pontos da história são unidades de medida para expressar uma estimativa do esforço geral necessário para implementar por inteiro um backlog do produto ou qualquer outro trabalho. Equipes atribuem pontos de história em relação à complexidade de trabalho, à quantidade de trabalho e ao risco ou à incerteza.
Como calcular a quantidade de story points? ›Como medir story points: sequência de Fibonacci
Os desenvolvedores usam uma sequência de Fibonacci (0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) como métrica para mensurar story points e forçar as equipes a chegar a decisões claras.
Estimamos, com story points, que a primeira é 1 ponto, a segunda são 2 pontos. E, simplificando bastante, imagine que cada ponto signifique uma mudança de parâmetro.
Como estimar pontos Scrum? ›Em frameworks como o Scrum e o Kanban, as equipes devem estimar o tamanho que é igual a quantidade de trabalho aos quais a equipe se comprometeu a fazer. Somando o tamanho de cada cartão concluído ao final de cada Sprint, o resultado será a estimativa de velocidade, frisa Kniberg (2009).
O que são e para que servem os Story points? ›Um Story Point é a estimativa relativa do tamanho da atividade comparado com outra atividade no projeto. Story Point é, provavelmente, a unidade de estimativa mais utilizada entre os times ágeis hoje. O nome é derivado dos times ágeis, que normalmente expressam os requisitos como User Story (Estória do Usuário).
Quantos pontos História? ›O curso de História apresenta nota de corte média de 610.63 pontos para ingresso pelo Sisu 2022, Considerando a menor nota de corte de 389.01 pontos e a maior nota de corte de 721.28 pontos.
Por que usar Story points? ›Logo, os Story Points possuem essa finalidade de medir a complexidade de algo dentro do time ou das tarefas que você e sua equipe realizam.
Qual o papel da equipe de qualidade em um projeto ágil? ›A equipe de QA desempenha papel fundamental, oferecendo apoio e suporte aos desenvolvedores, em algumas etapas, e executando testes, criando cenários e buscando soluções, em outras.
Como transformar Story points em horas? ›Pontos e horas não combinam: Story Points e horas não são compatíveis. Se um time decide usar pontos, deve esquecer horas. Não há um “de-para”. Aqui vale o empirismo iteração a iteração para calibrar os pontos em user stories de complexidades distintas.
Qual a porcentagem de entrega dos Stories? ›
Ou seja, em média, 2,5% dos seus seguidores irão ver sua história e esse é um número muito relevante!
Como avaliar o engajamento dos Stories? ›Deslize para cima na imagem ou no vídeo do story. Você também poderá ver a quantidade de respostas e o número de vezes que o story foi compartilhado, além de outras métricas de interação e engajamento com a publicação, como Contas alcançadas.
Quanto devo cobrar por 3 Stories? ›Sequência de Fibonacci, nada mais é do que a partir dos dois primeiros números 0 e 1 os seguintes serão obtidos pela soma dos antecessores.: 0, 1, 1, 2, 3, 5, 8, 13 , 21, 34 e etc…. Dessa sequência, ao se dividir qualquer número pelo anterior o resultado é um “número irracional algébrico” conhecido como número de ouro.
Como usar Planning Poker? ›- o Product Owner seleciona um item do Product Backlog para ser estimado e lê o item para toda a equipe, explicando da forma mais clara possível.
- os membros da Equipe de Desenvolvimento discutem o item e o Product Owner fica disponível para esclarecer quaisquer dúvidas que possam surgir.
Os pilares do Scrum são três: transparência, inspeção e adaptação.
Quem estima o trabalho do Scrum? ›Nesse evento, a equipe estima o trabalho a ser concluído no próximo Sprint. Os membros definem metas de Sprint que sejam específicas, mensuráveis e atingíveis. Ao final da reunião de planejamento, cada membro Scrum sabe como cada incremento pode ser apresentado no Sprint.
Quem criou Story points? ›Seguindo esse processo de mudança, a estratégia de adotar story points foi definida e nomeada inicialmente por James Grenning, em 2002, e se popularizou no campo dos projetos com o livro Agile Estimating and Planning, de Mike Cohn, um dos colaboradores do desenvolvimento de software Scrum.
Qual a diferença entre uma Sprint Review é uma retrospectiva? ›Enquanto a Revisão da Sprint busca avaliar o produto do trabalho do Time de Desenvolvimento, a Retrospectiva da Sprint (Sprint Retrospective) é uma oportunidade para que a equipe avalie a si mesma, refletindo sobre suas práticas e desenhando melhorias para aplicar na próxima Sprint.
O que é DoR e DoD? ›Talvez você já tenha ouvido falar também sobre Definition of Done (DoD). DoR e DoD tem objetivos diferentes, DoD são os critérios para considerar uma história como concluída. Já DoR, como eu já descrevi, são os critérios necessários para que uma história possa ser iniciada.
Quem participa do Planning Poker? ›
Qualquer equipe que esteja planejando construir algum caminho pode utilizar o Planning Poker como base. Isso porque a técnica é extremamente simples e que gera um grande engajamento entre os participantes. Além disso, também é possível alcançar vários indicadores úteis para o time.
Quantos pontos se leva? ›Nem todos os motoristas, no entanto, têm o direito de acumular 40 pontos na CNH. Poderão chegar à pontuação máxima de 40 pontos somente os condutores que não cometeram infrações gravíssimas. Se o motorista tiver uma infração gravíssima, a pontuação limite cai para 30 pontos.
Quantas questões de história? ›Ciências Humanas e suas Tecnologias
Sociologia 2 a 3 questões; História: 10 a 15 questões; Geografia: 9 a 11 questões.
A nova regra de trânsito, que prevê um limite de até 40 pontos na CNH, já está valendo em 2022. O documento do Código de Trânsito Brasileiro (CTB) foi criado em 1997, mas, em outubro de 2020, a publicação da Lei nº 14.071/2020 modificou algumas regras.
Porque meu Story tem um ponto de exclamação? ›O ponto de exclamação vermelho ao lado de sua mensagem significa que ela não foi enviada devido a uma má ligação com a Internet ou a um problema no servidor. Recomendamos tentar enviá-lo novamente mais tarde. Leve em conta que isso é um problema no envio da mensagem e não significa que o usuário tenha bloqueado você.
Por que fazer Stories criativos? ›1. Faça enquetes depois de contar uma história. Um dos objetivos de utilizar os stories criativos a seu favor é aumentar o engajamento com seu público. Além disso, o recurso gera uma melhor percepção junto ao algoritmo do Instagram, aumentando o seu alcance orgânico.
Quais são as três principais características de uma organização ágil? ›Rede de equipes capacitadas; Decisões rápidas e ciclos de aprendizagem; Líderes ágeis que estimulam colaboradores a assumirem protagonismo; Tecnologia integrada e essencial para todos os aspectos da organização.
Qual é o principal objetivo de uma liderança ágil? ›O principal objetivo desse modelo de gestão é formar líderes capazes de desenvolver a autonomia e as habilidades dos seus liderados. Aplicar a metodologia ágil é deixar de apenas comandar para influenciar os demais a evoluírem profissionalmente.
Quais as principais características da gestão ágil de projetos? ›Gestão ágil de projetos é um modelo de gestão que utiliza metodologias ágeis. Essas metodologias priorizam a capacidade de adaptação e planejamento progressivo do projeto, diferente de metodologias tradicionais, que requerem um planejamento inicial rígido e poucas mudanças ao longo do projeto.
Como fazer o Story ficar mais de 24 horas? ›Abra o aplicativo e clique na história desejada; 2. Ao visualizar a postagem que deseja que apareça por mais tempo, mantenha o dedo na tela. A história fica “paralisada” até que você solte a tela.
Como deixar Story mais de 24 horas? ›
Basta deslizar quando você estiver no Stories para acessar as fotos tiradas nas últimas 24 horas ou antes. Você também pode acessar suas fotos através do ícone da galeria. Encontre a foto que deseja postar, toque, edite da forma que preferir e depois adicione a sua história.
Porque o Story some antes de 24 horas? ›Um bug faz Stories do Instagram "sumirem" antes de completarem 24 horas após a publicação, alegam usuários pelas redes sociais. O problema parece afetar publicações de forma aleatória e não faz o post desaparecer de vez para todo mundo.
Quantas visualizações no Story é bom? ›De 1 a 7 stories/dia é o ideal
Se você quer um número concreto, o recomendado é que seja de um a sete – quando a taxa de conclusão (número de pessoas que viram todos eles) está em 70%. Mas veja bem: isso não quer dizer que 7 seja o limite! Tudo vai depender da sua estratégia e de quanto conteúdo quer entregar.
Não é possível ver quem visualizou os Stories de outras pessoas sem estar usando a conta delas.
Quantos Stories devo fazer por dia? ›Quantos stories publicar por dia? Segundo pesquisa, a publicação diária de até, no máximo, cinco stories garante uma taxa de retenção superior a 70%. Além disso, o estudo revelou que, em 2021, o número de… Lagi stories compartilhados por perfis maiores no Instagram foi superior ao de contas menores.
Como medir o engajamento? ›Taxa de engajamento (real)
São as fórmulas que levam em consideração o alcance do post. Então, ao calcular a sua taxa de engajamento real, faça a conta do número de interações divido pelo alcance, e não pelo número de seguidores. Interações (reações + compartilhamentos + comentários + cliques) / Alcance.
Ou seja: o quanto as pessoas estão interessadas nele. E é por isso que esse dado acaba sendo importante: o algoritmo percebe a relevância dos seus stories e começa a entregar para mais pessoas.
O que são contas com engajamento nos Stories? ›O que é engajamento? De maneira simplificada, podemos explicar o engajamento como a interação do seu público com o conteúdo nas diversas redes sociais. No Instagram, é representado pelas curtidas e comentários feitos nos posts, o compartilhamento de postagens, ao salvar um item na coleção, entre outras ações.
Como utilizar Story points? ›Um Story Point é a estimativa relativa do tamanho da atividade comparado com outra atividade no projeto. Story Point é, provavelmente, a unidade de estimativa mais utilizada entre os times ágeis hoje. O nome é derivado dos times ágeis, que normalmente expressam os requisitos como User Story (Estória do Usuário).
Qual métrica é usada para estimar com o Planning Poker? ›Qual métrica é usada para estimar com o Planning Poker? A métrica utilizada para estimar tarefas através do Planning Poker é a sequência de Fibonacci.
Porque não usar Story points? ›
Os Story Points, por fim, são unidades de medidas alternativas a mensuração por hora - que normalmente são utilizadas pelas empresas tradicionais - e convenhamos que é uma mensuração muito errática, pois é complicado para os times definirem as complexidades dos itens através de horas gastas em cada demanda.
Quais são os 3 pilares do Scrum explique cada um deles? ›Os pilares do Scrum são três: transparência, inspeção e adaptação.
Como quebrar uma história em tarefas Scrum? ›Analisar local e modelo de mesa que seja compartivel com o pedido do cliente. Executar a obra para que a mesa fique escondida. Pedir que o cliente faça testes para verificar se esta tudo Ok ou se será necessario alguma alteração/melhoria.
Quais são as três partes de uma história de usuário? ›Em 2001, Ron Jeffries, escreveu um artigo onde descreveu os três aspectos das histórias de usuários: cartão, conversa e confirmação. Esse conceito ficou conhecido como 3Cs.
Como fazer uma boa história de usuário? ›Como a User Story representa a necessidade do usuário, uma dica para escrever uma boa User Story é estabelecer três parâmetros: Ator: é o proprietário da User Story, quem irá utilizar a funcionalidade ou requisito. Uma imagem mental desse ator ajuda a representar um grupo distinto de usuários do produto.
Como se faz uma história? ›- Pesquise antes de escrever livro. ...
- Crie métodos para planejar o enredo do seu livro (ou só deixe rolar, mas com disciplina). ...
- Aprenda como desenvolver personagens. ...
- Escreva diálogos realistas. ...
- Foque em como cativar os leitores. ...
- Reduza seu texto ao necessário.
- Não legendar os vídeos. Com a correria do dia a dia a maioria das pessoas não tem tempo para parar e assistir um por um dos seus stories. ...
- Não usar as ferramentas interativas. ...
- Não respeitar as margens. ...
- Não postar em diferentes horários.
- Tornar as pessoas sensacionais. ...
- Experimentar e aprender rapidamente. ...
- Entregar valor a todo momento. ...
- Considerar a segurança como um pré-requisito.
- Foco.
- Abertura.
- Coragem.
- Comprometimento.
- Respeito.
- decisões com base empírica;
- autogerenciamento;
- colaboração;
- prioriza a entrega de valor;
- time-boxing;
- processo iterativo.
Qual a granularidade da User Story? ›
Granularidade: Temas, Épicos, Features, Estórias, Tarefas)
O que é um épico Agile? ›Resumo: um epic ágil é uma quantidade de trabalho que pode ser dividida em tarefas específicas (chamadas de histórias do usuário) com base nas necessidades/solicitações dos clientes ou usuários finais. Os epics são uma prática importante para equipes ágeis e de DevOps.