La estimación y el compromiso

Saltándome el debate del #noestimates (al que ya le dedicamos sus debidos post, como por ejemplo, debate (ya al más alto nivel) sobre #NoEstimates McConnell y Ron Jeffries) ¿Por qué estimamos? Haciendo una reflexión al estilo de aquella de si no tienes claro “por qué” estás implantando una práctica probablemente dejes de usarla… ¿Por qué intentamos predecir el numero de items, historias o el numero de puntos historia (en cualquiera de sus diferentes variantes)?
Una primera razón que se me viene a la cabeza es… para saber cuántas «cosas» seremos capaces de hacer como equipo en un determinado tiempo, típicamente, un Sprint. Y… ¿Por qué queremos saber, de antemano,  cuántas «cosas» seremos capaces de hacer?
Estimar es intentar adivinar, previamente, cuánto haremos. Medir la velocidad, la realidad, a posteriori, de cuánto hemos terminado en un determinado tiempo (típicamente un Sprint), nos ayuda a estudiar cómo hemos ido, a plantear una posible mejora de la velocidad (a ritmo sostenible, puedes leer también 3 cosas que debes entender sobre la velocidad ágil), e incluso nos ayuda a hacer mejores estimaciones.
Podríamos medir la velocidad al final de un Sprint y no estimar. Pero, entonces… ¿por qué estimamos? Puede haber varias razones, pero una de las fundamentales es para que otras personas, como el Product Owner, u otras ajenas al equipo (como los llamados Stakeholders, a través  del Product Owner), puedan ir haciendo sus propias previsiones, por ello una estimación conlleva algo muy importante… un compromiso. Intentar que lo predicho cumpla, en lo razonable, con la realidad, ya que otras personas tienen confianza en ello, basan parte de su trabajo en ello.
Poco sentido tiene estimar y no preocuparse por cumplir lo estimado o, es más… ni siquiera saber si se ha cumplido.
En modelos de trabajo, culturas, Ágiles, la estimación recae completamente en el Equipo Técnico, en aquellos que van a hacer aquello que se va a estimar. En tiempos oscuros, las estimaciones las hacían precisamente los que no harían el trabajo.
Pero, como le diría el tío Ben a Spiderman, “un gran poder conlleva una gran responsabilidad”, y el poder de decidir cuánto se pretende hacer en un Sprint, conlleva, principalmente, dos responsabilidades, una la de que se hago lo máximo posible (a ritmo sostenible, sin sacrificar la deuda técnica, sin crear walking dead en el código, bla, bla,, bla, esto ya lo he repetido muchas veces) y otra… cumplir con lo dicho, compromiso (sabiendo que ninguna estimación, por naturaleza, es exacta, pero sí cumplir la estimación dentro de un intervalo razonable).
Eso es el compromiso que se asume con haber estimado, es la confianza que damos a otros.

Terminando…

No sé ni cuantos post debe haber en el blog sobre estimaciones, noestimaciones, antiguos, recientes, sobre puntos histor, etc., un tema que me gusta mucho y del que he escrito mucho (hasta una guía de puntos historia), pero de entre todos, para terminar, como complemento a este post, te recomiendo este post de una clase mía, grabada, explicando parte de la estimación ágil.

1 comentario en “La estimación y el compromiso”

  1. Mi visión, cercana a la tuya, pero con un matiz, es la siguiente. Cierto que una estimación genera una expectativa, y que esa expectativa hay que gestionarla. Pero, entiendo que dices que cuando el equipo asigna un valor en puntos a una historia, ¿Se compromete con el product owner? Yo creo que no.
    Incluso el total de historias que se planea hacer en un sprint no es más que un plan, no un compromiso. Nuestro trabajo no es ciencia exacta, y es imposible predecir las cosas. Podemos estimar, mejor o peor, pero predecir, complicado.
    El Product owner es el que debe, mediante su comunicación con los stakeholders, convertir las estimaciones en compromisos, si procede. Hace muy poco publiqué estimar no es comprometerse y creo que ilustra mejor mi postura.
    ¿No crees que habría que diferenciar estimación de compromiso? ¿Que no es lo mismo «Creo que acabaré en tal fecha» con «Me comprometo a acabar en tal fecha»?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba