L'amélioration de la qualité de l'histoire de l'utilisateur [fermé]

Question

Nous utilisons Scrum. Nous rencontrons actuellement des problèmes au cours de sprints quand nous trouvons les histoires de l'utilisateur ne sont pas suffisamment granulaire pour capturer l'effort nécessaire pour terminer le sprint.

En particulier, nous constatons que nous sommes fournis avec wireframes de l'interface utilisateur qui contiennent beaucoup plus de complexité que les histoires originales auraient implicitement (par exemple la fonctionnalité dupliquées pour des raisons de facilité d'utilisation). Cela conduit au graphique burndown ressemblant tout est terminé, le dernier jour du sprint.

Nous passons lundi au début de chaque sprint de 2 semaines va sur les histoires créées par l'équipe du projet, au cours de laquelle nous affinons généralement les histoires un peu et les décomposer en tâches, estimer les heures pour chacun créer le graphique burndown. Au cours de cette journée, il ne se sent pas comme nous avons le temps d'améliorer de façon significative la qualité des histoires.

La meilleure façon de briser le cycle des histoires incomplètes / insuffisantes pour nos sprints?

Est-ce un échec de l'équipe du projet pour clouer les histoires suffisamment au début, ou devrions-nous (à savoir l'équipe de développement) prendre une partie de la responsabilité?

Answer 1

Donc, vous dites que:

1. Les clients / utilisateurs parlent de l'équipe de projet
2. L'équipe de projet écrit des histoires et crée wireframes
3. L'équipe de développement se décompose en tâches histoires et estimations

Est-il possible de l'équipe de développement en train de parler aux clients / utilisateurs? Histoires d'utilisateurs sont parfois considérés comme un moyen de lancer une conversation, par opposition aux documents exigence / cahier des charges.

EDIT: Quelques liens:

• une histoire d'utilisateur est un cas d'utilisation comme une gazelle est à un kiosque
• Six Caractéristiques d'une bonne histoire utilisateur - INVESTIR modèle
• Le client est toujours disponible

EDIT: Martin Fowler a fait un billet de blog hier sur ConversationalStories qui couvre ce bien mieux que Je l'ai fait.

Answer 2

Courez-vous sprint retrospectives? A la fin de la rétrospective, vous devriez avoir points d'action prioritaires pour améliorer ce qui est arrivé dans le sprint précédent. Les mêmes choses vont mal ne devrait pas être à plusieurs reprises .

Votre propriétaire du produit accessible au cours d'un sprint? Sinon, vous devrez peut-être ajouter plus pour une estimation que le détail d'une histoire utilisateur est incomplète.

suggestion @Pascal de consacrer 5% de votre sprint pour le toilettage de backlog de produit est un bon. Cela devrait permettre aux témoignages d'utilisateurs d'être dans un endroit plus détaillé avant le début de votre sprint.

  

Nous passons lundi au début de   chaque sprint de 2 semaines aller sur le   histoires créées par le projet   équipe, au cours de laquelle nous avons généralement   affiner les histoires un peu et pause   les en tâches, estimer les   heures pour chaque pour créer le burndown   graphique. Au cours de cette journée, il ne se sent pas   comme nous avons le temps de façon significative   améliorer la qualité des histoires.

On dirait que ceci est votre session de planification de sprint, avez-vous le contrôle sur ce que les histoires utilisateur que vous commiting à compléter lors du sprint? Comment pouvez-vous engager si vous n'avez pas suffisamment de détails?

Cela vous ramène à avoir une bonne rétrospective et résolution les questions soulevées.

  

La meilleure façon de briser le cycle de   histoires incomplètes / insuffisantes pour   nos sprints?

Rétrospectives, la planification, le toilettage backlog.

  

Est-ce un échec de l'équipe de projet   à clouer les histoires suffisamment   au départ, ou devrions-nous (à savoir la   dev team) prendre certains des   responsabilité?

Sa la responsabilité de l'équipe dans son ensemble. Trouver le blâme isnt va donner de la valeur, mais tous prendre la responsabilité donnera tous une chance de réaliser le projet avec succès.

Peut-être au cours de ces séances de planification du lundi matin, vous pouvez impliquer celui qui est en train d'écrire les histoires utilisateur / wireframes et travailler ensemble pour découvrir ce détail manque d'eux, ce détail rendrait vos estimations plus facile et plus précis. Peut-être un modèle de ce qu'ils devraient inclure pourrait être établi.

Answer 3

Nous avons eu (et nous continuons à certains égards) ce même problème. Je pense que ce problème est un manque d'analyse dès le départ et le manque de temps assez devs dépenses estimation d'une histoire d'utilisateur.

Vous pouvez commencer par une histoire comme:

As an administrative user I can create a new widget.

OK, qu'est-ce que cela signifie? Après une analyse, cela pourrait vouloir dire:

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

Alors, après que la liste des champs, la taille, et quels sont les champs obligatoires sont pour la sauvegarde de la base de données. Une maquette de l'interface utilisateur de base en serait bien aussi.

Une autre histoire d'utilisateur pour le prochain sprint pourrait être:

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

Ensuite, la liste des règles de validation complexes.

Answer 4

  

Nous passons lundi au début de chaque sprint de 2 semaines va au cours des histoires créées par l'équipe du projet, au cours de laquelle nous affinons généralement les histoires un peu.

Au début du sprint, les histoires devraient être prêts. Si vous avez besoin de les affiner un peu, je pense que vous (l'équipe de développement, le ScrumMaster, l'équipe du projet) devrait faire un peu en avance, lors du sprint précédent.

  

La meilleure façon de briser le cycle des histoires incomplètes / insuffisantes pour nos sprints?

Vous sous-estimez peut-être des histoires ou ils sont trop gros et trop vague. Dans les deux cas, cela ressemble à un problème d'estimation et une bonne façon d'améliorer est de réduire la taille des histoires. Pour travailler sur cette question, vous pourriez consacrer un peu de temps (par exemple 5% de chaque sprint) Carnet de commandes de produit Toilettage afin de préparer les histoires les plus importantes et de réduire leur taille en les mettant sur le régime alimentaire si nécessaire avant le sprint suivant. Et cela va réellement faire la planification de sprint réunion plus lisse.

  

Est-ce un échec de l'équipe du projet pour clouer les histoires suffisamment au début, ou devrions-nous (à savoir l'équipe de développement) prendre une partie de la responsabilité?

La responsabilité n'est pas important à mon humble avis (sauf pour des raisons politiques peut-être, mais ils ne produisent pas beaucoup de valeur de toute façon), tant l'équipe de développement et l'équipe du projet travaillent ensemble et « à défaut » ensemble. Ce qui est important est ici pour inspecter et adapter pour enlever l'obstacle. Ainsi, il est de la responsabilité de l'équipe de dev pour rendre visible ce problème (il est un obstacle). Et il est de la responsabilité de ScrumMaster travailler sur cet obstacle. L'échec serait de ne pas travailler là-dessus. séances de toilettage Carnet de commandes sont une façon de le faire. Et à la fin, je suis sûr que l'équipe du projet permettra d'améliorer et d'obtenir une meilleure compréhension de ce que l'équipe de développement attend. Et vous les deux meilleurs résultats.

Answer 5

Beaucoup de bonnes idées ici déjà sur les aspects de mêlée de votre problème. Sur la base de votre commentaire:

  

particulier, nous constatons que nous sommes fournis avec wireframes de l'interface utilisateur qui contiennent beaucoup plus de complexité que les histoires originales auraient implicitement (par exemple la fonctionnalité dupliquées pour des raisons de facilité d'utilisation).

J'ai aussi une préoccupation que vous pourriez avoir besoin de travailler sur vous processus de développement aussi bien que. Accès à la fonctionnalité à partir de plusieurs emplacements dans une interface utilisateur devrait être une simple addition qui consomme presque pas de temps. Si vous trouvez que cela soit un problème commun, votre fonctionnalité est trop étroitement couplé à des éléments particuliers de l'interface utilisateur. Votre équipe pourrait avoir besoin d'améliorer leurs compétences en conception (par exemple: utilisation du modèle).

Answer 6

Ce qui est intéressant. Il semblerait que vous faites la planification de sprint dans le sprint? Et que le Carnet de commandes Sprint est engagé avant la planification Sprint? Si oui, comment l'équipe commiting au carnet de sprint sans discuter les détails des histoires?

Une autre approche pourrait être de rendre le propriétaire du produit conscient que certaines histoires ne peuvent être ajoutés au carnet de sprint en raison du manque de clarté. En particulier que les critères d'acceptation ne sont pas pleinement compris. Cela pourrait provoquer la conversation nécessaire avec le propriétaire du produit. Idéalement, il ne devrait pas en arriver là. Il devrait être discuté et résolu dans la rétrospective.