Sprint Planning: Puntos de Historia vs Horas de Trabajo

He querido iniciar con esta interrogante, porque es algo que siempre me han consultado los Equipos Scrum con los que he trabajado.

Al respecto, tienes dos posibles escenarios:

El primero es bastante sencillo, si tu equipo lleva trabajando mas de 5 sprints juntos, entonces puedes tomar el promedio de su velocity correspondiente a los últimos 5 sprints y usar los puntos de historia como una línea de referencia para indicar el posible compromiso para el presente sprint. Por ejemplo si el promedio salió 45 puntos de historia, entonces puedes seleccionar según la prioridad dada por el Product Owner las historias cuya estimación sumen aproximadamente 45 puntos, y esa sería la respuesta.

Si tu equipo lleva trabajando mas de 5 sprints juntos, entonces puedes tomar el promedio de su velocity para indicar el compromiso del siguiente sprint.

Sin embargo, que pasaría si fuese un equipo nuevo, ahí ya no dispones de data histórica, y es, en ese momento en el que comienza a salir muchas dudas, tales como: ¿Cuántas horas tomará desarrollar ésta historia de usuario?, ¿Cuántas horas disponibles tiene el equipo?, llegando al punto de querer estimar las historias de usuario en relación a las horas de trabajo de cada miembro del equipo.

Para explicarlo mejor, quisiera mostrarte la siguiente tabla de relación:

Cómo podemos ver, los puntos de historia tienen su origen en las historias de usuario y sirve para comparar el valor del negocio, la complejidad, el riesgo y las dependencias que tiene una historia de usuario respecto de las otras que conforman el backlog.

Sin embargo, las horas de trabajo tienen su origen en las tareas y sirve para determinar cuánto esfuerzo se necesita para realizar una tarea.

Asimismo, una historia de usuario está conformada por un conjunto de tareas y comprende múltiples tipos de trabajo, por lo que es poco probable que sea desarrollada por una sola persona, ya que de ser así, se tendrían muchas historias de usuario en paralelo en estado “Doing”, incrementando el WIP (Work in Progress, el cual no entraré en detalle, pero será tema de otro artículo); muy por el contrario, una tarea generalmente es realizada por una sola persona, representa un solo tipo de trabajo y forman parte de una historia de usuario.

Ahora, que ya tienes claro las principales diferencias entre historias de usuario, tareas, puntos de historia y horas de trabajo, quiero que volvamos a pensar en la pregunta inicial de nuestro Product Owner: ¿Cuántas Historias de Usuario puede desarrollar el equipo?.

Para equipos que sean nuevos y no tengan una velocidad histórica, se puede usar el framework #SAFe a fin de predecir la capacidad para el nuevo #Sprint.

Para responder está pregunta, podemos hacer uso del framework SAFe, en la cual indica que para equipos que sean nuevos y no tengan una velocidad histórica para usar con el fin de predecir su capacidad para el Sprint, se puede aplicar el siguiente enfoque:

1. Asignar 1 punto de historia por cada día laborable del sprint a cada miembro del equipo.

2. Restar 1 punto de historia por cada día de vacaciones, licencias, etc.

Por ejemplo, para un sprint de 2 semanas con un equipo de 9 personas, se realizaría lo siguiente:

• Nº de días laborables: 10 días.

• Ceremonias ágiles: 2 días (se recomienda considerarlo por cada miembro del equipo).

• Nº de miembros del equipo: 9 personas

• Otros (Licencias, vacaciones, etc.): 2 días.

Por lo tanto:

Puntos de Historia = {[(10 días laborables - 2 días ceremonias) x 9 personas] - 2 días}

Puntos de Historia = 70

Ahora que tu mochila ya tiene una nueva herramienta para estimar, espero que tu Sprint Planning sea un éxito, que puedas facilitarlo correctamente y que puedas absolver las dudas tanto de tu Product Owner, Development Team y de cualquier Stakeholder.