Processo Comprometer Histórias de Usuário - SBOK SCRUMstudy

Conheça o Processo Aprovar, Estimar e Comprometer Histórias de Usuário no Gerenciamento Ágil de Projetos

Conheça o Processo Aprovar, Estimar e Comprometer Histórias de Usuário no Gerenciamento Ágil de Projetos

Neste artigo, apresentaremos o processo Aprovar, Estimar e Comprometer Histórias de Usuário, da fase Planejar e Estimar do Scrum de acordo com o Scrum Body of Knowledge, da SCRUMstudy. A fase Iniciar é composta por 5 processos. Além da fase Planejar e Estimar, existem ainda outras 4 fases: Iniciar, Implementar, Revisão e Retrospectiva e Release.

Carreiras Site Campus

Propósito do Processo Aprovar, Estimar e Comprometer Histórias de Usuário

Contendo uma lista de épicos em seu backlog, assim como histórias de usuário preliminares, chegando a fase de Planejar e Estimar o Dono do Produto terá a responsabilidade de reunir todo o Time Scrum para finalmente ir ao bit, determinar as histórias de usuário para as próximas iterações e garantir que o time de desenvolvimento se comprometa com elas. Veremos neste processo técnicas interessantes de estimativa de histórias de usuário, contudo, mais do que estimar estas histórias é importante garantir o comprometimento do time para com a Sprint seguinte – ao menos.

Este processo nos remete muito ao processo de conduzir o planejamento das entregas, ou releases, porque é a partir dele que poderemos validar estas entregas. Se o time decidir que não pode se comprometer como determinadas histórias, isso afetará o planejamento geral das entregas, que precisará ser feito. Importante aqui manter os olhos e a mente aberta para atualizações no backlog do produto, a partir da estimativa das histórias do usuário, que deverão ser refletidas nos demais artefatos de gerenciamento ágil de projetosplano da release, backlog do produto, histórias de usuário e épicos.

Conheça o Processo Aprovar, Estimar e Comprometer Histórias de Usuário no Gerenciamento Ágil de Projetos

Entradas

Time Central do Scrum*

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Entrada obrigatória neste processo!

Histórias de Usuário*

Já descrito no artigo sobre o processo Criar Histórias de Usuário, clique aqui para conferir.

Entrada obrigatória neste processo!

Critérios de Aceitação das Histórias de Usuário*

Já descrito no artigo sobre o processo Criar Histórias de Usuário, clique aqui para conferir.

Entrada obrigatória neste processo!

Recomendações do Scrum Guidance Body

Já descrito no artigo sobre o processo Criar a Visão do Projeto, clique aqui para conferir.

Ferramentas

Reuniões de Grupos de Usuários*

Ferramenta obrigatória neste processo!

Planejamento Poker

Mais fácil do que escrever, é mostrar: https://www.youtube.com/watch?v=yHeJSlm7qtY – confira o vídeo deste profissional, Rômulo Fabrício, muito bem elaborado. Assista abaixo, também.

Em resumo, o planejamento poker é simples: cada participante de uma reunião ganha um baralho numerado – cada número é uma estimativa – e então o mediador apresenta as histórias de usuário e cada participante escolhe uma carta que represente sua estimativa para aquela história. Se houver divergências, todos devem falar sobre suas justificativas para cada estimativa. Quando o consenso for alcançado, então é estabelecida a estimativa para cada história. Se as estimativas forem, na primeira rodada, iguais, então passa-se para a próxima história sem a necessidade de apresentação de justificativas.

Geralmente, cada ponto apresentado nas cartas está vinculado a um parâmetro de trabalho – os pontos das cartas PODEM ser horas de trabalho, mas não necessariamente. Confira o vídeo acima! Abaixo, verifique um baralho padrão de planejamento poker:

pokerplanning

Fist of Five

Para tomada de decisões em grupo, é possível utilizar o Fist of Five. Basicamente, é apresentada uma decisão para o grupo. Cada membro do grupo, em reunião, apresenta um dos dedos de uma de suas mãos ou todos os dedos da sua mão. Confira o que cada dedo representa (ou o punho todo):

1. Um dedo: Eu não concordo com a conclusão do grupo e tenho dúvidas.

2. Dois dedos: Eu não concordo com a conclusão do grupo e gostaria de discutir alguns problemas menores.

3. Três dedos: Eu não tenho certeza e gostaria de apoiar a conclusão de consenso do grupo.

4. Quatro dedos: Eu concordo com a conclusão do grupo e gostaria de discutir alguns problemas menores.

5. Cinco dedos: Eu concordo plenamente com a conclusão do grupo

Assim, em rodadas sucessivas, o grupo segue debatendo sobre conclusões e histórias de usuário. É possível combinar o planejamento poker com o Fist of Five para que em caso de divergência os participantes possam se posicionar desta forma simples.

Pontos de Estimativa de Custo

É uma estimativa paramétrica que pode ser empregada para determinar o custo de uma história de usuário a partir de um parâmetro fixo estabelecido antes de cada Sprint durante a estimativa e comprometimento de cada história de usuário. É possível determinar parâmetros de custo de implementação baseado em horas, remuneração e ainda outros parâmetros. O grupo pode definir tais parâmetros e combiná-los com outros, assim como o planejamento poker e seus pontos por carta. Consideramos como ponto de estimativa de custo também o tamanho relativo de cada história de usuário. O grupo pode determinar um parâmetro para cada ponto de história, como no planejamento poker, com base em riscos e esforço relativo para a implementação geral de histórias de usuário.

Outras Técnicas de Estimativa

  • Delphi
    • A Wideband Delphi é uma técnica de estimativa baseada pelo grupo, para determinar a quantidade de trabalho que está envolvido, e quanto tempo vai demorar para esse trabalho ser concluído. Os indivíduos dentro de um time anonimamente fornecem estimativas para cada recurso, e essas estimativas iniciais são então adicionadas em um gráfico. O time então, discute os fatores que influenciaram em suas estimativas e procedem para uma segunda rodada de estimativas. Este processo é repetido até que as estimativas dos indivíduos sejam similares e que um consenso possa ser alcançado para uma estimativa final.
  • Estimativa de Afinidade
    • É possível definir o tamanho relativo de épicos e histórias de usuário mais facilmente “estimáveis” e, posteriormente, agrupar histórias de usuários a estas inicialmente estimadas de acordo com sua afinidade. Também, por analogia, é possível criar outras estimativas para as histórias afins.
  • Estimativa de Intervalo
    • As estimativas para os projetos devem ser apresentadas em intervalos. Números exatos podem dar a impressão de serem altamente precisos, quando na verdade podem não ser. De fato, as estimativas, por definição, são entendidas como não sendo exatamente precisas. A Estimativa de Intervalo deve ser baseada no nível de confiança que o time tem em cada estimativa. O intervalo pode ser estreito quando o time está confiante, e amplo, quando o time não está tão confidente

Expertise do Scrum Guidance Body

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir

Saídas

Histórias de Usuário Aprovadas, Estimadas e Comprometidas*

Vamos simplificar: as estimativas para as histórias de usuário do backlog estão prontas? Está na hora de o time se comprometer com as histórias para a Sprint seguinte ou até mesmo para um conjunto de Sprints. Sabendo o trabalho estimado para as histórias e os épicos, é possível distribuir este trabalho em Sprints. O time deve então se comprometer com aquelas histórias. Em cada Sprint executada e revisada é possível que este comprometimento mude: mais ou menos histórias. Contudo, uma vez feito o comprometimento inicial é preciso ainda considerar este durante o planejamento de cada Sprint – que veremos ainda nesta fase, a fase de Planejar e Estimar.

Saída obrigatória neste processo!

Deixe seus comentários!

#
Compartilhe!
Fale com o Site Campus!

Tags: , , , , ,