¿Qué tan grande debe ser cada historia para una persona en un sprint de 3 semanas?

TL; DR

Básicamente, todo su conjunto de supuestos de planificación no es ágil. Debe revisar cómo está planificando sus iteraciones y cómo su equipo planea estimar el trabajo que cree que se puede completar para la iteración actual. A continuación, se ofrece un análisis más detallado.

Análisis detallado

Sabemos que la planificación a largo plazo (planificación del lanzamiento) debe estar en los puntos de la historia. [sic]

No. La planificación ágil de lanzamientos se realiza en iteraciones . Por lo tanto, un plan de proyecto Scrum estimará un rango aproximado de iteraciones necesarias para alcanzar el producto mínimo viable o completar el Backlog del producto inicial. Esto es solo una estimación, ya que el contenido de la acumulación cambiará con el tiempo, y la longitud y precisión de las estimaciones también cambiarán junto con el Cono de incertidumbre .

Pero para la planificación de sprints, debe basarse en el compromiso.

Una vez más, no. Sprint Planning es basado en la capacidad . El único punto de seguimiento (o Crear una estimación inicial de) la velocidad promedio del equipo es encontrar la capacidad sostenible del equipo para trabajar en el tiempo. Si bien el equipo debe asegurarse de no comprometerse nunca demasiado a trabajar en un Sprint solo porque el rango de velocidad o el promedio dice que debe haber capacidad disponible, es responsabilidad del equipo planificar la iteración actual tomando en cuenta la composición del equipo, la disponibilidad y otros factores que afectan al Sprint actual en consideración.

Decir que los Sprints están «basados en el compromiso» probablemente se use como un garrote emocional para hacer que los equipos se comprometan más trabajo del que deberían, porque por supuesto los miembros del equipo deberían estar «comprometidos». Sin embargo, eso «es un mal uso; en el mundo real, la capacidad del equipo generalmente debe reducirse pero rara vez aumentarse durante la planificación. Si el equipo se ha comprometido poco, entonces se puede quitar trabajo adicional del Product Backlog según sea necesario, pero recortar el alcance es casi siempre políticamente complicado y, a menudo, pone en riesgo el Sprint Goal. Por lo tanto, no haga eso.

La capacidad puede ser una métrica relativamente objetiva. Por otro lado, el compromiso (al igual que el patriotismo) «no se puede medir a menos que usted» están pidiendo a las personas que «hagan el máximo sacrificio», lo que es una especie de antítesis de toda la premisa de la sostenibilidad ágil. Nunca se comprometa con una marcha de la muerte .

Para un sprint de tres semanas, ¿qué tamaño debe tener cada historia para una persona?

Esto merece un libro completo lleno de «no». Las historias nunca se clasifican ni se aceptan por una persona. Todas las historias se estiman en función de los recursos completos y coordinados de un equipo multifuncional que trabaja juntos para completar cada historia. Las historias se aceptan o rechazan en función de si:

1. Son esenciales para el objetivo del Sprint actual.
2. Se ajustarán a la capacidad estimada disponible para el Sprint actual.

Un solo elemento de la lista de trabajos pendientes del producto puede ser cualquier re desde 0 puntos de historia hasta el máximo disponible para todo el Sprint. Sin embargo, una buena historia que cumpla con los criterios INVEST generalmente se compone de tareas de Sprint Backlog de alrededor de 0.5 días a 2.0 días de duración. Recuerde que cuanto más pequeña es la tarea o la historia, más precisa suele ser la estimación, por lo que una docena de historias de 5 puntos (cuando se calculan con precisión) son generalmente más confiables que una sola historia de 60 puntos. Sin embargo, la madurez de su equipo y la precisión de la estimación ciertamente pueden variar.