Melhorar a qualidade história do usuário [fechado]

Question

Nós utilizamos Scrum. Estamos enfrentando problemas durante sprints quando encontramos as histórias de usuários não são suficientemente granular para capturar o esforço necessário para completar o sprint.

Em particular, descobrimos que são fornecidos com wireframes UI que contêm muito mais complexidade do que as histórias originais teria implicado (por exemplo funcionalidade duplicada por razões de usabilidade). Isso leva ao gráfico de burndown olhando como tudo é concluído no último dia do sprint.

Nós passar a segunda-feira no início de cada 2 semanas de sprint passando por cima das histórias como criado pela equipe do projeto, durante o qual nós normalmente refinar as histórias um pouco e dividi-los em tarefas, estimar as horas para cada um criar o gráfico de extermínio. Durante o dia de hoje não sentimos que temos tempo para significativamente melhorar a qualidade das histórias.

A melhor forma de quebrar o ciclo de incompleta / histórias insuficientes para nossos sprints?

Esta é uma falha da equipe do projeto para pregar para baixo as histórias suficientemente no início, ou devemos (ou seja, a equipe de desenvolvimento) tirar um pouco da responsabilidade?

Answer 1

Então você está dizendo que:

1. Os clientes / usuários conversar com equipe do projeto
2. equipe do Projeto escreve histórias e cria wireframes
3. desenvolvimento da equipe divide histórias em tarefas e estimativas

Existe a possibilidade da equipe de desenvolvimento realmente conversando com os clientes / usuários? histórias de usuários são muitas vezes visto como uma maneira de começar uma conversa, em oposição à exigência de documentos / especificações.

EDIT: Alguns links:

• a história de usuário é um caso de uso como uma gazela é um gazebo
• Seis Características de uma boa história de usuário - INVEST Modelo
• o cliente tem sempre Disponível

EDIT: Martin Fowler fez um post de ontem sobre ConversationalStories que cobre esta muito melhor do que eu fiz.

Answer 2

Você está executando retrospectivas de sprint? No final da retrospectiva você deve ter itens acionáveis ??alta prioridade para melhorar o que aconteceu no sprint anterior. As mesmas coisas não deveria estar acontecendo de errado repetidamente .

é seu proprietário do produto acessível durante um sprint? Se não, você pode precisar adicionar extra para qualquer estimativa de como o detalhe de uma história de usuário está incompleta.

sugestão @Pascal dedicar 5% do seu sprint para preparação product backlog é uma boa. Isso deve permitir que as histórias de usuários para estar em um lugar mais detalhado antes do início do seu sprint.

Nós passar a segunda-feira no início de cada 2 semanas de sprint passando por cima da histórias como criados pelo projecto equipe, durante os quais nós normalmente refinar as histórias um pouco e pausa -los em tarefas, estimar o horas para cada um para criar o burndown gráfico. Durante o dia de hoje ele não se sente como nós temos tempo para significativamente melhorar a qualidade das histórias.

Parece que esta é a sua sessão de planejamento do sprint, você tem controle sobre o que as histórias de usuário que você está comprometendo a completar durante o sprint? Como você pode cometer Se você não tem detalhes suficientes?

Isso leva você de volta para ter uma boa retrospectiva e resolver as questões levantadas.

A melhor forma de quebrar o ciclo de histórias incompletas / insuficientes para nossos sprints?

Retrospectivas, o planejamento, a carteira de grooming.

É este o fracasso de um da equipe do projeto pregar para baixo as histórias suficientemente no início, ou devemos (ou seja, o dev team) tirar um pouco da responsabilidade?

É a responsabilidade da equipe como um todo. Encontrar is not culpa vai dar valor, mas todos assumir a responsabilidade dará todos a chance de completar o projeto com sucesso.

Talvez, durante as sessões de planejamento da manhã de segunda-feira você pode envolver quem está escrevendo o usuário histórias / wireframes e trabalhar juntos para descobrir o que detalhe está faltando a partir deles, o detalhe faria suas estimativas mais fácil e precisa. Talvez um modelo do que deve incluir poderia ser elaborado.

Answer 3

Nós tivemos (e continuam a em alguns aspectos), este mesmo problema. Eu acho que este problema é uma falta de análise inicial e uma falta de devs gastando tempo suficiente estimar uma história de usuário.

Você pode começar com uma história como:

As an administrative user I can create a new widget.

OK, o que isso significa? Depois de algumas análises, isso pode significar:

As an administrative user I can create a new widget in created status with complex data validation errors.

Assim, depois que uma lista de campos, como grande, e que os campos obrigatórios são para salvar o banco de dados. A básica UI mock up seria bom também.

Outra história de usuário para o próximo sprint poderia ser:

As an administrative user I can edit a created widget and correct the complex data validation issue to move the widget to completed status.

lista Então, as regras de validação complexas.

Answer 4

Nós passar a segunda-feira no início de cada 2 semanas de sprint passando por cima das histórias como criado pela equipe do projeto, durante o qual nós normalmente refinar as histórias um pouco.

No início do sprint, as histórias devem estar prontos. Se você precisar refiná-los um pouco, eu acho que você (a equipe de desenvolvimento, o ScrumMaster, a equipe do projeto) deveria fazer isso um pouco à frente, durante o sprint anterior.

A melhor forma de quebrar o ciclo de incompleta / histórias insuficientes para nossos sprints?

Você está talvez subestimando histórias ou são demasiado grande e demasiado vago. Em ambos os casos, isso soa como um problema de estimação e uma boa maneira de melhorar é para reduzir o tamanho de histórias. Para trabalho sobre esta questão, você poderia dedicar algum tempo (por exemplo, 5% de cada sprint) para Product Backlog Grooming a fim de preparar as histórias mais importantes e reduzir seu tamanho, colocando-os sobre dieta se necessário antes o próximo sprint. E isso vai realmente fazer o mais suave reunião de planejamento do sprint.

Esta é uma falha da equipe do projeto para pregar para baixo as histórias suficientemente no início, ou devemos (ou seja, a equipe de desenvolvimento) tirar um pouco da responsabilidade?

A responsabilidade não é que IMHO importante (exceto por razões políticas, mas talvez eles não produzem muito valor de qualquer maneira), tanto a equipe de desenvolvimento ea equipe do projeto estão trabalhando juntos e "não" em conjunto. O que é importante aqui é inspecionar e adaptar-se para remover o obstáculo. Então, é da responsabilidade da equipe dev para fazer este problema visível (ele é um impedimento). E é a responsabilidade ScrumMaster para trabalhar sobre este impedimento. O fracasso seria não trabalhar nele. sessões Backlog Grooming são uma maneira de fazê-lo. E no final, eu tenho certeza que a equipe do projeto irá melhorar e obter uma melhor compreensão do que a equipe de desenvolvimento está esperando. E você será tanto produzir melhores resultados.

Answer 5

Muitas boas idéias aqui já sobre os aspectos do scrum do seu problema. Com base no seu comentário:

particular, descobrimos que são fornecidos com wireframes UI que contêm muito mais complexidade do que as histórias originais teria implicado (por exemplo funcionalidade duplicada por razões de usabilidade).

Eu também tenho uma preocupação que você pode precisar para o trabalho em você processo de desenvolvimento bem embora. Acessando a funcionalidade de vários locais em uma interface de usuário deve ser uma adição simples que consome quase nenhum momento a todos. Se você está achando que este é um problema comum, em seguida, sua funcionalidade é muito intimamente ligado a determinados elementos de interface do usuário. Sua equipe pode precisar melhorar suas habilidades de design (por exemplo: uso padrão).

Answer 6

Isso é interessante. Parece que você está fazendo o planejamento do sprint no sprint? E que a Sprint Backlog é cometida antes da Sprint Planning? Se sim, como é o time cometer ao sprint backlog sem discutir os detalhes das histórias?

Uma abordagem alternativa poderia ser a de fazer o Product Owner ciente de que certas histórias não pode ser adicionado ao sprint backlog devido à falta de clareza. Em particular, que os critérios de aceitação não são totalmente compreendidos. Isto poderia provocar a conversa necessária com o Product Owner. Idealmente, não deve vir a este. Deve ser discutido e resolvido na retrospectiva.