Ser predecible es necesario en las empresas y los negocios:  ¿Cuándo estará listo mi coche? ¿Cuánto tiempo llevará la reforma de la casa? ¿Cuánto me costará el arreglo de un vestido de novia? En muchos sectores hemos tratado de ser predecibles históricamente, es una manera de controlar los gastos, las fechas y las expectativas. 

El mundo del software no se escapa de ello, desde que nació siempre hemos tratado de ser predecibles. Sin embargo, poco a poco nos hemos dado cuenta que este sector vive en el entorno complejo. Dada la cantidad de interacciones que participan en un equipo, a veces varias empresas, los requisitos no están claros, no sabemos la aceptación de nuestros usuarios, requisitos que cambian…  Todo ello, hace que haya una gran incertidumbre, lo que genera complejidad y dificulta nuestra capacidad de ser predecibles. 

En varios artículos hemos hablado de utilizar la técnica de Product Backlog Items (PBIs) finalizados por Sprint: ¡Lo ponemos en práctica! 

Midiendo PBIs por Sprint

Vamos a hacer un pequeño ejemplo. Imaginemos que un equipo en los últimos cinco Sprints ha finalizado los siguientes PBIs:

	Sprint 5	Sprint 6	Sprint 7	Sprint 8	Sprint 9
nº PBIs finalizados	6	8	12	10	9

Nuestra media de resolución es 9 y una desviación de 2 es decir 9 ± 2 ¡Ya podemos empezar a trabajar! 

En el Sprint 10, podemos decir que si nos va bien haremos (9+2) 11 PBIs y si nos va mal (9-2) 7 PBIs. De esta manera, podemos gestionar expectativas sobre el futuro y hacer previsiones en base al progreso del equipo. 

¿Qué ocurre si nuestro Product Owner nos solicita para el siguiente Sprint hacer 9 Items de un tamaño superior a los que hemos hecho en los Sprints anteriores?

Nuestros datos nos dicen que somos capaces de hacer como mínimo 7, el Product Owner podría actuar de “mala fe” y asumir que haremos lo que nos pida ya que entra en nuestro rango.  

Esta técnica usa el control estadístico y sirve para hacer previsiones. Dado que es una previsión, si cambiamos las condiciones de entrada, obtendremos nuevos resultados. Lo que sabemos es que, con las condiciones actuales, somos capaces de hacer entre 7 y 11 PBIs. 

Imaginemos que al finalizar el Sprint 10 solo hemos completado cuatro items (porque eran  más grandes que los anteriores). La situación sería esta:  

	Sprint 6	Sprint 7	Sprint 8	Sprint 9	Sprint 10
nº PBIs finalizados	8	12	10	9	4

Ahora nuestra media es 8,6 ± 2,6 por lo que nuestro rango varía entre 6 y 10,2. ¡Han cambiado nuestras condiciones y por tanto nuestra realidad! Debido a que hemos cambiado las condiciones no hemos cumplido la expectativa, y además, se ha ampliado nuestro rango, lo que es negativo porque nos hace menos predecibles. 

¿Y si tenemos Sprints con PBIs de tamaños muy diferentes? 

Analicemos este ejemplo: 

	Sprint 6	Sprint 7	Sprint 8	Sprint 9	Sprint 10	Sprint 11
nº PBIs finalizados	2	18	3	21	15	2

Nuestra media ahora es 10 ± 8, luego nuestro rango es muy amplio porque varía de 2 a 18. ¡Es muy difícil ser predecible con una situación así! Si tenemos esta situación y nuestro Product Owner quiere ganar en predictibilidad, habrá que dedicar más horas al refinamiento para que los items se parezcan más y podamos mejorar nuestros datos. 

¿Qué ocurre cuando tengo diferentes tipos de items? 

Esta situación también es bastante habitual. Hay equipos que hacen desarrollos e incidencias por lo que mezclarlos en PBIs les cuesta. En este caso, podemos hacer una medición de ambas por separado y gestionar expectativas con ello. Por ejemplo

PBIS\Sprints	Sprint 6	Sprint 7	Sprint 8	Sprint 9	Sprint 10	Sprint 11
nº de features finalizadas	5	8	2	3	1	5
Incidencias Resueltas	3	2	15	12	13	7

En este caso, tenemos dos datos: Nº de Features finalizadas y de incidencias cerradas. Si calculamos sus medas tendremos lo siguiente: 

Nº de Features: 4 ± 2,3

Incidencias: 8,6 ± 5 

Si estamos en la Sprint Review, y un stakeholder nos pregunta: ¿Cuánto haréis en el próximo Sprint? Pues depende, si aparecen muchas incidencias haremos menos y esto es nuestra capacidad de resolución. 

Sin PBIs terminados, no podemos medir

Un punto básico para poder utilizar esta técnica, es el tener PBIs finalizados al acabar el Sprint. Esto es clave, si no hay entrega (aunque no se ponga en producción), no podemos medir. 

Hay equipos que al aplicar esta técnica de medir lo finalizado, descubren que no pueden usarla porque en los Sprints pasados las cosas no estaban del todo terminadas: Estos ítems dijimos que estaban hechos pero les faltaban las pruebas, esto lo estamos terminando ahora o incluso puede que no tengamos claro cuándo se acabaron estas incidencias porque no las cerramos. 

Aquí aparece el primer debate interesante, ¿estamos siendo capaces de terminar cosas en cada Sprint? Si no la estamos terminando, sería importante que tuviéramos un debate en torno a esto ya que si no terminamos las cosas, podemos encontrar un problemón cuando queramos ir a producción y salga a la luz todo el trabajo que hemos ocultado. Es imposible ser predecible con elementos “medio-hechos”.  

Por tanto, si esto ocurre en un equipo, la técnica de medir PBIs ya nos ha aportado información interesante. ¡Mini punto para la técnica! 

La velocidad del equipo

El concepto de “velocidad” está muy extendido en el desarrollo ágil de software. Consiste en medir la cantidad de horas terminadas o de puntos de historia finalizados en un Sprint. La velocidad se suele utilizar para hacer proyecciones para los siguientes Sprints, y de esa manera ser predecibles. Con el tiempo, he perdido la fe en que sea realmente útil. 

Desde mi punto de vista, cuando usamos la velocidad, estamos midiendo estimaciones. El equipo realizar estimaciones en el Sprint Planning, y al acabar el Sprint se mide la cantidad hecha. Estamos creando un medidor basado en estimaciones, lo cual no deja de ser raro ya que las estimaciones son datos que no son científicos. Últimamente, incluso he llegado a afirmar que es un dato “inventado” porque aunque pueden salir de una buena reflexión, en el fondo es un dato que damos antes de hacer el trabajo. 

Y, recordemos, que muchas veces nuestras estimaciones están condicionadas por presiones externas, por ejemplo: “esto tiene que estar en este Sprint”, “no podemos decirle que no al cliente”, “no podemos tardar tanto”, etcétera. Por tanto, utilizar el concepto de velocidad como un parámetro muy fiable de predictibilidad quizás no sea lo más aconsejable según mi experiencia. 

Midiendo software terminado

Uno de los principios del desarrollo ágil de software dice que uses el software terminado como principal medida de progreso. Scrum no habla de velocidad, habla de medir el progreso del equipo. Estoy de acuerdo en que utilizar la velocidad como concepto de medición puede ser válido, pero… ¿Por qué no medir el software que hemos terminado de verdad sin haberlo estimado? Por ejemplo, podríamos medir la cantidad de Product Backlog Items que hemos terminado en cada Sprint. Esta técnica es muy positiva, porque nos permite medir la realidad, es decir, lo que realmente el equipo ha hecho y no lo que hayamos estimado. Todo ello lo convierte en un dato más científico, nos permite ser más predecibles si es lo que realmente queremos. 

Cuando explicamos esta técnica, la primera duda que nos asalta es: ¡Pero hay PBIs más grandes y PBIs más pequeños! Os animo a que hagáis la prueba, coged vuestro Jira (u otro software que uséis) y mirad cuando PBIs habéis finalizado en los últimos Sprints. ¿Os da una información útil? 

Gestionando las expectativas

La gran ventaja de esta técnica, desde mi punto de vista, es que sacamos a la luz un debate con Scrum que es muy complicado y que normalmente aplazamos: ¿Podemos estimar todo antes de empezar a trabajar? Por mucho que nos lo pidan, la realidad es que no sabemos lo que nos llevará un proyecto, una release o terminar un objetivo concreto que nos hayamos marcado. Esta técnica, favorece el tener ese debate, porque al no dar estimaciones evita el prometer algo que no se cumpla. ¿Cuándo estará todo? “No lo se, déjame trabajar un tiempo y midamos nuestra capacidad de entrega”. 

Este debate es duro porque muchas veces no nos dejan trabajar si no aseguramos que llegaremos, pero la realidad es que muchas veces no lo sabemos. Por tanto, esta técnica que se basa en empirismo, y no en medir estimaciones, quizás nos ayude a provocar el cambio en el equipo o en la organización. 

Esta técnica fuerza la idea de que trabajemos con datos reales y no con estimaciones, siempre será más realista y científico. Si quieres hacer una prueba, coge tu equipo si tiene histórico y mira el número de PBIs, seguro que te llevas una sorpresa. 

¿Cuántos PBIs hace tu equipo en los últimos Sprints?