Los puntos de historia son un concepto proveniente de Extreme Programming sobre el que pivota, de una manera u otra, Scrum. Todos los equipos los utilizan, casi todos ellos lo hacen mal. Los puntos de historia solo deben utilizarse para estimar incrementos de valor, no deben utilizarse para tareas técnicas o cualquier otra actividad que no contribuya de forma directa e inequívoca al valor. Aunque llamándose “puntos de historia” ya debería dar una pista de por qué no se debe estimar cualquier item.
Vamos a dejarlo claro desde el principio. Los puntos de historia no miden el esfuerzo. ¿De acuerdo?, vamos a repetirlo, No, nein, niente: No miden esfuerzo. Esfuerzo es una acción práctica que se ejerce para abordar una historia de usuario. Mensurable, concreta, comparable. Una preciosidad tangible. De acuerdo, no es tan así, pero se ejemplifica mejor por medio de una hipérbole descarada.
¿Quizá los puntos de historia representan complejidad? Es decir, ¿entendiéndolo como una representación de una colección múltiple de objetos diversos?, si fuera así, significaría que un proceso dado es descomponible en piezas de menor entidad que pueden ser abordadas en serie o en paralelo… No parece tampoco una buena definición. Tampoco un problema, más bien el proceso correcto.
¿Quizá podamos hablar de lo complicado que resulta una tarea, de lo intrincado? En realidad, tampoco, es una medida subjetiva, lo que resulta complicado para uno puede no serlo para otro. Comparar tareas bajo el prisma de lo que resulta o no complicado para su ejecutor es delicado, ya que el conocimiento sobre un área sin duda simplifica el desarrollo.
En realidad que algo sea complicado no es causa sino efecto. Es decir, una consecuencia. Lo que miden los puntos de historia es la incertidumbre. Y la incertidumbre es entendida como falta de definición o concreción externas o internas de la tarea que se desea acometer.
Este es el motivo por el que es tan habitual que tareas valoradas con menos puntos de historia que otras terminan por ejecutarse en más tiempo. Este resultado lo que nos indica es que estamos interpretando mal el objeto de la medición, no que lo midamos mal. Una tarea con un grado de incertidumbre máximo puede tardar menos que otra con una certeza casi completa. Este asunto fue tratado en por Daniel Vacanti en la charla Actionable Metrics for Predictability, y es un tema habitual en este autor y divulgador
Vale, vale… vamos a parar un momento… si todo el mundo habla de los puntos de historia como representación del esfuerzo, quizá no deberíamos volver a tratar este asunto nunca más, quizá es mejor dejarlo como está y alejarnos silbando mientras los equipos hacen equivaler los puntos con las horas sprint tras sprint.
El esfuerzo, incluye, según Mike Cohn:
- La cantidad de trabajo que hay que hacer.
- La complejidad del trabajo a abordar
- Cualquier riesgo o imprecisión que pueda afectar al trabajo.
Cuanto más trabajo, más dificultad para estimar porque más imprevistos pueden surgir. Si la labor fuera mensurable y lineal al estilo de “número de cajas descargadas por hora” no utilizaríamos una sucesión de Fibonacci con valores cada vez más altos.
La complejidad representa la oportunidad de que surja lo imprevisto. Si la labor es simple y repetitiva, carecen de la probabilidad de sucesos fortuitos relacionados con procesos enmarañados o compuestos por numerosos pasos intermedios.
El product backlog es una representación en items discretos de la visión del producto que posee el PO, por lo tanto, debe reflejar la certeza del equipo scrum respecto a la relación semántica entre el significado (lo que creo que sé) y el significante (cómo se expone que se cree saber en un entendimiento común del equipo).
Los riesgos o imprecisiones de una tarea representan, en realidad, incertidumbre. Las asunciones son el acuerdo tácito de que un evento o acción tendrán lugar. Un riesgo es el temor a que un evento o acción se manifieste. Una asunción se transmuta en riesgo cuando no se produce el resultado esperado. Los riesgos deben reflejarse como una parte esencial de aquello que resulta imprevisible, por ejemplo, la integración con un sistema viejo, no documentado, sin testing y con unas políticas de repositado inadecuadas, debe reflejarse en las estimaciones del equipo.
Los puntos de historia miden, pues, la incapacidad para prever e interpretar el futuro. Sirven como métrica de planificación que indica el grado de incertidumbre asumible por un equipo en cada sprint.
En cada iteración es esperable que el equipo sea capaz de asumir más historias de usuario porque despejan incertidumbre con mayor eficacia. La experiencia del equipo con el producto, la relación con los stakeholders, la mejora en los procesos iterativos y de feedback, permitirán mejorar paulatinamente y entregar más valor que tiene sus propias métricas. Los puntos de historia reflejan esta situación porque ante dos unidades de entidad semejante separadas por un periodo de tiempo determinado la más cercana al presente es estimada con un grado de incertidumbre menor, por lo que el equipo es capaz, en situaciones habituales, de entregar más valor por ciclo.
Por esta razón la estimación de cada miembro del equipo es independiente de su experiencia, dado que la incertidumbre es común a todos. Por ese motivo las votaciones son en común porque una discrepancia en el valor indica o una incomprensión de la tarea o un conocimiento mayor que puede ayudar a una mejor definición.
Entendiendo el esfuerzo como un conjunto de valores que, en realidad, indican incertidumbre es posible trabajar con probabilidades de consecución de objetivos y no en cantidades. Pensar en incertidumbre ayuda a cambiar el modo en el que se interpreta la división de conjuntos funcionales en unidades de valor verticales. Disminuir la incertidumbre obliga a un mayor detalle y granularidad, a una mayor comprensión y exploración, a más y mejores conversaciones.
En un esfuerzo por controlar la incertidumbre, los equipos incluirán la documentación y pruebas como parte del Definition of Done. La necesidad de abordar esas tareas, es decir, acciones que arrojan información sobre los procesos orientados a valor, deben tenerse en cuenta a la hora de realizar las estimaciones.
La incertidumbre es todo aquello que vela la visión del producto. Todo aquello que refleja el esfuerzo orientado a su mitigación. De esta manera resulta más sencillo comunicar qué es un punto de historia y la necesidad de estimar de forma eficaz.
Por este motivo, porque es necesario indicar la incertidumbre inherente a la visión de producto; los acercamientos que proponen no estimar las tareas parecen inadecuados. Es cierto que lo importante es alcanzar la madurez necesaria para refinar el backlog en unidades similares en cuanto a nivel de incertidumbre/esfuerzo, pero eso no quiere decir que no haya que hacerlo para buscar un entendimiento común y buscar la comunicación y participantes que puedan ayudar a aliviarla.
Imagen: Unsplash | @kellysikkema
Deja un comentario