¿Deberíamos contar una historia que ya no es requerida por el Cliente/PO/Administración en nuestra velocidad?

Hemos terminado una historia que PO/Administración ya no requiere. Seguramente esta historia no va a agregar ningún valor comercial. ¿Qué hacer en este caso? ¿Deberíamos contar el esfuerzo en velocidad o no?

La velocidad es principalmente (y de manera más efectiva) una métrica para estimar la capacidad de un equipo para realizar el trabajo futuro dentro de un Sprint o una serie de Sprints, y no pretende ser una medida de productividad o valor empresarial. Debido a que estima la capacidad futura en función del rendimiento histórico, debe tenerlo en cuenta al determinar cómo realizar un seguimiento de su velocidad.

En su caso específico, que es bastante escaso en detalles, sugeriría las siguientes reglas generales:

1. Si la historia se tomó al comienzo del Sprint durante la Planificación del Sprint, y si el trabajo se entregó al final del Sprint de acuerdo con la Definición de Terminado, entonces el trabajo cuenta legítimamente para la velocidad porque expresa correctamente el trabajo planificado. /completado durante el Sprint.

2. Del mismo modo, si la historia perdió su valor durante el Sprint por alguna razón, pero el Product Owner decidió no sacarla del alcance o terminar el Sprint antes de tiempo como resultado, entonces el trabajo aún mide adecuadamente la capacidad del equipo para entregar el trabajo.

3. Si la historia no se completó de acuerdo con la Definición de Hecho, entonces el trabajo no se puede contar para la velocidad del equipo.

4. Si se logró el objetivo del Sprint, ya sea que el propietario del producto haya solicitado o no que se elimine del Sprint, entonces contar o no el trabajo hacia la velocidad básicamente se reduce a cómo desea comunicar sobre la métrica de velocidad: según lo planeado/ trabajo terminado, o como valor o costo de oportunidad. Obviamente, me inclino por lo primero, pero algunos practicantes pueden discrepar legítimamente.

Por un lado, contar el trabajo hacia la velocidad refleja el trabajo planificado completado. Por otro lado, no contarlo hace que el trabajo invalidado sea visible como un lastre en la velocidad.

Siempre que no esté cometiendo el error fundamental de tratar de hacer que la velocidad refleje el esfuerzo o el tiempo invertido, y sea coherente en el uso de la métrica de velocidad para comunicar el estado del proyecto, la forma en que el equipo trata con una una situación como esta no debería tener mucho impacto en una métrica de velocidad expresada como un rango o promedio final.

Sin duda, hay excepciones, como proyectos muy cortos o fallas en la implementación del marco, pero en general esto no debería ser un evento que se aborde en la Retrospectiva de Sprint. Sin embargo, su millaje puede variar.

Gran oportunidad de aprendizaje

Si el trabajo se realizó en función de la PO que prioriza el trabajo, sí, debe contarlo en velocidad. Es posible que las condiciones del mercado hayan cambiado.

Si el equipo de desarrollo siguió adelante por su cuenta, entonces no se puede contar en velocidad. El punto clave es reforzar su proceso y comenzar a trabajar solo si la orden de compra lo prioriza.

Si hubo un malentendido entre el PO y el equipo de desarrollo, entonces debe reforzar su comunicación y comentarios.

De todos modos, esta es una gran oportunidad de aprendizaje. Es hora de una retrospectiva para identificar la causa raíz y encontrar formas de evitar una debacle similar nuevamente.