Puntos de historia de Jira versus estimación de subtarea

La razón por la que los equipos de Scrum a menudo usan puntos de historia para estimar es que proporciona una forma efectiva de calcular la capacidad de un equipo. También permiten realizar pronósticos livianos cuando se planifica el lanzamiento.

Las razones por las que usan estimaciones basadas en el tiempo en las tareas son diferentes. Es para que puedan:

• Dedique tiempo a dividir el trabajo, lo que a menudo ayuda cuando se trata de la implementación.
• Puede verificar que no se hayan comprometido demasiado en un sprint (puede haber parecido bien como puntos de la historia, pero el desglose de tareas puede revelar un compromiso excesivo)
• Verifique que no hayan sobrecargado una disciplina en particular (por ejemplo, demasiado trabajo de prueba y el equipo usa evaluadores dedicados)

Muchos equipos de Scrum comienzan con este enfoque, ya que ayuda a evitar algunos de los escollos de un equipo que es nuevo en Scrum. Los equipos más experimentados pueden abandonar las estimaciones basadas en el tiempo si ya no las encuentran valiosas.

+1000 en la publicación de Daniel: no use horas de tareas en absoluto.

La estimación de horas es algo que recomendarán muchos de los principales expertos ágiles. Y luego mira que las marcas de tiempo. No conozco ninguna voz ágil líder que aún admita el seguimiento de horas de tareas. Se ha considerado contraproducente para la estimación relativista de los puntos de la historia. El objetivo de estimar no es averiguar cuántas horas tomará, es estrictamente el equipo el que decide cuánto trabajo puede realizar en el sprint.

No nos importa cuánto tiempo tome una tarea, o incluso una historia. Nos importa si el equipo entrega lo que estimaron que entregarían.

En lugar de horas para las tareas, la directriz general sobre la que entreno a los equipos es "las tareas deben encajar en el valor de un día de trabajo". Esto permite un seguimiento más fácil del estado, ya que, desde el inicio diario hasta el inicio diario, debe completar tareas. Esta es una guía GENERAL. Recuerde también que un "día" es en realidad solo 4-5 horas de trabajo real.

¡Solo haz puntos de historia! Si ya obtuvo información sobre su velocidad, no necesita estimar horas adicionales. Por lo general, estimamos solo la complejidad de la historia y, en la planificación, el equipo tiene la oportunidad de volver a estimar la historia después de planificar todas las tareas. Luego, el equipo confirma solo aquellas historias que logran hacer en el sprint.

-- Editar

Nuestro equipo también consta de backend (Java) y front-end (HTML, CSS, ...). Como en tu descripción las historias siempre tienen relaciones diferentes de ambas habilidades. Por lo general, el propietario del producto comienza a presentar las historias comenzando por la más importante. Después de cada historia presentada, le preguntamos al equipo si pueden hacer más o si debemos detenernos aquí. Cuando uno de los grupos de habilidades tuvo suficiente para el sprint, revisamos el trabajo pendiente de arriba hacia abajo y tomamos la siguiente historia que los demás pueden hacer. ¡Espero eso ayude!

En el caso de su equipo, diría que es necesario un cambio en su proceso de estimación. Ya que llegaron a la conclusión de que están teniendo dificultades para hacer una estimación precisa hasta que conozcan todas las tareas que se requerirán para cumplir con la historia, deben pensar en ellas antes de hacer su estimación.

Puede hacer esto durante su proceso normal de planificación de sprints, simplemente describa la historia en discusión de la manera más completa posible, tal vez tenga un debate rápido sobre cuál es el mejor enfoque para resolver ese problema y luego simplemente escriba todas las tareas (preferiblemente en la publicación). es para que no necesite volver a escribirlos más tarde) y base sus estimaciones en el esfuerzo total requerido para esas tareas + pruebas adecuadas.

Incluso con este enfoque, su equipo aún debe tener una cantidad límite de puntos donde, si la estimación es mayor que esa cantidad, la historia se divide en varias historias. Siempre trate de mantener sus historias lo más autosuficientes posible sin dejar de mantenerlas fácilmente alcanzables en un solo sprint.

Me parece que la organización de su equipo es la raíz de su problema.

Si necesita saber cuánto trabajo de SQL hay en sprint, supongo que es porque si no hay mucho, el tipo de SQL estará jugando con sus pulgares y podría parecer que podría incluir algunas tareas de SQL más.

Sin embargo, el problema con esto es que estropea la finalización de las historias. Es muy difícil decir que una tarea individual está terminada a menos que también puedas decir que la historia está terminada.

Por ejemplo, tengo una tarea: escribir Db para página web y Tarea: escribir HTML para página web.

y Característica: la página web muestra el nombre de usuario.

A menos que trabajen juntos como un equipo, tanto las tareas de HTML como las de SQL podrían marcarse como realizadas, y cada programador supondría que la otra tarea estaba realizando la función de nombre de usuario.

Si llega al final y la función no está lista, pero el tipo de SQL está ocupado con otra tarea para una historia diferente y no puede volver a la función, entonces terminará con muchas tareas abiertas y 'algo así como listo. ' características.