Qué es la metodología Scrum, todo lo que necesitas saber

Muchos de mis lectores me preguntan continuamente “¿Qué es la Metodología Scrum?” Ahora traigo un largo artículo describiendo todo el proceso. Este artículo está basado en la Guía Scrum.

Se define Scrum como una estructura en la que las personas pueden abordar complejos problemas adaptativos, siendo a la vez productivas y creativas para entregar productos finales de gran valor. Scrum también incorpora varios elementos, como que es ligero y fácil de entender. Eso sí, es difícil de dominar.

Una Mirada más Profunda de la Metodología Scrum

Como ya se ha mencionado, Scrum es una estructura de procesos, y se lleva usando desde los inicios de los años 90. Se usa Scrum para la dirección del desarrollo de productos complejos, y varios procesos y técnicas garantizan que esto ocurre. Cuando pretendes mejorar tus prácticas de dirección y desarrollo, Scrum puede ayudarte a aclarar la relativa eficacia de tu gestión de productos.

La estructura está compuesta de Equipos Scrum que llevan a cabo una serie de funciones, tienen diferentes utensilios y eventos y siguen una serie de reglas. Cada parte de la estructura tiene un propósito, que trabaja hacia el éxito de Scrum.

Este artículo explica todo lo que necesitas saber sobre Scrum, incluyendo las reglas y relaciones implicadas. Además, hay diferentes discusiones sobre tácticas que revelan las diferentes maneras en las que se puede trabajar con la Estructura Scrum.

Entendiendo Scrum: Teoría de Scrum

Para entender Scrum, es importante echar un vistazo a sus fundamentos básicos. Scrum se ha fundado sobre una teoría empírica de control de procesos, que también se conoce como empirismo. Lo que afirma esta teoría es que el conocimiento se basa en la toma de decisiones y en la experiencia de los factores conocidos.

Por tanto, Scrum busca cómo optimizar la predictibilidad y controlar el riesgo utilizando un método Iterativo e Incremental. Para que esto suceda, hay tres pilares que se deben implementar. Estos son la Transparencia, la Inspección y la Adaptación.

Transparencia

Hay partes de este proceso que necesitan ser visibles para aquellos responsables de los resultados. Esto requiere definiciones estándar de todos los aspectos para asegurarse de que hay un entendimiento común de todas las observaciones. Considera estos ejemplos: –

• Todos los participantes en el proceso deben usar un lenguaje común
• Tanto aquellos que llevan a cabo el trabajo, como los que aceptan el resultado, deben tener una definición estándar de “Finalizado”.

Inspección

Aquellos que usan Scrum necesitan inspeccionar periódicamente los instrumentos Scrum y el progreso del Objetivo en el Sprint. Esto asegura que puedan detectar variaciones no deseadas a tiempo. Las inspecciones deben llevarse a cabo de vez en cuando, de manera que no se interrumpa el trabajo en progreso. Los inspectores cualificados se aseguran de que todas las inspecciones se hacen de manera correcta y son beneficiosas.

Adaptación

Después de una inspección, puede revelarse que uno o más aspectos del proceso se ha desviado de los límites aceptables. Esto significa que el producto final podría no ser aceptable y que es necesario hacer algún ajuste en el proceso o el material que se está usando. Cuanto antes ocurra, mejor, de manera que se eviten más desviaciones.

Equipo Scrum

Tres miembros componen el Equipo Scrum básico, y son el Product Owner, el Equipo de Desarrollo y el Scrum Master. Se espera que estos equipos se auto-organicen y sean multifuncionales. Cuando se auto-organizan, pueden elegir la mejor manera de finalizar el trabajo y no tener en cuenta la orientación que puedan dar personas que no sean del equipo.

Como equipos multifuncionales, tienen todas las competencias para para realizar el trabajo, sin depender de otras personas fuera del equipo. El objetivo del equipo es optimizar la flexibilidad, la creatividad y la productividad.

Los Equipos Scrum entregan productos de manera iterativa e incremental, aprovechando el feedeback que les llega. Las entregas incrementales de productos “Finalizados” asegura que siempre está disponible una versión funcional del producto. Si quieres conseguir un equipo óptimo, echa un vistazo a estos dos artículos: “Cómo Conseguir un Gran Equipo Ágil” y “Cómo Llevar a Cabo una Reunión Inicial de Equipo”.

 El Product Owner

Cuando se trata de maximizar el valor del producto y el trabajo del Equipo de Desarrollo, es el Product Owner el responsable de ello. Esto varía según los Equipos Scrum y las personas del equipo. El Product Owner tiene la responsabilidad de gestionar el Backlog del Producto. Esta gestión incluye:

• Expresar claramente los elementos del backlog de Producto
• Ordenar los elementos del Backlog de Producto para alcanzar las misiones y los objetivos
• Optimizar el valor del trabajo que realiza el Equipo de Desarrollo
• Asegurar que el Backlog de Producto es visible, transparente y claro.

Esto revela en qué debería trabajar el Equipo Scrum y asegura que el Equipo de Desarrollo comprende perfectamente los elementos del Backlog de Producto al nivel requerido. Aunque el Product Owner podría delegar este trabajo en el Equipo de Desarrollo, son responsables del resultado.

El Product Owner es una persona y no un comité. Si existe un comité en funcionamiento, pueden presentar sus deseos en el backlog de Producto. Aquellos que quieran hacer cualquier ajuste, necesitan consultar al Product Owner.

Para garantizar que el Product Owner tiene éxito, todas las personas de la organización deben respetar sus decisiones, que son visibles en el contenido y orden del Backlog de Producto. No hay nadie capaz de ordenar al Equipo de Desarrollo trabajar con requisitos distintos, y el Equipo de Desarrollo también tiene sus acciones limitadas bajo las instrucciones de otra persona.

El Equipo de Desarrollo

Es un equipo formado por profesionales que trabajan para entregar un Incremento de producto “Finalizado” que se pueda lanzar al final de cada Sprint. Solo los miembros de este equipo pueden crear el Incremento.

La organización asegura que el Equipo de Desarrollo está empoderado para organizar y gestionar su trabajo. La sinergia que ocurre, como resultado, optimizará la eficiencia y efectividad del Equipo de Desarrollo. Estos equipos tienen las siguientes características:

• Se auto-organizan. No reciben instrucciones ni consejo de nadie sobre cómo convertir el Backlog de Producto en Incrementos de funcionalidades potencialmente liberables.
• Son multifuncionales y tienen todas las habilidades necesarias para crear un Incremento de producto.
• Scrum no otorga ningún título al Equipo de Desarrollo. Todo el mundo es desarrollador, sin importar el trabajo que desempeñen. Esto se aplica sin excepciones.
• Dentro del Equipo de Desarrollo, el Scrum reconoce que no hay sub-equipos. Esto ocurre incluso cuando hay muchos dominios que tienen que ser tratados, como el análisis de negocios o el testeo. Esto se aplica sin excepciones.
• Cada miembro del Equipo de Desarrollo podría tener una habilidad o zona de confort especial, pero si hablamos de responsabilidades, se considera al equipo como un todo.

El Equipo de Desarrollo se compone de muchas personas, siendo tres el número óptimo. Esto asegura que se mantienen ágiles y son un lo suficientemente grandes para finalizar todo el trabajo que se debe hacer en un Sprint.

Si el equipo tiene menos de tres miembros, la interacción puede verse reducida, lo que significa que se tendrá menor productividad. Además, los Equipos de Desarrollo pequeños pueden ver restringidas sus capacidades durante el Sprint, significando que podrían no ser capaces de entregar un Incremento potencialmente liberable.

Los equipos grandes, como aquellos con más de nueve miembros, necesitan mucha más coordinación. Acaban generando demasiada complejidad como para gestionar un proceso empírico. Al contar al Equipo de Desarrollo, no se cuenta al Product Owner ni al Scrum Master a no ser que también estén realizando el trabajo del Backlog del Sprint.

El Scrum Master

El Scrum Master tiene la responsabilidad de asegurar que se ha entendido y aprobado el método Scrum. Trabajan con el Equipo Scrum, por lo que pueden adherirse a la teoría, prácticas y reglas de Scrum. El Scrum Master es esencialmente el líder-ayudante del Equipo Scrum. Si te encuentras en la situación de que eres el Scrum Master de dos equipos, echa un vistazo a: “Las Dos Preguntas más Importantes sobre Liderar 2 Equipos como Scrum Master”.

El Scrum Master ayuda a las personas que no están en el Equipo Scrum a entender cuáles de sus interacciones con el Equipo Scrum son útiles y cuáles no.

Entendiendo el Servicio del Scrum Master

Hay tres grupos de Servicio del Scrum Master, y estos incluyen:

El Servicio del Scrum Master para el Product Owner

Esto se hace de numerosas maneras, incluyendo:

• Encontrar técnicas para gestionar de manera efectiva el Backlog de Producto
• Ayudar al Equipo Scrum a entender la necesidad de tener elementos claros y concisos en el backlog de Producto
• Comprensión del planteamiento de producto en un ambiente empírico
• Asegurar que el Product Owner conoce la mejor manera de organizar el backlog de Producto para maximizar el valor
• Comprensión y práctica de la agilidad.
• Facilitar eventos de Scrum según se requiera

El Servicio del Scrum Master para el Equipo de Desarrollo

Aquí, el Scrum Master ayudará al Equipo de Desarrollo de las siguientes maneras:

• Actuar de coach en temas de auto-organización y multifuncionalidad
• Ayudar al Equipo de Desarrollo a crear productos de alto valor
• Eliminar los Impedimentos del progreso del Equipo de Desarrollo
• Facilitar eventos de Scrum según se requiera
• Actuar como coach en ambientes de organización donde el método Scrum no ha sido totalmente adoptado o entendido

Servicio del Scrum Master para la Organización

Los Scrum Masters pueden ayudar a la organización de varias maneras, como:

• Liderar al equipo y actuar de coach en la adopción del método Scrum
• Planear la implementación de Scrum en la organización
• Ayudar a empleados y partes interesadas a entender el desarrollo de Scrum y el desarrollo empírico de productos
• Causar cambios que lleven al incremento de la productividad del Equipo Scrum
• Trabajar con otros Scrum Masters para aumentar la efectividad de la implantación de Scrum en la organización

 Valores de Scrum

Hay muchos valores que el Equipo Scrum debe encarnar. Estos son el coraje, el compromiso, la sinceridad, el respeto Estos valores son básicos para erigir los pilares del método Scrum y conseguir confianza con todas las personas envueltas en él.

Los miembros del Equipo Scrum aprenden y exploran estos valores al trabajar en eventos y roles de Scrum. Para que el método Scrum tenga éxito, es necesario que los miembros del equipo sean competentes en estas cinco características.

Así lo hacen:

• Tienen el coraje para hacer lo que es correcto y abordar los problemas graves
• Se comprometen a alcanzar los objetivos del equipo
• Los inversores y el equipo acuerdan hablar abiertamente sobre el trabajo y las dificultades que tiene el mismo
• Se respetan los unos a los otros y confían en que son independientes y capaces
• Se centran en el trabajo del Sprint y los objetivos del equipo

Eventos de Scrum: Inspección y Eventos de Adaptación

Son normalmente eventos programados que se usan en Scrum. Normalmente regulan y minimiza la necesidad de llevar a cabo reuniones no planeadas. Todos estos eventos son de tiempo limitado, lo que significa que tienen una duración máxima.

En el momento que un evento, como un Sprint, comienza, tiene una duración fija que no puede cambiarse. Una vez que se cumple el objetivo del evento, todos los eventos restantes pueden finalizarse. Esto asegura que se gasta el mínimo tiempo posible en el proceso.

Cada evento da la oportunidad de inspeccionar o adaptar algo y ha sido diseñado para permitir una transparencia radical. Hay cuatro eventos formales programados en el método Scrum, que son: –

• Planificación del Sprint
• Scrum Diario
• Revisión del Sprint
• Retrospectiva del Sprint

Entendiendo el Sprint

El corazón del método Scrum es el Sprint. Se puede definir como un periodo de tiempo de un mes o menos en el que se crea un producto liberable, utilizable y “Finalizado”. Normalmente tienen una duración consistente durante un periodo de desarrollo. Los sprints deberían tener duraciones constantes durante todo el desarrollo. Un nuevo Sprint comienza solo cuando el anterior ha finalizado.

Los Sprints contienen y consisten de la Planificación del Sprint, los Scrums Diarios, la Revisión del Sprint, la Retrospectiva del Sprint y el Trabajo de Desarrollo.

Cuando el Sprint está en curso, no debería haber ninguna alteración que pudiera afectar al objetivo del mismo, los objetivos cualitativos no descienden, y el enfoque podría ser aclarado y renegociado entre el Product Owner y el Equipo de Desarrollo.

Es seguro considerar cada Sprint como un proyecto de un mes en el que se ha de conseguir algo. Por esta razón, en el Sprint se define claramente qué se va a construir, diseñar, un plan para la producción, el trabajo y el producto final. Si el Sprint durara más de un mes, la definición de lo que se va a crear cambiaría, y el riesgo podría subir junto a la complejidad general.

Los Sprints son importantes ya que aseguran que el trabajo es predecible y puede ser inspeccionado y adaptado mientras se trabaja por el objetivo del Sprint. Limitan el riesgo, particularmente si nos fijamos en el coste.

Es posible cancelar un Sprint antes de que finalice. Sin embargo, la única persona que puede hacer esto es el Product Owner. La decisión puede estar influenciada por otros, incluyendo las partes interesadas, el Equipo de Desarrollo o el Scrum Master. Una cancelación puede hacerse efectiva cuando el Objetivo del Sprint se vuelve obsoleto.

La obsolescencia puede estar causada por el azar en la dirección, las condiciones del mercado o las condiciones de la tecnología. Si el Sprint deja de tener sentido, debería ser cancelado. Sin embargo, verás que raramente se cancela un Sprint, ya que tienen una duración bastante corta.

Hay una serie de pasos que hay que cumplir al cancelar un Sprint. Se revisan primero los elementos completados y “Finalizados” del Backlog de Producto. Si algo del trabajo del Sprint puede liberarse, será aceptado por el Product Owner. Esos elementos que son incompetentes en el backlog de Producto se reestiman y devuelven al Backlog de Producto. Ya que este tipo de trabajo se puede depreciar rápidamente, se debe revalorar frecuentemente.

Las cancelaciones desaniman, ya que consumen recursos. Esto se debe a que todas las personas envueltas en el Sprint tienen que reagruparse y realizar otro proceso de planificación del Sprint, para comenzar uno nuevo. Causan malestar en el equipo y se trata de evitarlas.

Planificación del Sprint

Cualquier trabajo que va a hacerse en el Sprint se planea en la Planificación del Sprint. La planificación une al Equipo Scrum y se crea mediante un trabajo colaborativo. La planificación del Sprint tiene una duración concreta de ocho horas como máximo para un Sprint de un mes; aquí puedes encontrar sugerencias sobre cómo llevar a cabo una efectiva planificación del sprint.

Cuando el Sprint dura menos, también el evento tiene a ser más corto. Depende del Scrum Master asegurar que el evento tiene lugar y que los asistentes entienden la razón del mismo. El Scrum Master enseñará al equipo a mantenerse en la duración establecida.

En la Planificación se responden las preguntas sobre qué se puede liberar en el Incremento del siguiente Sprint, y cómo se conseguirá realizar el trabajo que se va a liberar.

¿Qué se puede liberar en el siguiente Sprint?

Durante el periodo de Planificación del Sprint, el Equipo de Desarrollo trabajará en pronosticar la funcionalidad que será desarrollada durante el Sprint. El Product Owner analizará el objetivo que se busca en el Sprint. Más allá, los elementos del Backlog de Producto que ayudarán a conseguir dicho objetivo. El Equipo Scrum al completo trabajará conjuntamente para comprender el trabajo del Sprint.

Esta reunión tiene unos aportes principales, que son el Backlog de Producto, el último Incremento de producto, la capacidad esperada del Equipo de Desarrollo durante el Sprint y el rendimiento previo del mismo. El Equipo de Desarrollo seleccionará cuántos elementos del Sprint provendrán del backlog de Producto. Es el Equipo de Desarrollo quien proporcionará información sobre qué pueden conseguir, basándose en las expectativas del Sprint.

Después del pronóstico de los elementos del Backlog de Producto, el Equipo de Desarrollo llevará a cabo el Sprint, mientras que el Equipo Scrum podría establecer el Objetivo del Sprint. El Objetivo del Sprint es el propósito que se alcanzará en el Sprint cuando el Backlog de Producto haya sido implementado. Sirve como guía para el Equipo de Desarrollo sobre por qué se crea el Incremento.

Si te interesa este tema, hace un tiempo Chris escribió un artículo en el blog: “Cuatro Razones Por las Que no se Llevan a Cabo las Historias de Usuario Ágiles”, échale un vistazo.

¿Cómo se logrará el trabajo?

Una vez que se ha establecido el Objetivo del Sprint y que los elementos de Backlog de Producto se han seleccionado, entonces el Equipo de Desarrollo decidido cómo se construirá la funcionalidad para conseguir un Incremento del producto “Finalizado” durante el Srpint. Los elementos del Backlog de Producto elegidos para este Sprint, junto al plan para liberarlos, se conoce como Backlog del Sprint.

El Equipo de Desarrollo diseñará un sistema para convertir el Backlog de Producto en un Incremento de producto funcional. La carga de trabajo puede variar según el esfuerzo necesario y el tamaño del trabajo. Durante la Planificación del Sprint, el Equipo de Desarrollo pronosticará qué piensan que se puede conseguir en el siguiente Sprint.

Al final de la reunión, el trabajo planeado para los primeros días del Sprint, que debe realizar el Equipo de Desarrollo, se descompone en unidades diarias (o menos). La auto-organización tiene lugar a la hora de realizar el trabajo del Backlog del Sprint, tanto durante la Planificación del Sprint como cuando sea requerido en el Sprint.

El Product Owner tiene la tarea de ayudar a aclarar los elementos del Backlog de Producto elegidos e intercambiarlos cuando sea necesario. Si el Equipo de Desarrollo decidiera que es mucho o poco trabajo, entonces debería ser renegociado basándose en los elementos del Backlog de Producto.

Esto se hace junto al Product Owner. El Equipo de Desarrollo tiene también la libertad de invitar a otros a asistir en beneficio del dominio o para dar consejos técnicos. Al final de la Planificación del Sprint, el Equipo de Desarrollo debería tener la capacidad de explicar al Product Owner y al Scrum Master cómo se realizará el trabajo trabajando como un equipo auto-organizado para alcanzar el Objetivo del Sprint.

Objetivo del Sprint

Es un objetivo que se pone en el Sprint, que se consigue con facilidad una vez que se ha implementado el Backlog de Producto. Actúa, de alguna manera, como una guía al Equipo de Desarrollo sobre la razón por la que se crea el Incremento. El Objetivo del Sprint se establece en la reunión de Planificación del Sprint.

Se asegura que el Equipo de Desarrollo tiene un nivel de flexibilidad, en relación a la funcionalidad implementada en el Sprint.

El Objetivo del Sprint se entrega a través de los Elementos del Backlog del Producto y asegura que el Equipo de Desarrollo puede trabajar conjuntamente, en lugar de dividirse en diferentes iniciativas.

El Equipo de Desarrollo trabaja con el Objetivo del Sprint siempre en la mente, y esto afecta su funcionalidad y uso de la tecnología. Cuando haya un cambio en las expectativas, el Equipo de Desarrollo y el Product Owner facilitarán la colaboración para negociar el enfoque que se da al Backlog de Producto en el Sprint.

Scrum Diario

Cada día, el Equipo de Desarrollo deja 15 minutos para sincronizar sus actividades y desarrollar un plan para las siguientes 24 horas. Esto se conoce como el Scrum Diario. Incluye una inspección del trabajo que se ha hecho desde el anterior Scrum Diario y posteriormente se enfatiza sobre el trabajo que ha de realizarse antes del siguiente.

Es esencial que la hora y el lugar del Scrum Diario sean siempre iguales, ya que esto evitará cualquier complejidad. En la reunión, el Equipo de Desarrollo se centrará en:

• Qué se hizo el día anterior que ayudó a alcanzar el Objetivo del Sprint
• Qué se ha hecho hoy para ayudar a alcanzar el Objetivo del Sprint
• Qué impedimentos pueden poner trabas a la consecución del Objetivo del Sprint

Esto significa que el Scrum Diario es como una manera de chequear el grado de consecución del Objetivo del Sprint. Asegura que el trabajo se basa en el Backlog del Sprint y facilita la tarea de alcanzar el objetivo. Se desafía al Equipo de Desarrollo durante el Scrum Diario a trabajar conjuntamente como un equipo auto-organizado a través de discusiones detalladas, en las cuales puede que tengan que adaptar o repetir el trabajo del resto del Sprint.

Es el Scrum Master quien asegura que esta reunión se realiza a diario, aunque está dirigida por el Equipo de Desarrollo. Los Scrum Masters aseguran que el equipo no se sobresale de los 15 minutos, y hacen cumplir las reglas de participación.

Los beneficios del Scrum Diario son numerosos, incluyendo la mejora en la comunicación, la no necesidad de otras reuniones, la identificación de trabas al desarrollo, la rápida toma de decisiones y el aumento del conocimiento general del Equipo de Desarrollo. Hace un tiempo escribí un artículo sobre “Cómo llevar a cabo un Scrum Diario efectivo”, al que puedes echar un vistazo.

Revisión del Sprint

La Revisión del Sprint se lleva a cabo una vez que el Sprint ha finalizado. En ella, se inspecciona el Incremento y se adapta el Backlog de Producto si fuera necesario. Cuando la Revisión del Sprint tiene lugar, el Equipo Scrum y las partes interesadas evalúan qué se ha hecho durante el Sprint.

El resultado de la discusión podría llevar a adoptar cambios en el backlog de Producto, así como a la revisión de lo que podría ser optimizado con el objetivo de añadir valor. La revisión sirve para compartir información y no es una reunión sobre el estado del proyecto. Solo se mantiene para conseguir algo de feedback y para asegurar que existe colaboración.

Duraría unas cuatro horas si el Sprint fuera de un mes. Si el Sprint fuera más corto, también lo sería la reunión, incluye los siguientes elementos:

• Asistencia del Equipo Scrum y de las partes interesadas, invitados por el Product Owner
• El Product Owner explica qué elementos del Backlog de Producto están “Finalizados” y cuáles no.
• El Equipo de Desarrollo explica qué funcionó durante el Sprint y qué no funcionó, y cómo se solventaron los problemas
• El Equipo de Desarrollo revela qué se ha “Finalizado” y propone preguntas sobre el Incremento
• El Product Owner habla sobre el estado del Backlog de Producto y posibles fechas de finalización de los proyectos
• El grupo al completo colabora en los siguientes pasos, de manera que la Revisión del Sprint proporciona información valiosa para la Planificación de próximos Sprints
• Revisar el mercado o el posible uso del producto, cualquier cambio, y lo mejor para hacer a continuación
• Revisar el cronograma, el presupuesto, las capacidades y el mercado para el lanzamiento del producto

Después de la Revisión del Sprint, el Backlog de Producto se suele revisar, y se definen los elementos del Backlog de Producto que se utilizarán probablemente en el siguiente Sprint. Puede que se hagan ajustes generales para encontrar nuevas oportunidades.

Retrospectiva del Sprint

Es una oportunidad para el Equipo Scrum de realizar una inspección sobre lo que se ha realizado y desarrollar un plan para conseguir mejoras en el siguiente Sprint. Ocurre una vez que la Revisión del Sprint se ha finalizado, antes de que la Planificación del Sprint vuelva a comenzar.

Es una reunión con una duración concreta de unas tres horas para Sprints de un mes. Sprints más cortos darán lugar a reuniones más cortas. El Scrum Master se asegurará de que la reunión tiene lugar y los asistentes entienden claramente su propósito.

El Scrum Master participará como un miembro del equipo para proporcionar información sobre las responsabilidades en el proceso Scrum. El objetivo de esta reunión es:

• Inspeccionar el último Sprint
• Identificar y ordenar lo que funcionó y lo que necesita ser mejorado
• Desarrollar un plan para implementar mejoras al Equipo Scrum y la manera en que trabajan

El Scrum Master usará esta reunión para animar al Equipo Scrum a mejorar en las prácticas y procesos del desarrollo. Esto asegurará que el siguiente Sprint sea más efectivo y disfrutable. Se implementan los planes para elevar la calidad del producto, estableciendo una definición apropiada de producto “Finalizado”.

Una vez que se ha completado la Retrospectiva del Sprint, el Equipo Scrum habrá identificado qué se puede mejorar en el siguiente Sprint. Se adoptarán estas mejoras y serán inspeccionadas por el propio Equipo Scrum. La Retrospectiva del Sprint es una oportunidad formal de centrarse en la inspección y la adaptación.

Si te interesa este tema, puedes echar un vistazo a mi otro artículo: “La Guía Sobre Las Retrospectivas Ágiles Que Te Convertirá En Un Magnífico Facilitador”. Mi amigo Marc Loeffler escribió este artículo: “Las cinco preguntas más comunes sobre las Retrospectivas Ágiles”. Y, por supuesto, si buscas nuevas ideas para tu Retrospectiva del Sprint, echa un vistazo a: “Ideas sobre las Retrospectivas Ágiles”.

Elementos de Scrum

Representan el trabajo o valor para proporcionar transparencia, así como oportunidades para la inspección y la adaptación. Se definen como específicamente diseñadas para maximizar la transparencia sobre la información clave, de manera que todos tienen el mismo conocimiento del elemento en cuestión.

El Backlog de Producto

Esto se refiere a una lista ordenada de todas las cosas que se requieren para desarrollar un producto. Contiene todos los requisitos para cualquier corrección que se tenga que hacer a un producto; el responsable de ello es el Product Owner.

Es un trabajo en progreso (WIP), y no llega a tener nunca una versión final. Establece los requisitos y evoluciona a la vez que el producto. Sufre cambios basándose en qué es más conveniente, útil y competitivo para el producto y existirá mientras que exista el producto.

Contiene una lista de todas las funciones, requisitos, características, mejoras y arreglos, que constituyen los cambios que tienen que realizarse al producto en la siguiente release. Los elementos del Backlog del Producto tienen una descripción, orden, estimación y valor.

Cuanto más se use el producto, y obtenga valor, más feedback puede esperarse del mercado. Esto resultará en el crecimiento del Backlog del Producto, al mismo tiempo que los requisitos evolucionan. También puede sufrir cambios basados en los requisitos de negocio, condiciones del mercado y la tecnología.

Donde hay muchos Equipos Scrum, puede que necesiten trabajar juntos en un producto.

En Este caso, solo un Backlog de Producto será utilizado para describir el producto. Para refinar el Backlog del producto, los detalles, las estimaciones y el orden de los elementos podría ser modificado.

Esto lo realizan mediante la colaboración el Product Owner y el Equipo de Desarrollo. Mientras se refina, también se revisan los elementos que se quedan dentro. Es el Equipo Scrum quien decide cómo se realizará el perfeccionamiento, de manera que no se coja más del 10% de la capacidad del Equipo de Desarrollo. El Product Owner tiene la capacidad de actualizar los elementos del Backlog del Producto en cualquier momento.

Hay elementos del Backlog del Producto ordenados más arriba y otros más abajo, siendo los que están más arriba los más aclarados y detallados. Son los que están arriba los elementos que pueden ser “Finalizados” por el Equipo de Desarrollo, y pueden ser considerados como “Listos” para la selección en la Planificación del Sprint.

El Equipo de Desarrollo es responsable de todas las estimaciones, ya que son los que van a realizar el trabajo.

Monitorizar el Progeso de Cara a Conseguir un Objetivo

Es posible calcular la cantidad de trabajo necesaria para alcanzar un objetivo. Durante la Revisión del Sprint, el Product Owner establecerá cuánto trabajo queda por hacer. Se realiza una comparación entre el trabajo sobrante de Revisiones de Sprint pasadas y el progreso necesario para completar el Sprint actual en el tiempo que se ha establecido. Esta información se comparte después con todas las partes que están involucradas.

Para pronosticar el progreso, se utilizan gráficos burn-up y burn down y diagramas de flujo acumulado. Allá donde existe un ambiente complejo, el resultado podría ser desconocido, de manera que solo lo que ha ocurrido en el pasado sería tomado en cuenta a la hora de tomar decisiones.

Backlog del Sprint

Se conoce a los elementos del Backlog de Producto que se han seleccionado para el Sprint como el Backlog del Sprint. Incluyen también el plan para entregar el Incremento del Producto y alcanzar el Objetivo del Sprint. Fundamentalmente, el Backlog del Sprint es un pronóstico del Equipo de Desarrollo que se centra en saber cuán funcional será cada Incremento, así como el trabajo que es necesario para convertir la funcionalidad en un Incremento “Finalizado”.

El Backlog del Sprint asegura que todo el trabajo realizado por el Equipo de Desarrollo es visible y que se puede alcanzar el Objetivo del Sprint. El Backlog del Sprint es esencialmente un plan que contiene el detalle necesario para que en el Scrum Diario se comprendan los cambios realizados.

El Equipo de Desarrollo puede modificar el Backlog del Sprint durante todo el Sprint y después surgir durante el Sprint, mientras que el Equipo de Desarrollo trabaja en el plan. Esto se debe a que se aprende más sobre el trabajo necesario para alcanzar el Objetivo del Sprint.

Si existe la necesidad de finalizar el trabajo, el Equipo de Desarrollo lo añade al Backlog del Sprint. Mientras se completa, el trabajo restante se actualiza. Por el camino, se elimina cualquier elemento del plan que no sea necesario.

Solo el Equipo de Desarrollo puede cambiar el Backlog del Producto en el curso de un Sprint. El Backlog del Sprint es como una huella visible para el Equipo de Desarrollo y pertenece solamente a este equipo.

Monitorizar el Progreso del Sprint

Durante el Sprint, se puede resumir el Backlog del Sprint en cualquier comento. Depende del Equipo de Desarrollo el monitorizar en cada Scrum Diario el trabajo restante para alcanzar el Objetivo del Sprint. Monitorizarlo le permite al Equipo de Desarrollo gestionar el progreso del proyecto.

Incremento

Se puede resumir todo el trabajo que resta del Backlog del Sprint en cualquier momento. El Incremento es la suma de esto y del valor de cualquier otro Incremento de Sprints previos. El incremento final al terminar el Sprint debería estar “Finalizando”, que significa que está en una condición utilizable y cumple con la definición establecida por el Equipo Scrum. La condición utilizable es indispensable, sea cual sea la decisión del Product Owner de lanzarlo o no.

Transparencia en los Elementos

Para que el método Scrum sea como es, la transparencia es esencial. Es la base de las decisiones que se toman para optimizar el valor y el control del riesgo. El grado de cumplimiento de la transparencia determina si las decisiones son correctas o no. Si los elementos no son completamente transparentes, entonces las decisiones tienen defectos y su valor disminuye. Además, el riesgo aumentará.

El Scrum Master debe trabajar con todas las partes participantes, incluyendo el Product Owner y el Equipo de Desarrollo, para asegurar que los elementos son totalmente transparentes. En el caso de que no exista una fuerte transparencia, hay prácticas para salir adelante.

El Scrum Master debe a ayudar a todos a aplicar las prácticas más apropiadas para conseguir una buena transparencia. Un Scrum Master puede detectar una transparencia incompleta mediante la inspección de los elementos, el razonamiento sobre los patrones y la observación cuidadosa de toda la información disponible.

Desde aquí, se pueden detectar las diferencias entre los resultados reales y los esperados. El Scrum Master ha de trabajar con el Equipo Scrum y la organización para aumentar la transparencia de los elementos. Esto se consigue mediante el aprendizaje, el convencimiento y los cambios, y requiere un largo camino.

Definición de “Finalizado”

El término “Finalizado” ha aparecido bastantes veces en este texto. Cuando se dice que un elemento del backlog del Producto o un Incremento está “Finalizado”, es muy importante que todas las partes involucradas entiendan el significado.

Está directamente relacionado con completar el trabajo y asegura que existe transparencia. Para el Equipo Scrum, “Finalizado” significa que el trabajo está completado en el Incremento del producto. Hace un tiempo, escribí un ejemplo de una “Checklist de la Definición de Finalizado”. Es esta la definición que servirá como guía para el Equipo de Desarrollo en el número de elementos del Backlog del Producto que deberían seleccionarse durante la Planificación del Sprint.

La razón de existencia de cada Sprint es entregar Incrementos de funcionalidades potencialmente liberables que cumplan con la definición de “Finalizado” del Equipo Scrum.

Con cada Sprint, el Equipo de Desarrollo debería entregar un Incremento de funcionalidades del producto. Es utilizable y un Product Owner podría decidir lanzarlo inmediatamente. En el evento en el cual la definición de “Finalizado” para un Incremento es parte de las costumbres o estándares de la organización de desarrollo, entonces todos los Equipos Scrum deben seguirla.

En el evento en el cual la definición de “Finalizado” no es un estándar de la organización de desarrollo, entonces se pide al Equipo de Desarrollo del Equipo Scrum traer una definición de “Finalizado” que vaya en la línea del producto. Allí donde hay muchos Equipos Scrum trabajando en el lanzamiento del producto, los Equipos de Desarrollo de todos ellos deben definir mutuamente el término “Finalizado”.

Cada Incremento es acumulable a los Incrementos anteriores y se prueba minuciosamente. Esto asegura que todos trabajan conjuntamente.

A la vez que los Equipos Scrum maduran, sus definiciones de “Finalizado” se expanden para incluir más criterios. Aquí presento algunas sugerencias para empezar con este acercamiento.

Todos los sistemas y productos necesitan una definición de “Finalizado”, que es el estándar que se aplica al trabajo realizado en ellos.

Creo que esto resume todo acerca de “Qué Es La Metodología Scrum”. Puedes comentar debajo lo que te apetezca.

Trabajar Conmigo o Con Evolution4All

He desarrollado el “Organisational Mastery”. El objetivo de este producto es crear un aliado que impulse los cambios y la innovación interna junto a la distribución de la información en toda la organización.  Es muy adecuado para las empresas que quieren mejorar drásticamente la alineación entre el liderazgo ejecutivo y los equipos de ejecución.