¿Qué hacer con la estimación de la historia incompleta?

Soy parte de un equipo de desarrollo que es relativamente nuevo Scrum, supongamos que al final del sprint algunas historias importantes son in progresso no acceptedpor el PO.

En primer lugar, ¿qué pasa con esas historias de usuarios? ¿Los llevas al próximo sprint?

Si es así, ¿deberían ser reestimados? En mi opinión, el trabajo restante en estas historias de usuario puede ser mínimo o mucho. ¿Si no, porque no?

EDITAR: en mi caso específico, las historias no se completaron debido a un impedimento que duró unos días, no debido a la subestimación de la historia del usuario. Para aquellos de ustedes que pueden ayudar, estamos utilizandoVersionOne

agile scrum

— código comestible
fuente

Trabajo con un proceso de XP y me he preguntado cuál es la mejor manera de lidiar con este tipo de situaciones

— Chrisbunney

El hecho de no identificar un impedimento como posible riesgo y determinar la exposición al riesgo RE (impacto * probabilidad) indica un problema con la estimación. Una historia de usuario con un alto RE necesita tener un mayor amortiguador de costo y tiempo asociado para abordar esos riesgos, en caso de que se conviertan en problemas.

— Thomas Owens

doblar y agregar 32, al igual que C => F

— Paul

Respuestas:

En primer lugar, ¿qué pasa con esas historias de usuarios? ¿Los llevas al próximo sprint?

Depende. Si ninguna otra historia tiene mayor prioridad, entonces sí, se trasladan al siguiente sprint. Si otras historias tienen una prioridad más alta, entonces podrían volver a entrar en la cartera de pedidos del producto si no hay suficiente espacio en el sprint para acomodarlas. Todo esto sucede en la planificación del sprint, en función de las prioridades asignadas a cada historia por el propietario del producto. Dado que uno de los propósitos de los métodos ágiles como Scrum es maximizar el valor entregado mientras se reduce el tiempo, todo se reduce a cuánto valor se agrega al terminar esas historias.

Independientemente de lo que ocurra, aún debe luchar por un producto potencialmente enviable al final del sprint. Esto podría significar retroceder para garantizar que el producto de fin de carrera supere todas las pruebas y que el usuario pueda utilizar las funciones completas sin ningún problema significativo.

Si es así, ¿deberían ser reestimados? En mi opinión, el trabajo restante en estas historias de usuario puede ser mínimo o mucho. ¿Si no, porque no?

No volvería a estimar porque, en Scrum, estimas una historia cuando la aceptas, comienzas a trabajar y no tienes el concepto de completar parcialmente . Una historia está 100% completa, probada y aceptada (hecha) o no está hecha. Si no hay un concepto de parcialmente completado, no hay forma de determinar cuánto trabajo le queda a la historia. Parece que tampoco estoy solo en este pensamiento . Calculó el trabajo que pensó que podía hacer, por lo tanto, deje este punto de datos y discuta por qué la estimación no fue correcta en su sprint postmortem e intente evitar cometer ese error en futuros sprints.

— Thomas Owens
fuente

Solo hemos experimentado esto una vez, y no tenía que ver con que la estimación fuera incorrecta, tuvimos un impedimento que resultó en el trabajo realizado, pero no probado.

— código edible

@ user1016253 Eso significa que su estimación tuvo un problema. Las estimaciones deben incluir la exposición al riesgo (impacto * probabilidad = exposición, donde la exposición tiene un impacto en el costo, el tiempo y la calidad). Debido a que sucedió un impedimento, pero la estimación no lo explicaba (o no explicaba lo suficiente), algo fue pasado por alto o mal evaluado (el impacto o la probabilidad fue demasiado baja, lo que significa que la exposición fue demasiado bajo, lo que significa que no se asignaron suficientes recursos para identificar y corregir el problema cuando ocurrió).

— Thomas Owens

@ user1016253 Y si tiene problemas para estimar y ver los riesgos y posibles obstáculos, tal vez una buena idea sería descomponer la historia, ya sea en varias historias que cada una de ellas va a la cartera de pedidos o sub-historias para que el equipo de desarrollo las use solo para comprender El trabajo que hay que hacer. A menudo es más fácil estimar y realizar análisis de riesgo en una unidad de trabajo más pequeña.

— Thomas Owens

@Thomas Owens: Esa no parece ser una forma útil de gestionar el riesgo para mí. En particular, un evento de baja probabilidad que no es catastrófico es una exposición baja y, por lo tanto, incluso un proyecto bien administrado puede verse retrasado en ocasiones. Si nunca te arriesgas, lograrás muy poco. Por supuesto, el seguimiento de la estimación debe evitar aceptar tales excusas, o terminará haciendo estimaciones que son tan válidas como las inversiones que llevaron al reciente colapso hipotecario, y por las mismas razones

— David Thornley,

@DavidThornley No es una forma de gestionar el riesgo en absoluto, sino un punto de partida para un plan de gestión de riesgos que también incluiría estrategias de detección y mitigación. Es una técnica utilizada para garantizar que tenga suficiente dinero y tiempo en su plan en caso de que los riesgos se conviertan en problemas. Es defendido por Steve McConnell en Software Estimation y Karl Wiegers en este documento . Es importante darse cuenta de que no es un búfer por tarea, sino un búfer de proyecto (o iteración) si se materializan varios riesgos.

— Thomas Owens

Por lo general, corresponde al maestro Scrum elegido decidir qué será de las tareas que han superado un sprint, obviamente después de consultar al resto del equipo y al patrocinador del proyecto / propietario del producto. Al final de un sprint, es el momento de revisar cuáles son las prioridades. Es posible que la historia en cuestión tenga una prioridad menor que una historia nueva / existente y se vuelva a colocar en el rastreador como 'en curso' o cualquier etiqueta que use su rastreador, lo que indica que esta historia se debe seguir en otro punto a tiempo. Alternativamente, la historia se puede descifrar por completo. No ha mencionado qué rastreador está utilizando, pero la mayoría de los que he visto le permiten configurar una historia como 'descifrada' si ya no forma parte del proyecto.

En segundo lugar, dado que su equipo es nuevo en Scrum, todo esto es parte del proceso de aprendizaje. Ahora ha reconocido que algunas historias son demasiado grandes, por lo que su equipo tomará más tiempo para desglosar las historias. Normalmente es responsabilidad del scrum master asegurarse de que esto suceda. El Scrum Master también tendrá que consultar al patrocinador del proyecto / propietario del producto con historias incompletas para tratar de desglosarlas aún más u obtener la última palabra sobre cómo descifrarlas por completo.

En mi equipo, se elige un nuevo maestro Scrum cada 2 semanas (sprint), por lo que todos tienen la oportunidad de administrar tareas, organizar reuniones Scrum y garantizar que todos envíen informes de progreso. Espero que ese sea el caso en su propio equipo, ciertamente es una buena experiencia.

— Planeta desolado
fuente

Nitpick: La decisión de qué hacer con la historia incompleta es una cuestión de priorización. Por lo tanto, creo que el propietario del producto debería decidir esto, no el maestro Scrum.

— sleske

@sleske - De acuerdo. Debería haberlo aclarado en mi respuesta. Originalmente dije que el scrum master consultaría al equipo, pero debería haber incluido al patrocinador / propietario del proyecto, lo que he corregido. Gracias por la cabeza levantada sin embargo.

— Desolate Planet el

Si las historias incompletas siguen estando incompletas al final de un sprint, en realidad no puedes desglosarlas en ese punto porque es probable que eso subvierta completamente la Definición de Hecho - "¿Entonces estás diciendo que parte de la historia está Hecho? ¡Pero aún no se ha revisado el código! " Es por eso que las historias épicas como solteras son horribles y nunca deberían permitirse en sprints.

— Robin Green

@RobinGreen Estoy de acuerdo con tu opinión sobre las epopeyas y no soy fanático de ellas. Una de las cosas clave (algo con lo que muchas personas con las que he trabajado pasan por alto) es el valor de las retrospectivas. Recientemente comenzamos a usar el tablero Agile de JIRA y con frecuencia le muestro al equipo la tabla de rendimiento del equipo. Las historias incompletas se discuten si suceden y cuándo suceden, y se vuelven a colocar inmediatamente en la cartera de pedidos. En la retrospectiva, vemos por qué la historia estaba incompleta. ¿Falta de recursos? ¿Falta de conocimiento? o tal vez una combinación suelta de los dos.

— Desolate Planet