Lo que cabe dentro de un Sprint y lo que no es algo que decide el Equipo de Trabajo. Ellos son quienes mejor pueden calcular hasta dónde pueden llegar en esas semanas que dura el Sprint porque son ellos quienes saben hacer el trabajo. Si se les obliga a aceptar un alcance mínimo para entregar en ese tiempo lo que podríamos estar haciendo es forzarles a que disminuyan la calidad.

En todo proyecto hay siempre tres variables que están ligadas unas a otras. Es el llamado triángulo de hierro. Estas variables son:

• Alcance: El conjunto de funcionalidades o tareas a realizar.
• Coste: El presupuesto o el número de personas empleadas para desarrollar esas funcionalidades.
• Tiempo: Lo que durará el proyecto.

Esto es, si tienes un alcance muy grande tendrás un proyecto muy grande con un coste alto y que durará bastante tiempo. Si por ejemplo, en un proyecto empleas a pocas personas para el mismo alcance tendrás un proyecto que se alargará en el tiempo. Estas variables están interconectadas por lo que si intentas reducir alguna de estas variables manteniendo fijas las otras será la calidad la que se resienta.

Si en cambio, como dice el título de este apartado, alguien externo al proyecto obliga a aceptar un alcance muy elevado en sólo un Sprint, estaremos ampliando el alcance pero dejando inmutables el coste (número de desarrolladores) y el tiempo. Con esto sólo conseguiremos que no lleguemos a cumplir el objetivo del Sprint o que lo hagamos con unos niveles de calidad inaceptables.

No pasará nada en un principio, todo irá aparentemente bien aparte del estrés para poder cumplir el Sprint, pero si la calidad ha bajado esto se terminará notando. Lo hará más adelante en forma de bugs o incidencias que irán apareciendo o de funcionalidades que no están bien pensadas o resultas y que son usables. Funcionalidades poco prácticas o incómodas de usar por los usuarios y que requieren más clics de los necesarios.

Si tenemos un objetivo del Sprint demasiado ambicioso, que ha sido impuesto desde fuera y que es inasumible corremos el riesgo de emplear el doble de trabajo que si lo hubiésemos repartido mejor entre más Sprints. Veamos por qué:

• Los programadores tendrán que hacer multitarea para intentar acometer el alto número de tareas que tienen en ese Sprint. Lamentablemente nunca tenemos en cuenta la bajada de productividad que la multitarea supone.
• Tendremos que dedicar tiempo a la corrección de bugs. No habrá tiempo ni para pensar y todas las tareas se acometerán a toda prisa: No hay tests, no se hacen pruebas, no se revisa la aplicación una vez está todo integrado y no hay tiempo de comprobar que todas las funcionalidades pedidas realmente se han hecho.
• Debido a esto último, muchos bugs aparecerán más tarde, cuando se hagan las pruebas de aceptación por el cliente o cuando se ponga en uso la aplicación. Puede que algunos aparezcan meses o años después de entregado el código ¿Quién se acuerda ahora de por qué el código se hizo así? ¿Para qué eran esas funcionalidades? Se tardará mucho más tiempo en resolver esos bugs que si se hubiesen corregido en el mismo Sprint cuando se tenía aún fresco en la memoria el trabajo hecho. Se sobresaturó el trabajo en el Sprint y no quedó tiempo para hacer buen código y revisarlo después (o a la vez que se escribe). En el futuro pagaremos más por cada bug detectado, es mejor pagar la deuda técnica ahora que hacerlo luego con muchos más intereses.