En este post les traigo parte de la documentación del trabajo fin de grado que realice junto a un compañero, en el que describimos el funcionamiento de la forma de trabajo que utilizamos a la hora de gestionar el proyecto, aunque como verán está metodología está pensada para grupos de trabajo de entre 3 y 8 personas, aunque personalmente no lo aplicaría en grupos de menos de 5 personas.

Que es Scrum

Scrum es un marco de trabajo creado por Ken Schwaber y Jeff Sutherland a principios de los noventa, por aquel entonces ellos ya tenían experiencia como desarrolladores, directores de TI y compañías de software.

Scrum está pensado para gestionar proyectos complejos de manera incremental e iterativa, permitiendo obtener, en cada iteración, un producto entregable que irá adaptándose a factores que produzcan cambios en los requisitos del producto a desarrollar. Está encuadrada dentro de las metodologías ágiles, y aunque en principio nació enfocada al sector TIC, es aplicable en cualquier proyecto en el que exista una lista de requisitos cambiantes, bloques de trabajo y un equipo de desarrollo asignado a dicha tarea. En la propia guía de Scrum se define como algo:

Ligero
Fácil de entender
Extremadamente difícil de llegar a dominar.

El nombre de esta metodología viene de la similitud con la formación que se utiliza para reanudar el juego en un partido de rugby. En una scrum o melé el equipo debe estar perfectamente coordinado, si un miembro del equipo se cae, el equipo completo sufre las consecuencias.

Formación Scrum.

En que se basa Scrum

Scrum se basa en la teoría de control de procesos empírica que, en pocas palabras, asegura que la experiencia es la clave del éxito. Un control de procesos empírico aumenta la predictibilidad del producto y proporciona un mejor control del riesgo. Seguir una gestión empírica viene de la mano de tres factores que constituyen los pilares de Scrum: inspección, adaptabilidad y transparencia.

La inspección tras cada iteración persigue detectar los elementos que se deben adaptar. Si se detecta algún desajuste frente a los objetivos reales, es posible adaptar el proyecto al final de cada iteración. Esto permite que el resultado final esté más cerca del esperado, pues es más fácil ir adaptando iterativamente, que intentar ajustar el proyecto una vez finalizado. Para que el proceso de inspección tenga sentido, es necesario que haya plena transparencia entre los miembros del Equipo. La situación del proyecto debe ser conocida por todos, en caso contrario podríamos dejar de lado alguna característica del producto que debe ser reajustada. Es importante que los miembros del equipo tengan un lenguaje común y una misma definición de ‘producto terminado’.

La teoría de control de procesos, el seguir un modelo iterativo y buscar adaptabilidad, transparencia y una inspección regular del producto constituyen sin duda la base para que el producto cumpla los requisitos que se marcaron. Pero Scrum persigue algo más. Scrum persigue la originalidad, flexibilidad, la inspiración, la motivación e innovación. Estos elementos hacen que el equipo trabaje más cómodamente y permite a su vez la autosuficiencia del conjunto de trabajadores. Al no tener que depender de personas ajenas al proyecto, es más fácil la colaboración y conlleva mejores resultados.

Cada iteración del proceso se denomina Sprint. Un Sprint es un periodo de tiempo, normalmente de entre dos semanas y un mes, en el que se desarrollan unas tareas especificadas previamente. Cada iteración, o Sprint, puede variar, aunque una vez definida la duración del Sprint a iniciar no puede ser alargado ni acortado para mantener la regularidad que busca Scrum, y que es clave en su éxito como marco de trabajo. Scrum se comentará con detalle más adelante, pero es aconsejable tener una idea del concepto para comprender los conceptos explicados antes que él.

Componentes de Scrum

Scrum está formado por algunos componentes que caracterizan este marco de trabajo. Básicamente, los conceptos más singulares de Scrum son artefactos, eventos y el Equipo Scrum.

Aunque el equipo sea parte esencial de cualquier grupo de trabajo, la división y los roles que asigna Scrum son característicos de la metodología. Cualquier orden a la hora de explicarlos tiene inconvenientes, pues están estrechamente relacionados, mediantes los conceptos que constituyen la base de Scrum, y conforme uno de ellos es explicado aparecen términos propios de alguno de los otros.

Artefactos

Los artefactos de Scrum son la Lista de Producto (Product Backlog), Lista de Pendientes (Sprint Backlog) y el gráfico Burndown. Las listas representan trabajo y son compartidas por los miembros del equipo para aumentar la transparencia. Estas listas se modifican iterativamente, facilitando la adaptación del producto. En cambio el gráfico Burndown nos permite ver la evolución del Sprint y se modifica durante el Sprint. Estos artefactos contienen información clave y es necesario que todos tengan acceso a ella, aunque no todos tienen la libertad de modificarlos.

Lista de Producto

La Lista de Producto es un documento que contiene las funcionalidades, requisitos, y necesidades del producto. Estos elementos se ordenan dentro de la propia lista de mayor a menor importancia en base a algún criterio. El responsable de esta lista es el Dueño de Producto.

La Lista de Producto no estará completa hasta el final del proyecto. Mientras exista el producto en cuestión, y su gestión (desarrollo y mantenimiento) se haga dentro de Scrum, tendrá una lista asociada. La primera elaboración de está lista generalmente contiene los requisitos conocidos y que mejor se entienden, pero, a la vez que el producto en sí, el entorno y las necesidades cambian, la lista aumenta. El propio mercado proporciona retroalimentación y el Equipo Scrum detecta nuevas exigencias a las que dar solución. El entorno es algo cambiante, la introducción de una nueva ley, la entrada en el mercado de un producto, o el paso de una moda a otra, por ejemplo, son factores que condicionan la lista, y en cada iteración la lista de producto debe adaptarse a todo ello para conseguir un producto final acorde a las necesidades que pretende resolver.

Cada elemento de la Lista de Producto tiene unos atributos concretos: descripción, orden, estimación y valor. En torno a estos se realiza el reordenado. Esto se hace mediante un proceso que en Scrum comúnmente se denomina “refinamiento”. El refinamiento es un proceso que se realiza en cada Sprint. El Equipo Scrum concreta cuando se realizará, y consiste en añadir detalles, y valorar cuantitativamente los elementos para priorizarlos. Generalmente, se utiliza el ROI para dar prioridad a cada requisito de la lista. A mayor ROI (cuanto más devuelva la inversión), mayor prioridad dentro de la lista.

Aunque es conveniente que los miembros del Equipo Scrum se reúnan y debatan sobre el valor que hay que asignar, y la importancia de cada elemento, el verdadero propietario y responsable de la lista es el Dueño de Producto, y este tiene total libertad para alterarla.

Lista de Pendientes del Sprint

La Lista Pendientes del Sprint está formada por aquellos elementos de la Lista de Producto que han sido seleccionados para ser elaborados. Por tanto, existe una Lista de Pendientes por cada iteración del proceso. Aparte de los requisitos, la lista está constituida por un plan que regula cómo se llevará a cabo el objetivo del sprint.

Visto desde otro punto de vista, este documento es una predicción del Equipo de Desarrollo, del trabajo que es capaz de desarrollar en el periodo de tiempo estipulado para el Sprint. También puede ser interpretado como un resumen del trabajo que el Equipo identifica como necesario para cumplir las metas impuestas por ellos mismo, pues, a diferencia de la Lista de Productos, esta lista pertenece al Equipo de Desarrollo, que se auto organiza libremente y marcan las pautas a seguir en cada tramo temporal.

En cuanto al contenido de la Lista de Pendientes del Sprint, cabe destacar que es más detallada, pues en realidad es un sublista de la lista anterior. El nivel de detalle es tal, que cada punto podría corresponder al trabajo diario dentro del Sprint, con el fin de, entre todos los miembros del Equipo de Desarrollo, ser capaces de analizar el progreso diario. Pero, como no podía ser de otra forma en Scrum, la lista es dinámica. A la vez que se profundiza en uno de los elementos pendientes, se conoce mejor los pasos a seguir para lograr el objetivo y esto permite acortar o alargar la lista dentro de las limitaciones de tiempo inicial. También pueden influir factores externos tal y como pasaba con la Lista de Productos.

Grafico burndown

El gráfico burndown es una herramienta que proporciona información sobre como avanza el proyecto, de lo retrasado o lo adelantado que este va. Esta información ayuda a planificar mejor el próximo Sprint. El eje X de un burndown representa el tiempo en días y el eje Y representa las unidades de trabajo, en el gráfico se representa la evolución del proyecto estimada y lo que realmente está pasando.

Ejemplo de Burndown Chart

La imagen anterior representa el burndown de un Sprint, en ella se puede observar (en verde) la estimación que se realizó y lo que realmente ha sucedido (en rojo). Este gráfico indica que algo falló en la planificación del Sprint, quizás se subestimó la capacidad del Equipo de Desarrollo para alguna de las tareas que se realizaron durante este Sprint y se debería tener en cuenta para la planificación del siguiente Sprint o incluso cancelar el proyecto. Otra posibilidad es que alguna o varias herramientas de desarrollo no hayan estado disponible durante el día 22 (se puede observar que apenas se avanzó).

En cualquier caso este gráfico muestra que ha habido algún problema que se debe analizar y reparar para los próximos Sprints.

Equipo Scrum

Los artefactos dentro de Scrum potencian la adaptabilidad y por tanto la productividad, sin embargo, esto no sería posible sin un equipo que lo gestionase. Dentro de este marco de trabajo se distinguen tres partes diferentes que forman el grupo de trabajo: Dueño de Producto, Equipo de Desarrollo y Scrum Master. La suma de los tres desemboca en el Equipo Scrum, un equipo auto organizado y multifuncional. El propio equipo gestiona el trabajo y no necesita apoyo externo ni para la gestión, ni para cumplir los objetivos. Es autosuficiente. Este esquema de trabajo aumenta la flexibilidad, la creatividad y la productividad, que, como ya se explicó, son objetivos primordiales de Scrum. El equipo completo comparte un objetivo común, algo estrictamente necesario para lograr transparencia.

Dueño de Producto

El Dueño de Producto es una persona física, nunca un equipo o comité, cuya función principal es la gestión de la Lista de Producto. Todo elemento que aparezca en esta lista, o cualquier decisión tomada sobre ella, es únicamente responsabilidad suya. Por tanto se encarga de ordenarla, añadir o eliminar requisitos, asegurarse de que toda persona tiene acceso a ella, etc. Es un miembro activo del equipo y como tal debe estar presente en todos los eventos programados.

Dentro de sus obligaciones está la de comunicarse con el cliente. De hecho es el encargado de reunirse con él, de transmitir sus exigencias al resto del equipo, y de transformar sus deseos en tareas y funcionalidades a implementar. El Dueño de Producto debe saber expresar los elementos de manera clara y transparente. De esta manera se asegura que el Equipo de Desarrollo entiende los requisitos al nivel necesario para una correcta implementación ya que, aparte de la gestión de la lista, es responsable del buen uso y entendimiento de esta.

La organización y el Equipo Scrum en general deben respetar sus decisiones, y no pueden interferir en el contenido de la lista de otra manera que dando su opinión al Dueño. Si este decide tenerlo en cuenta, la sugerencia pasará a formar parte de la Lista de Producto, pero tiene total libertad para no hacerlo. También existe la posibilidad de que el Dueño de Producto otorgue los privilegios sobre la Lista al Equipo Desarrollador, aunque no lo exime de la responsabilidad de esta y será él quien responda ante cualquier inconveniente o contratiempo proveniente de una mala gestión por parte del Equipo. De cualquier manera, delegue la responsabilidad en el Equipo o no, en su papel está gran parte de la responsabilidad del éxito, y es fácil sentirse abrumado por esta situación. Por ello es importante que el resto del equipo respete sus decisiones y evite complicar su trabajo.

El Dueño de Producto influye en el trabajo a desarrollar en cada Sprint, hasta tal punto que selecciona el mismo las tareas de la Lista de Producto que deben completarse durante ese periodo, aunque de ninguna manera puede influir en la manera de desarrollarla. Al final de cada Sprint tiene la posibilidad, y a su vez el deber, de decidir si el trabajo desarrollado es aceptable o desechable.

Scrum Master

El Scrum Master es un líder al servicio del equipo Scrum. En la web se pueden encontrar múltiples definiciones o ejemplos para ayudar a entender que función tiene esta persona. Algunos lo consideran el entrenador del equipo, pues es el encargado de sacar el máximo provecho de los integrantes y de conseguir que lo hagan lo mejor posible dentro de sus posibilidades. Otros lo catalogan como el protector debido a que entre sus funciones se encuentra la de asegurarse de que el equipo no es sobrecargado y se fijan objetivos dentro de sus posibilidades. También es usual encontrar comparaciones con un entrenador personal, cuyo objetivo es motivar al equipo y a la vez asegurarse de que no evita hacer tareas duras siempre que estén capacitados para ella.

La persona que desempeña este rol debe asegurarse de que Scrum es entendido y aplicado. En definitiva esa es su misión, pero la manera de que esto se lleve a cabo es compleja por ello surgen las diferentes comparaciones. Como consecuencia, es el encargado de organizar los eventos necesarios para llevar Scrum a cabo, y a su vez facilitar un día y una hora en la que todos puedan asistir.

Para enfocar el proyecto en el marco de trabajo Scrum, debe estar en contacto con toda persona, interna o externa, relacionado con el trabajo. Es el encargado de ayudar a entender que tipo de interacciones con el Equipo de Desarrollo son de utilidad y cuales no. También debe asegurarse de que el Dueño de Producto sabe ordenar la Lista de Producto, que no quiere decir que interfiera en su ordenación, pero debe aportar técnicas eficientes para esta tarea. Guía al Equipo de Desarrollo a ser multifuncional y autoorganizado, y les ayuda a crear productos de alto valor, sacando el máximo provecho a sus habilidades. Para mantener la productividad del equipo en los niveles más altos posible los aísla de interrupciones y de elementos que afecten a su rendimiento.

Su aportación a la organización consiste en liderar y guiar la adopción de Scrum, algo que no es nada fácil y más si no se tiene experiencia con esta metodología de trabajo. Debe asesorar a toda persona que lo necesite y ayudarle a entender el porqué de usar Scrum y el cómo, haciéndole entender las ventajas que supone frente a otros sistemas. Por tanto es responsable de planificar la implementación. También debe ser él quien motive un cambio de dirección o proponer un reajuste si con ello se incrementará la productividad del Equipo Scrum.

Respecto a la autoridad del Scrum Master, se puede resumir en que no tiene responsabilidad sobre los miembros del equipo pero si sobre el proyecto. No podría tomar decisiones como despedir a alguien pero si tiene autoridad para establecer la duración de los Sprint por ejemplo.

Equipo de Desarrollo

El Equipo de Desarrollo está formado por los profesionales que crean el producto. Sólo ellos intervienen de manera directa en este proceso, pues hay personas involucradas de manera indirecta marcando objetivos, pautas y requisitos, pero es el Equipo de Desarrollo el encargado de transformar las ideas en algo material. Deben disponer de las habilidades necesarias para realizar las tareas propias de este trabajo: análisis, desarrollo, pruebas, diseño, documentación… etc.

Más importante incluso que las habilidades es la organización del conjunto, pues es la clave para la agilidad que persigue Scrum por definición. El equipo trabaja de manera independiente y auto organizada, algo que lleva a explotar la creatividad de sus integrantes, además su estructura está pensada para optimizar la eficiencia y productividad de los desarrolladores. Ni si quiera el Scrum Master puede entrar en la decisión de cómo se van a convertir los elementos de la Lista de Producto en un producto tangible y con valor para el cliente. Dentro del equipo no hay distinciones en cuanto a roles, ni jerarquía entre ellos. Todos están al mismo nivel y no existen sub-equipos y, aunque cada uno tenga una habilidad concreta o una función particular dentro del grupo, la responsabilidad del éxito del trabajo recae en todos por igual.

En cuanto al tamaño del equipo, lo ideal es entre 3 y 8 personas, aunque esto es ambiguo y no existe una patrón estricto. El número de personas que componen el grupo se estima en relación al tipo de proyecto, la cantidad y complejidad del trabajo y el plazo de entrega. Se suele decir que el grupo debe ser lo suficientemente pequeño como para ser ágil, y a la vez lo suficientemente grande como para completar una cantidad de trabajo significativa en cada Sprint, aunque, por norma general, se establece que menos de tres miembros reduce la interacción y las ganancias en productividad. También hay que considerar que un grupo demasiado pequeño puede presentar carencias a la hora de afrontar un objetivo debido a la falta de profesionales especializados en la materia en cuestión. Es lógico pensar que un equipo demasiado numeroso es complicado de gestionar y frenaría la toma de decisiones entre ellos, incrementaría los tiempos de sincronización y, como consecuencia, reduciría la agilidad del equipo. Como comentario final, es importante recalcar que para contabilizar los miembros del Equipo no se deben tener en cuenta al Scrum Master y al Dueño de Producto a no ser que intervengan a la hora de decidir la Lista de Pendientes del Sprint.

Otros roles

Los roles auxiliares en el Equipos Scrum son aquellos que no participan de manera activa en el proceso Scrum, pero no por ellos hay que dejar de tenerlos en cuenta. Para que el proceso resulte ágil y efectivo es importante tener en cuenta durante el proceso a clientes, expertos y usuarios finales del producto. La retroalimentación que aporta este subconjunto es vital para alcanzar la adaptabilidad y aumentar el valor final de lo que se está produciendo.

Los roles en Scrum.

Eventos

En el marco de trabajo Scrum existen eventos definidos que buscan crear regularidad y una rutina de trabajo eficaz en los miembros del proyecto. El hecho de reuniones predefinidas busca a su vez reuniones improvisadas o sin planificar que son mucho menos eficientes y productivas.

Se define un evento como un bloque de tiempo, de duración máxima y fija. Cada uno de ellos es una oportunidad para la inspección del producto y el reajuste de algún elemento que se desvíe de lo estrictamente deseado por el cliente. Por el contrario, la ausencia de alguno de ellos, reduce la transparencia y significa perder una oportunidad para llevar el producto por el camino adecuado.

Dentro de los eventos, se diferencian dos tipos según el objetivo de cada uno de ellos. Se denominan Sprints y Reuniones.

Sprint

El Sprint es un bloque de tiempo de entre dos semanas y un mes en el que se desarrolla una parte del producto, algunas personas lo consideran un proyecto dentro del propio proyecto. La duración de un Sprint no debe exceder el mes pues la complejidad y el riesgo de desajuste incrementa.Tampoco se recomienda una duración menor a las dos semanas pues el coste aumenta considerablemente debido a las reuniones que se realizan durante el Sprint.

Para cada Sprint se realiza una Lista de Pendientes del Sprint, que contendrá aquellos elementos de la Lista de Productos escogidos para completar durante la iteración. El contenido de esta puede ser renegociado con el Dueño de Producto a medida que se profundiza y se obtienen conocimientos sobre los temas que se deben abordar. Aunque exista cierta flexibilidad en cuanto a la Lista de Pendientes, no se permite realizar cambios que involucren disminución de la calidad del producto, ni que cambien el Objetivo del Sprint.

Las Reuniones predefinidas en Scrum tienen lugar durante los Sprint. Por definición esto no podría ser de otra forma, pues un Sprint empieza seguidamente acaba el anterior, por tanto el ciclo de desarrollo del producto es una sucesión de Sprints y cualquier evento debe situarse dentro de alguno de ellos.

Un Sprint puede ser cancelado, algo que raramente ocurre. El Dueño de Producto es la única persona que tiene poder para hacer esto, aunque para ello puede ser influenciado por el propio equipo, el Scrum Master u otra persona relacionada con el proyecto. La única razón por la que se debe cancelar un Sprint es que el Objetivo marcado carezca de sentido. Esto ocurre si las condiciones de mercado cambian, se produce algún avance tecnológico, la entrada de alguna nueva ley… etc y el Objetivo queda obsoleto.

Reuniones

En Scrum existen un conjunto de reuniones predefinidas que deben respetarse dentro de cada Sprint. En concreto Scrum define cuatro tipos para asegurar que el equipo sea regular y constante.

Planificación del Sprint

Este evento está programado al inicio de cada Sprint y tiene como fin establecer el trabajo que debe completarse durante esa iteración. Si el Sprint tiene programado un mes de duración, este evento debe durar aproximadamente ocho horas pero nunca más. Si el Sprint es más corto la duración del evento disminuye proporcionalmente.

La reunión debe enfocarse a responder dos cuestiones claves: qué se va a terminar y cómo se conseguirá completar el trabajo. Como resultado se produce la Lista de Pendientes del Sprint que contiene elementos seleccionados más el plan para abordar el objetivo.

Para responder a la primera cuestión, hay que aclarar que funcionalidades se van a desarrollar. Esta es una decisión conjunta entre el Dueño de Producto, que decide qué elementos deberían empezar a producirse, y el Equipo de Desarrollo, que selecciona el número de ellos que piensan que tienen la capacidad de afrontar. A la hora de tomar esta decisión influyen ciertos factores como el resultado del anterior Incremento, la capacidad del Equipo de Desarrollo en base a resultados anteriores, el rendimiento mostrado hasta entonces… etc.

En cuanto a la segunda cuestión, la meta a alcanzar es un plan que describa de forma detallada cómo se procederá con cada uno de los puntos que componen la Lista de Pendientes del Sprint. El nivel de detalle es tal que habría que descomponer cada requisito en unidades de trabajo cuyo tiempo estimado para completarlos sea de 24 horas aproximadamente. Básicamente consiste en describir el día a día que les espera mientras desarrollan el proyecto.

Al final de cada Reunión el Equipo de Desarrolladores debe ser capaz de explicar y convencer al Scrum Master y al Dueño de Producto de cómo van a gestionar las tareas que se le han asignado

Scrum diario

Durante el Sprint, el Equipo de Desarrollo se reúne a diario durante no más de 15 minutos para replantear el trabajo a realizar durante ese día, siempre tratando de alcanzar los objetivos marcados.

Este evento está pensado para que los desarrolladores pongan en común su experiencia hasta entonces en el trabajo que están abordando. Deben comentar lo que se hizo en las últimas 24 horas a favor del proyecto y lo que se planea hacer en las próximas para contribuir a él.

Revisión del Sprint

En la revisión del Sprint se reúne el Equipo Scrum durante no más de 4 horas para juntos revisar qué es lo que ha pasado durante el Sprint, esto incluye el que se ha realizado, si está o no completo, si es o no usable. Las partes que no se puedan añadir como una funcionalidad más volverán a la Lista de Producto como “aún por realizar”.

Pueden surgir nuevas oportunidades o retos durante la revisión del Sprint que se verán representadas en nuevas funcionalidades o modificación de alguna de las existentes.

La revisión del Sprint puede concluir con alguna o varias de las siguientes decisiones:

Comenzar a utilizar las nuevas funcionalidades.
Decidir qué hacer durante el siguiente Sprint y prepararse para ello.
Cancelar el proyecto.

En cualquier caso el riesgo del proyecto está controlado en cada Sprints.

Retrospectiva del Sprint

Si durante la revisión del Sprint se decidió continuar, todos los miembros del Equipo Scrum se reúnen durante 4 horas como máximo para formular mejoras en el trabajo, lo que incluye los siguientes puntos:

Si los miembros del equipo han trabajado bien o no y por qué.
Si se hizo más o menos de lo esperado y por qué.
Si el equipo tiene las habilidades y facilidades para realizar el trabajo.
Si los desarrolladores entendieron o no los requisitos y por qué.
Si el equipo es capaz de completar el Sprint con los objetivos marcados, y si no lo es, por qué.
Qué se puede mejorar o abandonar en el próximo Sprint y por qué.
Qué piensa el equipo del uso de Scrum.

Lo siguiente es identificar las cosas que se deben hacer de forma diferente en el próximo Sprint para incrementar la creatividad, efectividad y productividad. En general que se puede mejorar en el Equipo Scrum.

Descripción gráfica de los eventos de Scrum

En el gráfico se aprecian todos los eventos de Scrum que han sido descritos a lo largo del capítulo. Lo que a simple vista se aprecia es un Sprint, que se genera a partir de la Lista de Producto. Los elementos que sigan permaneciendo en esa Lista provocan una reunión al principio del Sprint para determinar los objetivos, es lo que aparece como Sprint Backlog dentro del gráfico. Entre 2 y 4 semanas, el Equipo de Desarrollo elabora el producto, manteniendo reuniones diarias (Daily Sprint meeting) para comentar los progresos. Al final del Sprint, el Equipo completo vuelve a reunirse para determinar qué elementos van a ser publicados, que ha ido como se esperaba y que inconvenientes o problemas ha habido para evitarlos en la próxima iteración. Después de esto, si todo ha ido bien, se obtiene una nueva versión del producto.

Conclusiones y aclaraciones

Scrum es una forma de gestionar proyectos complejos de cualquier tipo, no solo software, para proyectos simples suele ser más eficaz la metodología tradicional en la que se planea el proyecto completo al principio del mismo.

Está basado en la experiencia obtenida previamente y durante su uso por lo tanto no garantiza el éxito del proyecto pero si disminuye el riesgo en el que se incurre al tener la posibilidad de reencaminar o de cancelar el proyecto al final de cada Sprint.