¿1 punto de historia = 1 día ideal?

En charlas, foros y otros ambientes de discusión, hay debates sobre la unidad a utilizar para estimar el tamaño de las historias de usuario. XP, eXtreme Programming, por ejemplo, utiliza el punto de historia, y lo define como la cantidad de trabajo que se realiza en un día: 1 punto = 1 día ideal.

Realmente la unidad que se utilice es irrelevante. Lo que importa es que el equipo la conozca y la tenga interiorizada, signifique lo mismo para todos y que todo miembro sepa estimar con esa misma unidad.

Usar el tiempo, en el caso de XP los días, también es tema de debate, ya que en los proyectos medimos tamaño en unidad de tiempo, usualmente en horas/hombre o días/hombre. Algún comercial o jefe de proyecto podría, o bien de forma inconsciente o bien caer en la tentación de hacerlo conscientemente, condicionar al equipo en la estimación de las tareas. Cuantas veces nos han dicho al estimar "el proyecto han de ser tantas horas aproximadamente, por encima de eso el cliente no lo aceptará....". Por otro lado solemos caer en considerar la medida de trabajo "tiempo ideal" equivalente a la medida de tiempo real o duración, no es fácil entender que por ejemplo 4 horas de tiempo ideal se han realizado en 6 horas reales, aunque eso pueda ser una muy buena productividad.

Página de login, algo común a muchas aplicaciones

Lo ideal es que cada equipo defina el punto de historia como algo que le sea representativo, cualquier elemento con el que el equipo se sienta cómodo es válido; por ejemplo en pantallas maestro-detalle, en listados de 10 columnas y totales, páginas de login... Toda aplicación suele tener una página de login, por tanto es un buen referente común de los equipos para una unidad de tamaño. He trabajado con un cliente con una buena experiencia en que un punto de historia de partida fue media jornada y que consideró la jornada de 6 horas en tiempo ideal, por tanto razonablemente realizable en 8 horas reales.

Una vez hayamos empezado a rodar el punto de historia toma su significado, y probablemente no represente ese tiempo ideal con el que el equipo ha comenzado. Es momento de desacoplar, no mirar atrás, permitir que el sistema recalibre el punto de historia a lo que le llevado la mejora continua del marco de Scrum.