Como yo lo veo, tenemos tres niveles:
Épico : visión amplia de lo que sería bueno hacer. (Por lo general, más que un Sprint)
Historia - Vista más definida y estructurada. (Qué se puede hacer en un Sprint)
Tarea : historia que se desglosó en Componentes (Backend, DB, Frontend, iOS, etc.) (Qué se puede hacer en un día)
Permitir que la gente pague en el sitio web
Permitir que la gente pague en la aplicación móvil
(* - mismo billete)
Hay una manera de crear un Epic en Jira. Y podemos agregar Stories a Epics . No podemos dividir cada historia en tareas para tener una buena estructura. Pero según tengo entendido, hay un camino común. Es para crear sub - tareas para Stories . ¿Qué diferencia habrá con respecto a Tasks en sí? Y luego podemos llevar estas Historias a nuestro Sprint con la función de creación de resortes de trabajo pendiente de una placa. PERO.
Una historia debe ser entregable por sí sola (cuando se completa). Lo mejor es ceñirse a esto como la convención todo el tiempo.
Cuando se trata de Jira, cualquier entrada debe ser una historia o un error . Cualquier cosa que no sea un error es una historia. Como señaló, cada vez que se introducen otros tipos, solo causan más confusión. Hemos estado usando este enfoque simplista durante bastante tiempo y nunca tuvimos ningún problema con él. Obviamente, las épicas todavía están en uso cuando se involucran múltiples historias y/o errores que posiblemente abarcan múltiples sprints.
Hemos adaptado el uso de 3 niveles como dijiste, siendo el último de subtareas. Creamos tantas subtareas de implementación como sea necesario, pero también incluimos todas las demás acciones que se incluyen en nuestra Definición de Listo como subtareas. De esta manera, cuando se cierra una historia, estamos seguros de que se aplica DoD.
Con respecto a tus preguntas:
Solo estime historias, nunca subtareas. Está perfectamente bien que el equipo proponga subtareas mientras discute la estimación, sin embargo, deben proporcionar sus estimaciones como equipo para toda la historia considerando todo lo relacionado con completarla en un estado liberable. Los miembros pueden compartir sus opiniones sobre lo que implican diferentes subtareas, pero depende del equipo acordar una estimación compartida. Resumir las estimaciones para cada subtarea proporcionada por diferentes miembros del equipo no será lo mismo (al menos en el nivel de compromiso)
Usa la estimación restante. Preferimos estimar el trabajo restante en nuestra sesión de planificación de sprint y usar eso (1 punto en su caso). Si mantiene los puntos originales, tendrá que mantener en mente la cantidad de trabajo completado, que es un equipaje innecesario. Además, el propósito es completar cada historia dentro del sprint planificado, y el equipo mejora al hacerlo a medida que avanzan juntos en un par de sprints. El esfuerzo "perdido" no importa mucho, ya que lo importante es la cantidad de funcionalidad de trabajo que ofrece.
Lo que ha hecho mi equipo es usar las subtareas de JIRA como tareas: los detalles de desglose mecánico de una historia.
Mientras tanto, las 'Tareas' de JIRA están al mismo nivel que las Historias, pero se diferencian por el hecho de que no aportan valor comercial directo a ningún usuario. Por ejemplo, 'optimizar el compilador', 'investigar [nueva tecnología]' y 'aumentar la cobertura de la prueba' pueden calificar como tareas de JIRA. Estos también pueden tener subtareas propias.
Respecto a tus preguntas...
La estimación la realiza el Equipo, representando el trabajo del Equipo. No por particulares. Esto es parte del propósito de un equipo interfuncional y la propiedad del código compartido. Las personas no son dueñas de las Historias. Todo el Equipo lo hace.
Mi equipo lo ha intentado en ambos sentidos. Primero, tratamos de mantener la estimación anterior. Nuestro razonamiento fue para que 'no se perdiera el conocimiento del esfuerzo que pusimos en ello'. Con el tiempo descubrimos que a nadie realmente le importaba eso, y mantener historias de alrededor de 10 puntos a las que les quedaban 30 minutos de trabajo se estaba volviendo confuso. Así que al final decidimos cambiar y funcionó mucho mejor. De todos modos, esto encaja mejor con toda la idea de Agile; si tiene más/mejor información con respecto a esa estimación (el hecho de que está hecha en un 90 %), entonces, ¿por qué no debería actualizarla?