Los puntos de historia son unidad de trabajo empleada habitualmente en Extreme Programming y metodologías ágiles, definida por la cantidad de trabajo a realizar en un día de trabajo ideal (tiempo ideal). Expresa una estimación que se requerirá para implementar completamente un elemento de la pila de producto. En lugar de medir el trabajo en horas o días, se utiliza una escala relativa para comparar la complejidad entre diferentes tareas.

Una de las ventajas de utilizar los Puntos de Historia en lugar de medidas más precisas de tiempo es que permite al equipo enfocarse en la complejidad de la tarea en lugar de en el tiempo que tardará en completarse. Esto ayuda a evitar subestimar o sobreestimar el tiempo que llevará completar una tarea y permite una planificación más precisa.

A cada uno de los elementos de la pila de producto le asignamos un valor en puntos. Al final, lo importante son los valores relativos, una historia de 2 puntos debe ser el doble de trabajo que una historia que tiene asignado 1 punto. 

Al definir la cantidad de puntos hay que tomar en cuenta la cantidad de trabajo por hacer. Si por ejemplo hay que actualizar el tamaño de un campo en su cantidad de caracteres que acepta. Antes de asignar los puntos deberemos tener en cuenta todas las partes en las que tenemos que hacer ese ajuste. Actualizar el campo en una forma, no involucra el mismo trabajo que actualizarlo en 20 formas.

La cantidad de trabajo por hacer o el esfuerzo para hacerla, no se deberá relacionar con la cantidad de puntos. Un punto no representa 1 hora o 2 horas, es una medida relativa que el equipo asigna para identificar que un elemento con más puntos requiere más esfuerzo que otro con menos puntos.

Una actividad interesante en SCRUM es la estimación, dado que el todo el equipo debe estar involucrado y participar, de esta manera el trabajo comprometido es responsabilidad del equipo, de quién hará el trabajo y de nadie más. El equipo es el que adquiere la responsabilidad de entregar el trabajo para la siguiente reunión de revisión, un compromiso que no es de un miembro del equipo, del Product Owner, del SCRUM Máster, o de la Gerencia, es de todos.

Cuando se hace la estimación es de extrema importancia que participe el equipo, uno, para estar en las explicaciones que el Product Owner pueda dar, dos, para entender de primera mano lo que se quiere implementar, y tres, para ver lo que piensa el equipo de cada funcionalidad y de cómo se puede implementar, si fuera el caso.  Así, todo el equipo decide si una funcionalidad es simple o compleja, si se incluye en el siguiente Sprint o no. De esta forma el compromiso es del equipo, el equipo decidió que es lo que se entrega en el Sprint y por consiguiente hay que hacerlo.

En la estimación del trabajo para el siguiente Sprint es también responsabilidad del SCRUM Máster hacer las preguntas adecuadas para asegurar que el equipo no está tomando mucho, o poco trabajo para hacer. Revisar problemas potenciales para reducir el riesgo de estarse comprometiendo con demasiado trabajo. Por lo general en el primer Sprint el equipo se queda largo o corto, mas largo que corto, del trabajo que se puede hacer y va mejorando a medida que se conocen mejor sus capacidades

Photo by fauxels from Pexels

Hacia el final de un proyecto de desarrollo de software estamos con los tiempos en contra de nosotros, nos esforzamos por cumplir con el tiempo, funcionalidad y si se puede con la calidad, lo que nos genera un desgaste tremendo. La realidad es que lo resolvemos como dicen a “fuerza bruta”, con puro corazón.  Después de varios proyectos ya el ánimo no es el mejor y nos preguntamos: ¿Por qué cada vez tenemos que pasar por lo mismo?, algo que dijimos que ya no sucedería. ¿Qué fue lo que no vimos?

Es claro que cuando estimamos lo hacemos con poca información disponible, nuestro proceso de recopilación de información no es muy efectivo o no le dedicamos el tiempo suficiente, es común también, que no conocemos quién hará el proyecto, desconocemos las capacidades de la organización. No siempre conocemos la tecnología en la que se implementará el proyecto. A lo anterior le podemos añadir un proceso de desarrollo inmaduro,que en las primeras semanas de ejecución vemos al estimado alejarse rápidamente. Por ultimo, nuestro proceso de estimación es deficiente dado que no consideramos muchos factores, como los mencionados anteriormente.

Esta es una pregunta interesante ya que típicamente asociamos la estimación a un cobro al cliente y no es siempre así. Antes de tener un proyecto se hace una estimación para la propuesta con información no muy clara, bastante general y que es lo que le vendemos al cliente.

Cuando ya tenemos un proyecto, es decir que la propuesta ya fue aprobada, necesitamos revisar la estimación de la propuesta o estimar de nuevo para cerciorarnos que las condiciones iniciales se siguen cumpliendo. Quién conformará el equipo, qué experiencia tiene, se puede lograr el proyecto con este equipo, se tiene la infraestructura que se pensó, etc., si no es así, hay que hacer los ajustes necesarios.

• Al inicio del proyecto • Contando con los requerimientos detallados • Con el diseño terminado (opcional) • Ante cambios en el proyecto ¿Qué pasa si los estimados difieren mucho de lo que vendimos?, Aquí podemos hacer dos cosas, negociar el nuevo alcance, sobre todo en cuanto a los costos, o bien absorber nosotros los costos. Esto ultimo si fue a nosotros a los que se nos paso algo y que el no tenerlo la aplicación no funcionaría. Independientemente de cómo negociemos, es necesario revisar nuestros estimados para ver si las condiciones del proyecto siguen siendo las mismas y podemos llegar a la fecha de entrega con la funcionalidad y costo requerido.