Punto de historia de Sprint desde la perspectiva de PM

Como gerente de proyectos, estoy interesado en el esfuerzo (estimado y real). Si bien la estimación basada en Sprint se basa en puntos de la historia, ¿cómo puedo traducirlos en esfuerzo para poder rastrearlos e informarlos?

Una y otra vez escucho que debemos abstenernos de asociar horas al punto de la historia; pero como PM necesito hacer un seguimiento de mi esfuerzo como horas. ¿Me estoy perdiendo de algo?

Pensé que sería bueno explicar por qué necesitaba esto. Esto es desde dos perspectivas:

  1. Facturación (la facturación del cliente debe realizarse en horas)

  2. Comparación de mejoras de productividad y revestimiento de base organizacional.

Respuestas (2)

La estimación basada en el tiempo y la estimación puntual de la historia son conceptos diferentes. Hay dos grandes diferencias:

  • Con la estimación de puntos de la historia, el equipo está adivinando el tamaño relativo de las tareas. Por ejemplo, el Piso A es dos veces más grande que el Piso B. El objetivo es que el equipo haga este dimensionamiento relativo de manera consistente.
  • La estimación del punto de la historia es un enfoque basado en métricas. La idea es hacer algo de trabajo y luego medir cuánto tiempo tomó completarlo. Luego use esa medida para predecir el tiempo que llevará hacer un trabajo futuro que sea de un tamaño similar .

Si existe un requisito comercial para realizar un seguimiento del esfuerzo en unidades de tiempo (por ejemplo, si necesita facturar a un cliente por las horas trabajadas), esto debe hacerse registrando el tiempo que lleva completar las tareas. Esto sería completamente independiente del proceso de estimación de puntos de la historia.

Tenga en cuenta que este tipo de registro de tiempo es una sobrecarga y, por lo tanto, reducirá la producción del equipo. Es posible que el equipo se resista a registrar el tiempo a menos que vea una buena justificación para ello.

Si también desea realizar un seguimiento del esfuerzo estimado en unidades de tiempo, el equipo deberá realizar dos rondas de estimación. Primero harían la estimación del punto de la historia (para Scrum) y luego tendrían que hacer una estimación basada en el tiempo (para cumplir con el requisito de gestión del proyecto).

Una vez más, esto sería introducir una sobrecarga que reduciría la producción del equipo. Y una vez más, este costo tendría que ser justificado.

No puede traducir directamente un punto de la historia en el equivalente de una hora de esfuerzo. En el mejor de los casos, un punto de la historia es una distribución continua que representa un rango de valores de tiempo durante los cuales se podría completar una historia.

Decir algo como 2 puntos de historia = 3 días de esfuerzo es incorrecto.

Sin embargo, podría ser cierto que una historia de 2 SP tiene un tiempo de finalización promedio de 3 días con un mínimo de 1 día y un máximo de 5 días utilizando un intervalo de confianza del 95 %.

Quienquiera que pida que los valores de esfuerzo se deriven del punto de la historia o de los valores de velocidad sigue pensando en términos de cascada. Si es absolutamente necesario proporcionar valores de esfuerzo, un método común es descomponer las historias en tareas y hacer que los miembros del equipo realicen un seguimiento de sus horas estimadas y reales en comparación con las tareas individuales.

Sin embargo, si sigue esta ruta, encontrará que muchos miembros del equipo pueden quejarse de que es una carga administrativa. También encontrará comportamientos de relleno. Finalmente, si trabaja con ciertos tipos de gerentes de cascada, expondrá al equipo a la microgestión, algo que generalmente es absolutamente prohibido en los equipos ágiles de scrum.

Como nota al margen, idealmente no hay un rol de PM en un equipo Scrum. Los 3 roles básicos son PO, miembro del equipo y Scrum Master. Gran parte del trabajo tradicional de PM generalmente se divide entre el PO y el Scrum Master, y las responsabilidades organizativas restantes se basan en el equipo general, donde se alienta a las personas a organizarse por sí mismas y se les permite ir más allá de los roles tradicionales de desarrollador o control de calidad. Dicho esto, hay muchos excelentes PM en los equipos Scrum que hacen la transición a un rol de liderazgo de servicio y ayudan a la organización en general a volverse más ágil a medida que el equipo asume las responsabilidades tradicionales del PM.
Entonces, ¿cuál sería una buena manera si un cliente solicita una estimación del costo total del proyecto? Debería haber alguna forma de transformar el SP en horas facturables, ¿no?
No, los puntos de la historia son distribuciones de probabilidad a lo largo del tiempo, por lo que es imposible tratar de equiparar un punto de la historia con una hora exacta equivalente. Puede usar puntos de la historia para derivar pronósticos sobre cuándo podría completarse un proyecto. Muchos equipos realizan algún tipo de estimación basada en el rango. Entonces, por ejemplo, 12-16 semanas con un 80% de confianza. Los equipos generalmente queman una cantidad fija de efectivo durante un período de tiempo para poder obtener un rango de costos. Esto supone que se conoce todo el backlog, lo que siempre es falso.
El truco consiste en trabajar con el cliente para que entienda que los equipos de scrum se centran en la entrega incremental de valor y no asumen que todo el alcance se conoce por adelantado. Véndale al cliente la capacidad del equipo para cambiar las prioridades y desarrollar una acumulación de valor con el tiempo, en lugar de permitir que el cliente pague por un cliente utilizando los principios de planificación en cascada.
Bueno, mañana tengo mi primera reunión con un cliente y estoy bastante nervioso sobre cómo presentárselo. Desearía que hubiera más recursos para esa parte de los métodos ágiles.
Google para los 5 niveles de planificación ágil, ese es el marco general que admite la planificación a más largo plazo y lo que a menudo se puede usar para impulsar las previsiones presupuestarias, así como para ayudarlo a usted o al cliente a comprender por qué el alcance fijo no funciona en proyectos ágiles.