Estimaciones y planes en SCRUM

El manifiesto ágil tiene entre sus principios dar “Respuesta ante el cambio sobre seguir un plan”, lo que quiere decir que por encima el plan está la flexibilidad para realizar cambios y adaptarse a las exigencias dinámicas del negocio, del mercado, de la tecnología, etc.

En Scrum la planificación se realiza al inicio de cada Sprint, sobre la base de un Product Backlog  priorizado, que va evolucionando a lo largo del proyecto. El Sprint Planning se focaliza en establecer qué y cuánto trabajo incluir en el Sprint para lograr la meta acordada por el equipo, incluyendo cómo lograrlo.

El marco de trabajo iterativo de Scrum, comienza en el Sprint 1, con la existencia de un Product Backlog preliminar, ya que sus autores no referencian un Sprint 0. Independientemente de esto, antes de iterar para obtener los incrementos del producto, es necesaria una fase preliminar, que algunos llaman “Incepción“ (Inception), para conformar el equipo de Scrum, comprender una visión general del problema y de la solución de alto nivel compartida por todos los miembros del equipo, identificar e involucrar a los stakeholders, asegurar los recursos financieros, técnicos y logísticos necesarios, configurar los ambientes, generar el Product Backlog, desarrollar las historias de usuario prioritarias, y generar un Plan General de Entregas de alto nivel (Release Plan).

En los proyectos complejos, al comienzo poco se sabe sobre el producto y el desempeño del equipo, por lo que las estimaciones están sujetas a una gran incertidumbre, sobretodo en proyectos de software, donde el contexto es volátil, la tecnología cambia con rapidez, así como la dinámica del negocio y del mercado.

Las estimaciones en contextos inciertos hacen poco probable el cumplimiento de planes, a medida que avanza el proyecto aumenta el conocimiento y las estimaciones podrán ser más precisas. Las estimaciones iniciales son aproximaciones basadas en supuestos con incertidumbre que utilizan valores con orden de magnitud probable. Por ejemplo las Épicas (agrupaciones de historias de usuario de alto nivel), podrían estimarse con letras (S pequeña, M medio, L grande, XL muy grande), para las historias de usuario se suele utilizar una estimación relativa que asigna puntos basados en la secuencia de Fibonacci (0, 1, 2, 3, 5, 8, 13, …), así una historia de 2 puntos requiere el doble de esfuerzo de una de 1 punto, y una de 3 puntos el triple.

Una forma de asignar el puntaje a la historia, es con la técnica del Póker Planning, donde cada miembro del equipo recibe un lote de cartas con los valores de la serie de Fibonacci, el Product Owner explica la historia de usuario, cada persona selecciona una carta y todos a la vez presentan su selección. Las personas con los puntos más bajos y más altos explican por qué del puntaje asignado, el equipo discute y puede repetirse la jugada hasta llegar a un consenso.

Por otra parte, cada equipo de desarrollo tiene una Velocidad, que representa la cantidad de trabajo realizada en un Sprint, por ejemplo, una velocidad de 15 puntos indica que el equipo realiza 15 puntos de trabajo en cada Sprint. Para los primeros Sprint el equipo asigna una velocidad estimada, que se refina luego del tercero o cuarto Sprint con la velocidad real que ha tenido el equipo en estos primeros Sprint.

Sobre métricas y estrategias de seguimiento hablaremos en la próxima entrega.

Gracias por leerme.-

Las Historias de Usuario en SCRUM

Uno de los principales insumos en el desarrollo de productos son las especificaciones funcionales, donde clientes y usuarios describen a los desarrolladores lo que desean del producto. Cuando éstas son escritas, están sujetas a interpretaciones, malos entendidos y resultados que no satisfacen las expectativas. La comunicación humana se enriquece con las conversaciones, ya que el tono de voz y los gestos comunican más que las palabras, por esta razón en SCRUM se incorpora el concepto de Historias de Usuario (User Story), especificaciones compuestas de una pequeña ficha (card) que esquematiza la redacción del requisito, conversaciones entre el Product Owner y el Equipo de Desarrollo y Criterios de aceptación que especifican las condiciones que debe cumplir dicho requisito (3C: Card Conversaciones Criterios).

La redacción de la historia de usuario describe para el rol involucrado, la funcionalidad requerida y el objetivo de la misma en una frase corta, la cual tiene la forma: Como Quiero Para . Por ejemplo: Como Estudiante quiero consultar mis programas en línea para ahorrar tiempo y dinero.

Los criterios de aceptación deben describir un contexto, un evento y la respuesta o consecuencia esperada. La forma más utilizada para describir los criterios de aceptación es: Dado Cuando Entonces . Aquí un ejemplo: Dado un estudiante autenticado en el sistema académico Cuando accede a la opción de programas en línea Entonces se le redirige automáticamente a la lista de programas de la carrera en la cual está inscrito.

Una buena historia de usuario debe cumplir un conjunto de características, conocidas con el acrónimo INVEST: Independiente (poderse desarrollar sin depender de otra), Negociable (entre el Product Owner y el Equipo de Desarrollo), Valiosa (para los clientes), Pequeña (desarrollable en poco tiempo) y Testeable (con los criterios de aceptación bien definidos para ser probada). Adicionalmente, el equipo de desarrollo acuerda con el Product Owner las condiciones que debe cumplir una historia de usuario para estar lista (Definition of Ready) y poder ser incluida en el Sprint Backlog, por ejemplo debe cumplir los requisitos INVEST, estar redactada de la forma    Como-Quiero-Para, y detallados los Criterios de aceptación de la forma Dado-Cuando-Entonces.

Finalmente, el equipo de SCRUM también debe acordar las condiciones que debe cumplir la historia de usuario para darla por terminada (Definition of Done) y disponer de un producto entregable y usable, por ejemplo todos los criterios de aceptación funcionan correctamente, todos los archivos fuentes están en el repositorio adecuado, entre otros.

En el Product Backlog, pueden registrarse historias de usuario generales, de gran complejidad, que cuando pasan a ser prioritarias, se descomponen en más pequeñas. A estas historias se les conoce como épicas (epic) y la estimación general que se puede utilizar es XS (muy pequeña), S (pequeña), M (medio), L (grande) y XL (muy grande). Para las historias de usuario que van al Sprint Backlog, la estimación de esfuerzo puede utilizar la secuencia de Fibonacci, técnica sobre la cual les hablaré en el próximo artículo.

Gracias por leerme.

Rituales o Eventos de SCRUM

La dinámica de SCRUM se implementa a través de ceremonias o rituales caracterizadas por eventos de duración predeterminada (Time-box), que le dan al desarrollo un ritmo sostenible, con entregas frecuentes de software valioso y oportunidades frecuentes de inspección, adaptación y transparencia. Cada evento en forma de reunión, tiene un objetivo con una duración máxima que depende del tamaño del Sprint, que se puede acortar si se logra antes dicho objetivo. Solo el Sprint tiene una duración fija. El SCRUM Master se asegura que el equipo comprende, realiza y logra el objetivo de cada evento en el tiempo especificado.

Los rituales de SCRUM mejoran la comunicación entre los miembros del equipo y con ello su nivel de conocimiento, asimismo, promueven el cumplimiento del objetivo del Sprint ya que facilita procesos ágiles de aprendizaje, toma de decisiones y solución de problemas.

El Sprint es el núcleo de SCRUM en el que se desarrolla y entrega un incremento del producto. Tiene una duración entre 1 y 4 semanas, siendo 2 o 3 semanas la duración más común. Considerando la complejidad del desarrollo, la volatilidad del negocio, la tecnología y la madurez del equipo,  el equipo SCRUM decide el tamaño fijo que tendrán los Sprint. Si la meta fijada para el Sprint se logra antes, o no se pudiese alcanzar, el equipo podría ajustar el alcance del Sprint, pero no se modifica su tiempo de duración. Cada Sprint contiene los demás eventos.

Los eventos de SCRUM incluyen: la reunión de Planificación del Sprint (Sprint Planning Meeting), las reuniones Diarias (Daily Scrums), la Revisión del Sprint (Sprint Review) y la reunión de Retrospectiva (Sprint Retrospective). Adicionalmente, el equipo puede realizar 1 o 2 reuniones de Refinamiento del Product Backlog (Product Backlog Refinement o Grooming) para colaborar con el Product Owner en el mantenimiento y detalle del Product Backlog.

En el Sprint Planning todo el equipo colabora para seleccionar los PBI (Product Backlog Item) priorizados que se desarrollarán durante el Sprint y fijar la meta del mismo. Los PBI deben ser lo más independientes posible, los más dependientes podrían agruparse en uno. 

El Sprint Planning dura máximo 8 horas en Sprint de un mes. Se divide en 2 partes, la primera donde el Product Owner explica los detalles funcionales de los PBI prioritarios, responde las preguntas del equipo de desarrollo y junto al equipo se seleccionan los PBI a desarrollar y la meta del Sprint. En la segunda parte, se suele retirar el Product Owner, y el equipo acompañado del Scrum Master, establece cómo se realizará el trabajo, define un diseño general, identifica tareas técnicas y llega a acuerdos de alto nivel que se detallarán durante el desarrollo del Sprint. El resultado del Sprint Planning es el Sprint Backlog que se coloca en una pizarra de tareas (Taskboard), física o digital, visible para todos.

El Equipo de Desarrollo es quien realiza la estimación de esfuerzos. Puede utilizar la técnica de Planning Poker para realizar una estimación inicial por consenso donde cada miembro  comparte su opinión y estimación. También se suele utilizar información sobre la velocidad y capacidad productiva del equipo obtenida en Sprint anteriores. En SCRUM la estimación es un pronóstico  potencial que se basa en el compromiso que adquiere el equipo para lograr el objetivo del Sprint.

Las reuniones Diarias (Daily Scrums), son reuniones cortas que el equipo de desarrollo debe realizar todos los días, de solo 15 minutos, para asegurar la comunicación, coordinación de actividades y la colaboración entre los miembros del equipo. Los Daily permiten al equipo evaluar actividades, compartir dificultades y tomar decisiones de planificación, en tiempo real, promoviendo los pilares de Scrum de Transparencia, Inspección y Adaptación.

Se realizan siempre a la misma hora y en el mismo lugar. Es conducida por el Equipo de Desarrollo, el Scrum Master puede facilitar la dinámica para garantizar se mantenga la reunión dentro de su propósito y duración. Puede asistir el Product Owner y otros involucrados en calidad de observadores, sin embargo, no deben intervenir en la discusión, ni solicitar justificación del progreso o explicaciones a los problemas. No se debe usar para dar Status a ninguno de los roles.

Cada miembro del equipo de desarrollo responde a 3 preguntas: 1. ¿Qué hice desde el último daily? 2. ¿En qué voy a estar trabajando?, y 3. ¿Qué problema o impedimento tengo para alcanzar el objetivo?.  Los problemas no se resuelven en el daily, sino en revisiones posteriores. El Scrum Master asegura que estas revisiones se realicen a la brevedad y los problemas sean resueltos con prontitud.

Al finalizar el Sprint se realiza una reunión de revisión (Sprint Review), donde el equipo de desarrollo presenta al Product Owner e involucrados, el resultado funcional del incremento. Estos lo aceptan o rechazan dando retroalimentación al equipo de desarrollo. Si el elemento (PBI) es rechazado, reingresa al Product Backlog con alta prioridad, para ser tomado en el próximo Sprint; a menos que el Product Owner cambie la prioridad del elemento. El Scrum Master facilita la reunión, asegurando que cumpla su objetivo dentro del tiempo estimado, que en Sprint de un mes, es máximo de 4 horas.

Luego del Sprint Review y antes del Sprint Planning del próximo Sprint, se realiza una reunión de Retrospectiva (Sprint Retrospective), que permite al equipo reflexionar sobre cómo se realizó el trabajo, identificar y analizar los acontecimientos positivos y negativos para el cumplimiento del objetivo del Sprint. El resultado principal de esta reunión es lograr en consenso acciones de mejora para ser implementadas en el próximo Sprint, asegurando con ello la mejora continua y la implementación de prácticas emergentes en los procesos del equipo de desarrollo. Estas acciones y su impacto se revisan en la próxima reunión de retrospectiva. Cómo en los otros eventos, el Scrum Master facilita la reunión, asegurando que cumpla su objetivo dentro del tiempo estimado, que en Sprint de un mes, es máximo de 3 horas.

Por último, a fin de mantener el Product Backlog priorizado y los PBI próximos a desarrollarse detallados, el Product Owner y el Equipo de desarrollo suelen ejecutar 1 o 2 reuniones de refinamiento (Product Backlog Refinement o Grooming) en cada Sprint, donde se añaden, retiran, detallan y estiman los elementos del Product Backlog del siguiente Sprint. Es una reunión corta, generalmente de 1 hora, conducida por el Product Owner, con el apoyo del Scrum Master quien asegura que la reunión cumpla su objetivo en el tiempo establecido.

Un aspecto de gran relevancia para el éxito de cualquier proyecto de desarrollo de software, es la forma en que se describen los requerimientos o requisitos del producto en el Product Backlog, siendo la técnica más utilizada las historias de usuario. Sobre este tema escribiré en el próximo artículo.

Gracias por leerme.-

Los 3 artefactos de SCRUM

Al aplicar SCRUM se utilizan 3 herramientas o artefactos: el Product Backlog, donde se registran los elementos (requerimientos y características) del producto, el Sprint Backlog, que contiene los elementos a desarrollar en un Sprint y los resultados de cada Sprint que se denomina el Incremento del producto.

El Product Backlog está conformado por la lista de elementos (PBI: Product Backlog Item) que conforman las especificaciones de un producto. Estos elementos incluyen los requerimientos, características del producto, historias de usuarios, criterios de aceptación, etcétera.  Esta lista está ordenada por prioridad, de acuerdo al valor que el PBI da al negocio y su aporte al logro de los objetivos. El Product Backlog es gestionado y mantenido por el dueño del producto (Product Owner).

En los enfoques de desarrollo tradicionales, se procura describir con el mayor detalle posible el alcance del producto, valorando que éste no cambie durante la construcción. En SCRUM se reconoce, que al desarrollar proyectos complejos, es imposible conocer en detalle todas las especificaciones del producto que se pretende desarrollar. En lugar de eso, se tiene un alcance variable que se va refinando y descubriendo en la medida que el desarrollo avanza, con las entregas iterativas y la retroalimentación frecuente, dando lugar a un producto iterativo, incremental y evolutivo. En el Product Backlog los PBI más prioritarios tienen más detalle que los PBI de menor prioridad, que se van refinando y  adaptando a la evolución del producto, del contexto y de la tecnología.

El Product Owner establece el objetivo y meta del Sprint, y el Equipo de Desarrollo selecciona los PBI que hacen posible la meta deseada, conformando el Sprint Backlog, junto al plan, tareas técnicas, tareas de ejecución y acciones de mejora del proceso. El Equipo de Desarrollo es el dueño del Sprint Backlog, y es el único que lo gestiona y actualiza. El Product Owner no debe modificar los PBI del Sprint Backlog y el Equipo de Desarrollo debe hacer visible su contenido a todo el equipo de trabajo y a los involucrados (stakeholders) del proyecto.

El tercer artefacto de SCRUM es el Incremento del producto, que es la suma de todos los PBI completados durante un Sprint y el valor de los incrementos de todos los Sprint anteriores. Un acuerdo importante que debe establecer y cumplir el Equipo de trabajo, es cuando un PBI está completado o terminado, lo que se conoce como “Definition of Done”, el cual especifica las condiciones que debe cumplir el elemento para darlo por completado. Incluye usualmente que todos los criterios de aceptación de cada PBI han sido validados y aceptados por el Product Owner, que todas las pruebas unitarias e integrales se realizaron sin generar errores, entre otros criterios. Esto asegura que el incremento es usable, independientemente de si el Product Owner decide liberarlo o no.

Estos artefactos se crean y mantienen de forma cíclica dentro de los Eventos de SCRUM. En el próximo artículo te hablaré sobre el propósito y la dinámica de cada uno de estos eventos.

Gracias por leerme.-

El Liderazgo en SCRUM

En Scrum se definen 3 roles: el Equipo de Desarrollo (Development Team), el Dueño del Producto (Product Owner) y el SCRUM Master.

El Equipo de Desarrollo es responsable de estimar, desarrollar y entregar productos terminados al final de cada Sprint. No tiene un líder, sus miembros disponen de las habilidades necesarias para construir el producto, sin títulos ni rangos, aunque con destrezas específicas, todos son desarrolladores, y la responsabilidad del producto es del equipo. Sus miembros se auto-organizan para decidir cómo realizar el trabajo y resolver los problemas que se presenten. Su tamaño suele estar entre 3 y 9 personas.

El Product Owner es el responsable de maximizar el valor del Producto y del trabajo del Equipo de Desarrollo, asegurando la claridad, visibilidad, transparencia y comprensión de las características y requerimientos del incremento del producto a desarrollar en cada Sprint. Gestiona las expectativas de los stakeholders y determina las prioridades de las especificaciones del producto, adaptándolas a los cambios que se den en el negocio o en la tecnología. Aunque puede representar las necesidades de un grupo de personas o comité, el Product Owner es una sola persona con la autoridad para establecer las prioridades y especificaciones del producto dentro del proyecto.

El SCRUM Master es el Coach del equipo, enseña y acompaña el uso de SCRUM, ayudando al equipo para que alcance su máximo nivel de productividad. En palabras de Wolk[1] es un Facilitador que fomenta ambientes de apertura y discusión para lograr consensos, es un Provocador que desafía las estructuras rígidas y antiguas concepciones de cómo se deben hacer las cosas, es un Detective que busca indicios y pistas en la narrativa del equipo, y es un Soplador de brasas que facilita en el otro el aprendizaje para reconectarlo a sus pasiones.

El SCRUM Master es un Facilitador Servicial que acompaña al Product Owner y al Equipo de Desarrollo en la comprensión y el uso correcto de SCRUM,  y para que realicen sus actividades con productividad y eficiencia. Asimismo, protege al equipo de distracciones y trabas externas, facilita la remoción de impedimentos y asegura la comunicación y colaboración dentro del equipo.

El SCRUM Master realiza sus funciones sin interferir en el trabajo del equipo, no ordena, ni controla, por lo que no incide de forma directa en los resultados del equipo, a diferencia de un gerente tradicional de proyectos. Sin embargo, sí el SCRUM Master logra cumplir con éxito su propósito, será una pieza clave en el logro del éxito del proyecto.

SCRUM propone un conjunto mínimo de artefactos para construir un producto, en la próxima entrega les hablaré sobre ello.

Gracias por leerme.

---

[1] Wolk, Leonardo. Coaching. El arte de soplar brasas, 2003. Citado en Alaimo y Salinas. Proyectos ágiles con SCRUM. Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos, 2015.