The Scrum Map

Desde CertMind, te damos la bienvenida a este libro, tu aliado en el fascinante mundo del desarrollo de productos bajo una filosofía ágil. Felicitaciones por tomar este paso significativo en beneficio de tus equipos y tu organización. Este libro no es solo para leer; es para interactuar, aplicar y reflexionar. Ya sea que lo estés consultando en línea o en PDF, utilízalo como una herramienta dinámica en tu camino hacia el dominio de Scrum.Aquí encontrarás un complemento esencial a 'The 2020 Scrum Guide' (https://scrumguides.org), enriquecido con explicaciones prácticas, ejemplos y ejercicios que elevarán tu comprensión de Scrum. Basamos nuestra guía en años de experiencia, colaboraciones con expertos, estudiantes y voluntarios. Nos inspiramos tanto en la guía oficial de Scrum como en el destacado 'The New New Product Development Game' de la Harvard Business Review. Así que, adelante, únete a nosotros en este viaje apasionante de transformar ideas en productos excepcionales.

1. Introducción: De la filosofía ágil a la práctica con Scrum

Este capítulo inicial te introduce en el mundo de la agilidad como filosofía de trabajo, sentando las bases para entender cómo Scrum se inserta en este contexto. Exploraremos los fundamentos de ambos conceptos para darte una comprensión sólida antes de abordar aspectos más específicos. Puntos clave de este capítulo: - Descubre la esencia de la agilidad y por qué importa. - Aprende cómo la agilidad impulsa la creación de productos exitosos. - Entiende el lugar que ocupa Scrum en el mundo ágil. - Hazte amigo de los términos de Scrum que serán tus compañeros de viaje en este libro.

1. Introducción: De la filosofía ágil a la práctica con Scrum

1.1 - ¿Qué es la agilidad y por qué se habla de ella en Scrum?

En el mundo actual, caracterizado por su dinamismo y constantes cambios, la agilidad se ha convertido en una filosofía esencial que promueve la adaptabilidad y la entrega continua de valor.

Antes de adentrarnos en el marco de trabajo Scrum, una de las herramientas más prominentes para implementar las prácticas ágiles, es fundamental que tengamos una sólida comprensión de lo que encarna la agilidad.

En este capítulo, exploraremos qué significa ser ágil, los beneficios que aporta, y los desafíos que podrías enfrentar al adoptar este enfoque. Esta base nos preparará perfectamente para luego entender cómo la cultura ágil y Scrum pueden colaborar en la transformación no solo de proyectos, sino también de organizaciones completas.

Caso de estudio: Adopción de la agilidad para mejorar las empresas Antes de adoptar prácticas ágiles, "People Information" se encontraba en una situación donde los proyectos demoraban mucho en completarse y a menudo excedían los presupuestos establecidos. La decisión de abrazar la agilidad y específicamente Scrum, fue un cambio estratégico crucial; Al enfocarse en ser más ágiles, empezaron a trabajar de una manera más colaborativa e innovadora, lo que les permitió responder rápidamente a los cambios y mantener una alta calidad en su entrega de productos. Este cambio no solo optimizó sus procesos internos sino que también mejoró la satisfacción de sus clientes al entregar soluciones que verdaderamente atendían sus necesidades actuales.

Scrum y su relación con la agilidad

Scrum es uno de los marcos de trabajo más reconocidos para adoptar la agilidad en equipos y organizaciones. Es un marco de trabajo que se enfoca principalmente en el desarrollo de productos, permitiendo que los equipos trabajen de manera iterativa e incremental. Esto significa que, en lugar de planificar todo el trabajo desde el principio, el trabajo se divide en pequeñas partes manejables, entregando valor continuo y permitiendo ajustes basados en el feedback real y las condiciones cambiantes del mercado.

Adoptar Scrum puede ser una estrategia eficaz para ayudar a las organizaciones a navegar por la complejidad del mundo actual, permitiendo entregas más rápidas y soluciones de mayor calidad que realmente resuenen con las necesidades de los clientes.

Scrum adopta los principios y valores contenidos en el Manifiesto Ágil (https://agilemanifesto.org/), lo que facilita la creación de productos de alta calidad, fomentando la colaboración y la respuesta rápida a los cambios. Al integrar Scrum en su enfoque hacia la agilidad, las organizaciones pueden esperar una mayor satisfacción del cliente, equipos más colaborativos y soluciones que verdaderamente atienden las necesidades actuales y emergentes del mercado.

👉 Tip para el lector
Promueve la formación continua en métodos ágiles dentro de tu organización. Considera establecer un programa de formación interno o aprovecha los cursos disponibles en plataformas reconocidas para desarrollar las habilidades necesarias en tu equipo. La formación constante facilita una transición más suave hacia las prácticas ágiles y ayuda a mitigar la resistencia al cambio

y entonces ... ¿Qué es la agilidad?

La agilidad es una mejor manera de resolver problemas complejos, con enfoque en la generación de espacios de colaboración, confianza e innovación.

La habilidad para aplicar estas técnicas de trabajo está determinada por el hecho de que los equipos de trabajo sean multifuncionales, enfocados en el cliente y autogestionados, lo cual contribuye de forma eficiente a generar estrategias enfocadas al cambio, permitiendo identificar rápidamente la mejora en los procesos; haciendo que se defina y construya el producto de acuerdo con las necesidades de la empresa y del cliente. Por lo general todos los métodos ágiles están diseñados para que el equipo de trabajo realice el trabajo de manera incremental e iterativamente.

La adopción de prácticas ágiles puede ser un verdadero catalizador para fomentar la innovación y mejorar la entrega de productos en una organización.

Beneficios de practicar la agilidad

Caso de Estudio: Renovación Ágil en TechSolutions "TechSolutions", una firma de tecnología, enfrentaba entregas tardías y descontento de clientes. Para remediar esto, optaron por adoptar Scrum en uno de sus equipos centrales. Esta transición rápidamente promovió una colaboración intensificada y elevó la moral del equipo, facilitando entregas más rápidas y una mejor calidad de producto; La integración continua del cliente en el proceso aseguró que los productos finales estuvieran más alineados con sus necesidades cambiantes, elevando así la satisfacción del cliente. Este cambio, aunque inicialmente implementado en un solo equipo, inspiró una transformación ágil a lo largo de la empresa, consolidando a "TechSolutions" como un testimonio de éxito y eficiencia en la industria.

Desafíos al adoptar prácticas ágiles

Ser ágil va más allá de simplemente adoptar nuevas herramientas o técnicas; es un cambio cultural que pone un fuerte énfasis en la colaboración, la comunicación y la adaptabilidad.

1. Introducción: De la filosofía ágil a la práctica con Scrum

1.2 - La cultura ágil: Cuando mejorar procesos no es suficiente

En un mundo donde la competencia se intensifica día a día, adoptar una cultura ágil ya no es una preferencia, sino una necesidad para las empresas que aspiran a destacarse. La Cultura Ágil, más que un conjunto de prácticas, representa una revolución en la forma en que los equipos piensan y operan, poniendo en primer lugar la creación de valor y la satisfacción del cliente. Acompáñanos mientras desentrañamos los conceptos clave de "Ser Ágil" y "Hacer Ágil", elementos cruciales para abrazar la agilidad en tu organización.

Una cultura ágil es donde la innovación se encuentra con la eficiencia, creando un espacio donde las ideas florecen y se realizan sin obstáculos.

La esencia de la Cultura Ágil

La cultura ágil, también conocida como Cultura Agile (incluso muy similar a lo que algunos llaman "Agile Mindset"), implica una transformación radical en la forma de trabajar. Se trata de adoptar estrategias que reduzcan la complejidad y centren los esfuerzos en crear productos o servicios que respondan directamente a las necesidades del cliente.

El propósito es maximizar el potencial de los equipos de trabajo, permitiéndoles alcanzar resultados destacados en plazos más breves y dinámicos, con un enfoque sólido en la excelencia, la competitividad, y la colaboración integral.

Ser Ágil vs. Hacer Ágil: Un equilibrio necesario

Hacer Ágil

"Hacer Ágil" es el acto de aplicar técnicas y estrategias específicas del ámbito ágil. En esta fase, nos centramos en incorporar eventos estructurados y definidos que faciliten el desarrollo fluido de un producto. Aquí, se integran herramientas específicas y se adoptan responsabilidades definidas para gestionar el trabajo de una manera más eficiente y productiva.

Ser Ágil

En contraste, "Ser Ágil" va más allá de las prácticas tangibles, sumergiéndose en la transformación de la mentalidad de cada integrante del equipo. Se trata de cultivar un enfoque que valora la colaboración, la adaptabilidad y un compromiso constante con el cliente. Esta faceta busca inculcar valores y principios ágiles en cada persona, fomentando una cultura de mejora continua y una predisposición a la innovación.

cultura-agil

En nuestra ilustración, el cerebro representa de manera simbólica la dualidad de la cultura ágil. En el hemisferio izquierdo, se destaca el "Hacer Ágil", que engloba la estructura y las prácticas concretas que guían el trabajo diario, sirviendo como el pilar racional y metódico de la gestión ágil. Por su parte, el hemisferio derecho resalta el "Ser Ágil", un espacio donde reside la mentalidad y los valores que deben permear en cada individuo y equipo, fomentando una actitud de colaboración, innovación y enfoque centrado en el cliente. Esta representación simboliza la armonía y el equilibrio necesarios entre la adopción de prácticas ágiles estructuradas y el fomento de una mentalidad ágil, demostrando que una verdadera cultura ágil prospera cuando ambos hemisferios trabajan en una sintonía perfecta.

Ten presente que debería existir tanto el ser, como el hacer en una correcta adopción de Scrum, así que no debes centrarte sólo en una o en otra.

Caso de estudio: cuando cambiar los procesos no es suficiente People Information LLC, una firma especializada en el outsourcing de recursos humanos, decide mejorar sus procesos usando Scrum. En su fase inicial, se enfocaron en estructurar y organizar sesiones de trabajo y asignar responsabilidades claras (Hacer Ágil), logrando una notable mejora en la eficiencia de sus procesos, Sin embargo, pronto se dieron cuenta de que para alcanzar un estado de agilidad verdadero, necesitaban ir más allá. Empezaron a fomentar una mentalidad ágil (Ser Ágil) en su equipo, promoviendo la colaboración, la comunicación constante y una fuerte orientación hacia el cliente. Esto no solo transformó su forma de trabajar sino que fomentó una cultura donde la innovación y la mejora continua eran el día a día, permitiendo una sintonía perfecta entre las metodologías ágiles y una mentalidad de crecimiento y adaptabilidad.

1. Introducción: De la filosofía ágil a la práctica con Scrum

1.3 - Scrum: ¿Revolución o moda pasajera?

¿Es Scrum una revolución en el desarrollo de productos o simplemente una tendencia pasajera? Después de haber explorado la profundidad de la cultura ágil, ahora nos enfocamos en uno de sus marcos más destacadas: Scrum. Esta guía te proporcionará una visión detallada y clara de lo que es Scrum, sus orígenes y cómo puede ser un agente de cambio significativo en tu organización.

Sumérgete con nosotros en este análisis objetivo para determinar el verdadero valor de adoptar Scrum.

Aclaraciones de la guía

Consejo para el lector: Es imperativo destacar que el libro "The Scrum Map" NO está restringido solo al ámbito del desarrollo de software. De hecho, se erige como una guía valiosa para cualquier profesión que aspire a implementar prácticas ágiles, facilitando así la gestión eficiente y la entrega de valor en una diversidad de campos profesionales. A través del "Scrum Map", los profesionales pueden trazar una ruta clara, estructurada y adaptable, que potencie la colaboración y la innovación en sus respectivos equipos.

Historia De Scrum

La historia de Scrum se puede rastrear desde 1986 en un artículo de la Harvard Business Review, “The New New Product Development Game” escrito por Hirotaka Takeuchi y Ikujiro Nonaka, en el que analizaron el enfoque que utilizaban compañías como Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, y Hewlett-Packard para el desarrollo de sus productos (esto debido a que estas compañias destacaban por su capacidad de innovación y buen desarrollo de productos).

Durante sus investigaciones, se dieron cuenta que dichas empresas compartían seis características:

  1. Inestabilidad incorporada
  2. Equipos de proyectos autoorganizados
  3. Fases de desarrollo superpuestas
  4. Multi-aprendizaje
  5. Control sutil
  6. Transferencia organizativa de aprendizaje.

Este enfoque, visualizado como un proceso ágil y flexible, sirvió para rejuvenecer organizaciones estancadas, infundiendo creatividad y respuestas impulsadas por el mercado.

El artículo original se puede leer en: https://hbr.org/1986/01/the-new-new-product-development-game

El camino de Scrum continuó en 1995 con Ken Schwaber y Jeff Sutherland, quienes consolidaron las ideas previas y presentaron una definición formal de Scrum en la conferencia OOPSLA de ese año, haciendo eco de su aprendizaje en empresas como Individual, Inc. y Fidelity Investments. Desde entonces, Scrum ha evolucionado bajo la custodia de Sutherland y Schwaber, sirviendo como un marco robusto y adaptable que complementa y potencia las estrategias de desarrollo de productos.

La guía publicada por Ken Schwaber y Jeff Sitherland se puede consultar en: https://scrumguides.org/

... Pero y entonces ¿Qué es Scrum?

Scrum es un marco de trabajo (framework en inglés) que proporciona una orientación para organizar las personas y guiar su forma de trabajo para construir productos de forma eficiente y creativa con un objetivo principal: entregar el máximo valor posible en el menor tiempo, esto se logra haciendo entregas parciales del producto, que también se conocen como incrementos de producto.

Cuando hablamos de Scrum, es importante destacar que pertenece a los marcos de trabajo ágiles, y que esto implica una transformación cultural, descubrimientos, experimentación, que al final se traducen en un cambio en la forma de desarrollar productos.

Scrum no es simplemente un proceso, no es una técnica, o un método definitivo para hacer las cosas, es más bien un conjunto de muchas herramientas y guías para que puedas llevar la agilidad y el cambio que esto supone para la organización.

Usos de Scrum

Inicialmente concebido para la gestión y desarrollo de productos, el alcance de Scrum se ha ampliado considerablemente. Hoy en día, se ha evidenciado su utilidad en una variedad de contextos, tales como:

  1. Investigar e identificar mercados viables, tecnologías, y capacidades. Ejemplo: Una empresa de energías renovables puede utilizar Scrum para investigar y desarrollar nuevas tecnologías de energía sostenible, ajustando su enfoque basándose en los hallazgos de cada incremento.
  2. Desarrollo de mejoras a productos ya existentes. Ejemplo: Un equipo de desarrollo de software puede utilizar Scrum para implementar actualizaciones regulares basadas en el feedback de los usuarios.
  3. Desarrollo de productos que requieren lanzamientos diariamente o tantas veces como sea posible. Ejemplo: Una plataforma de noticias online puede emplear Scrum para adaptar y actualizar su contenido varias veces al día, en respuesta a los acontecimientos mundiales en constante cambio.
  4. Desarrollo y mantenimiento en ambientes cloud (en línea, con foco en seguridad, y servicios por demanda), facilitando una operatividad óptima para el uso de productos. Ejemplo: Un proveedor de servicios cloud puede emplear Scrum para mantener y actualizar su infraestructura de forma continua y ágil.
  5. Mantenimiento y renovación de productos. Ejemplo: Una empresa manufacturera podría utilizar Scrum para la mejora continua de la línea de productos, permitiendo adaptaciones rápidas a las necesidades del mercado.
  6. Scrum se ha demostrado especialmente efectivo en la transferencia de conocimiento iterativa e incrementalmente. Scrum es ampliamente utilizado para la construcción de productos y servicios. Ejemplo: Una organización educativa podría utilizar Scrum para desarrollar y mejorar cursos de formación, integrando feedback iterativo de los estudiantes para realizar mejoras continuas.

Conclusión

¿Es Scrum una revolución o una moda pasajera? A través de los años, Scrum ha demostrado ser una herramienta vital, propulsando la eficiencia y colaboración en diversos campos, más allá del desarrollo de software. Su flexibilidad y enfoque en la entrega de valor lo consolidan como una revolución en la gestión de productos y proyectos, no como una tendencia efímera.

A medida que continuamos explorando la profundidad de este marco de trabajo ágil, en nuestro próximo módulo, nos sumergiremos en el corazón de Scrum: el modelo core, donde descubrirás los componentes clave del marco:

2. Modelo Core de Scrum

En este capítulo, hablaremos de las bases de Scrum, abriendo la caja para mostrar cada una de sus piezas fundamentales: el equipo, los artefactos, los eventos y la teoría que lo sostiene. Piensa en ello como los ingredientes básicos que necesitas para el desarrollo de productos exitosos. Puntos Clave de Este Capítulo: - Descubre quiénes componen el equipo en Scrum y cuál es su función. - Identifica los artefactos que actúan como herramientas de trazabilidad y planeación. - Reconoce los eventos que mantienen en marcha el proceso Scrum. - Comprende la teoría de Scrum que vincula todas las piezas juntas.

2. Modelo Core de Scrum

2.1 - El equipo Scrum

product-owner scrum-master developers

Un Equipo Scrum consiste en un Propietario del Producto (Product Owner), un Scrum Master y los Developers; y se trata de una unidad cohesionada de profesionales centrados en un objetivo a la vez: el Objetivo de Producto (Product Goal).

Los Equipos Scrum son auto-gestionados y multifuncionales. El modelo de Equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad.

Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades para poder obtener retroalimentación. Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.

Tamaño del Equipo Scrum

El tamaño óptimo de un Equipo Scrum es 10 personas o menos, esto le permite ser lo suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para poder completar una cantidad significativa de trabajo.

Consideraciones:


1. El Product Owner (Dueño de Producto)

product-owner

La gestión del Product Backlog incluye:

Para que el Product Owner pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones. Las decisiones del Product Owner se reflejan en el contenido y en la priorización del Product Backlog.

Responsabilidades del Product Owner

Normalmente el rol del Product Owner se asocia con un Gerente de Proyecto, dadas sus responsabilidades de gestión, sin embargo, estos roles NO son iguales. Es más preciso asociarlo al rol que representa “La voz del cliente”.


2. Desarrolladores (Developers)

scrum-master

Los Developers son los profesionales que realizan el trabajo de entregar un Incremento de producto “Terminado” (Done) que potencialmente se pueda poner en producción al final de cada Sprint. Solo los Developers participan en la creación del Incremento.

Responsabilidades de los Developers

Nota: Se llaman “Desarrolladores”, porque desarrollan el producto (no necesariamente software)

La organización es la encargada de estructurar y empoderar a los Developers para que estos organicen y gestionen su propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad del Equipo Scrum en conjunto.

Los Developers tienen las siguientes características:


3. El Scrum Master (Maestro Scrum)

scrum-master

El Scrum Master es un facilitador, responsable de promover y apoyar Scrum como se define en la Guía de Scrum. Su principal responsabilidad entonces es garantizar que todos conocen y aplican correctamente la teoría y práctica de Scrum.

El Scrum Master al servicio del Equipo y los Desarrolladores (Developers)

El Scrum Master sirve a los desarrolladores de varias formas, incluyendo:

El Scrum Master al servicio del Product Owner

El Scrum Master sirve al Product Owner de varias formas, incluyendo:

El Scrum Master al servicio de la Organización

El Scrum Master sirve a la organización de varias formas, incluyendo:

Scrum NO considera el rol tradicional de “Gerente del Proyecto”. Entonces, ¿a dónde van estos empleados? Lo más frecuente y natural es que los Gerentes de Proyecto hagan una transición hacia Product Owners e incluso a Scrum Masters. Sin embargo, muchos buenos Scrum Masters provienen de los desarrolladores y QA; por lo tanto el Scrum Master no es ni remotamente parecido al del Gerente de Proyecto, y por esto es importante que el candidato a Scrum Master adquiera capacitación en Scrum.

El Scrum Master debe aceptar que el equipo es dueño de la agenda de trabajo, así que no más actualizar los viejos Diagramas de Gantt. Debe alentar al equipo para que mantenga actualizadas sus estimaciones diarias. El Scrum Master asegura que se siga el proceso de Scrum, que todos entienden Scrum y cómo funciona.

El Scrum Master debe quitar impedimentos, o asistir en quitar impedimentos, lo más rápido posible.

Se asegura que el equipo se mantiene en rumbo, recordándole al equipo el objetivo del Sprint en cada reunión.

Organiza los Scrums diarios (Reunión diaria), y se asegura que se realice en el mismo lugar a la misma hora.

Traducido de Coping with change on Scrum projects, por Jack Milunksy.


Comunicación en el equipo

comunicacion-equipo
2. Modelo Core de Scrum

2.2 - Artefactos en Scrum

Los artefactos de Scrum representan el trabajo o el valor en diversas formas, los cuales son útiles para proporcionar transparencia y oportunidades para la inspección y adaptación. Los artefactos definidos por Scrum están diseñados específicamente para maximizar la transparencia de la información clave, necesaria para asegurar que todos tengan el mismo entendimiento sobre el Producto.

Cada artefacto está vinculado con un compromiso para garantizar que se cuenta con información suficiente sobre el producto, esto mejora la transparencia y el enfoque con el que se puede medir el progreso:

Antes de abordar los artefactos, ¿qué es un Producto?

Un producto es un vehículo para aportar valor y se refiere a cualquier resultado entregable y potencialmente utilizable que se desarrolla durante un determinado tiempo. Tiene un límite claro, partes interesadas conocidas, usuarios o clientes bien definidos. Un "producto" puede ser un bien tangible o intangible, como un software, una aplicación, un documento, un servicio, un producto físico o cualquier otro artefacto que proporcione valor a los clientes o usuarios finales.


1. El Product Backlog

El Product Backlog es una lista ordenada de todos los elementos que podrían ser necesarios para el producto y es la única fuente de requisitos para cualquier cambio a realizarse en el producto, y también es la única fuente de trabajo para el Equipo Scrum.

El Product Owner es el responsable del Product Backlog, incluyendo su contenido, disponibilidad y ordenación.

Un Product Backlog siempre esta en constante actualización. El desarrollo inicial de los elementos del Product Backlog solo refleja los requisitos conocidos y mejor entendidos al principio.

El Product Backlog evoluciona a medida que el producto y el entorno en el que se usará también lo hacen. El Product Backlog es dinámico; cambia constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil. Mientras el producto exista, su Product Backlog también existe.

El Product Backlog enumera todas las características, funcionalidades, requisitos, mejoras, correcciones y cambios a realizarse sobre el producto para entregas futuras. Los elementos del Product Backlog tienen como mínimo los siguientes atributos:

A medida que un producto es utilizado y se incrementa su valor y el mercado proporciona retroalimentación, el Product Backlog se convierte en una lista más larga y exhaustiva. Los elementos estan en constante actualización así que el Product Backlog es un artefacto vivo. Los cambios en los requisitos de negocio, las condiciones del mercado o la tecnología podrían causar cambios en el Product Backlog.

¡Nota Importante! Para evitar proyectos que nunca terminan, es importante considerar el alcance del producto a la hora de crear y actualizar el Product Backlog.

El compromiso del Product Backlog es el Product Goal

Product Goal (Objetivo del Producto)


2. El Sprint Backlog

El Sprint Backlog es un conjunto de los elementos del Product Backlog que han sido seleccionados para desarrollarse durante un Sprint, el cual constituye un plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint.

El Sprint Backlog es una predicción hecha por el Equipo de Desarrollo acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento “Terminado”.

Cuando se requiere nuevo trabajo, el Equipo de Desarrollo lo adiciona al Sprint Backlog. A medida que el trabajo se ejecuta o se completa se va actualizando la estimación de trabajo restante. Cuando algún elemento del plan se considera innecesario, es eliminado. Solo el Equipo de Desarrollo puede cambiar su Sprint Backlog durante un Sprint. El Sprint Backlog es una imagen visible en tiempo real del trabajo que el Equipo de Desarrollo planea llevar a cabo durante el Sprint y pertenece únicamente al Equipo de Desarrollo.

El Sprint Backlog se compone del Sprint Goal (por qué), el conjunto de elementos del Product Backlog seleccionados para el Sprint (qué), así como un plan de trabajo para entregar el Incremento (cómo).

El compromiso del Sprint Backlog es el Sprint Goal

Sprint Goal (Objetivo del Sprint)

Es el Objetivo único para el Sprint, el cual se verá reflejado al entregar el incremento de producto generado al final de un Sprint.

El objetivo de Sprint se define durante la Planificación de Sprint y, a continuación, se agrega al Backlog de Sprint (Sprint Backlog).

A medida que los desarrolladores trabajan durante el Sprint, tienen en cuenta el Objetivo del Sprint. Si el trabajo resulta ser diferente de lo que esperaban, colaboran con el Product Owner para negociar el alcance del Sprint Backlog dentro del Sprint sin afectar el Objetivo del Sprint.


3. Incremento de Producto

Un Incremento es el resultado que entregan los Desarrolladores al final de cada Sprint, el cual se suma al valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint el nuevo Incremento debe estar “Terminado”, lo cual significa que está en condiciones de ser utilizado y que cumple con la Definición de “Terminado” del Equipo Scrum.

El compromiso del Incremento es la Definición de Terminado (DoD)

Definición de Terminado (DoD - Definition Of Done)

Es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto.

Un ejemplo genérico de criterios de terminado puede ser:

2. Modelo Core de Scrum

2.3 - Eventos en Scrum

Los eventos en Scrum, también conocidos como sesiones de trabajo, son momentos estructurados que facilitan la colaboración, la transparencia y la inspección regular, promoviendo una ejecución ágil de los proyectos. Aquí está una descripción concisa de cada uno y su propósito:

En Scrum existen diferentes eventos predefinidos con el fin de crear regularidad, minimizar la necesidad de reuniones innecesarias y permitir la transparencia.

Todos los eventos tienen un periodo de tiempo limitado (time-box), de tal modo que todos tienen una duración máxima, y se llevan a cabo al mismo tiempo y en el mismo lugar para reducir la complejidad.

1. El Sprint

¿De qué se trata un Sprint?

Los Sprints son el latido del corazón de Scrum, donde todas las ideas se convierten en valor. El Sprint es un evento con un tiempo asignado (time-box) de 1 a 4 semanas durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.

Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior. Los Sprints contienen y consisten en la Planificación del Sprint, los Scrum Diarios, el desarrollo del trabajo, la Revisión del Sprint, y la Retrospectiva del Sprint.

Cada Sprint puede considerarse como un “mini-proyecto” con un horizonte no mayor de un mes. Al igual que los proyectos, los Sprints se usan para alcanzar una meta. Cada Sprint tiene un objetivo de lo que se construirá, es decir, el Objetivo del Sprint (Sprint Goal), un diseño y un plan flexible que guiará su construcción, el trabajo del equipo y el incremento de producto resultante.

Los Sprints habilitan la predictibilidad al asegurar la inspección y adaptación del progreso al menos en cada mes calendario.

¿Cuál es la duración de un Sprint?

Típicamente, el Sprint dura entre 1 y 4 semanas (un mes calendario), siendo 2 semanas el duración más común.

Cuando el horizonte de un Sprint es mayor a un mes, la complejidad podría incrementarse y el riesgo podría aumentar.

¿Quiénes participan durante el desarrollo del Sprint y cómo se involucran?

¿Qué se necesita para poder llevar a cabo un Sprint?

¿Qué sucede durante el Sprint?

No hay una "agenda" para el Sprint como tal, pero el flujo general es:

  1. Comenzar a trabajar en los elementos del Sprint Backlog.
  2. Realizar reuniones diarias de sincronización (Daily Scrum).
  3. Trabajar colaborativamente para resolver impedimentos.
  4. Asegurarse de que se cumplan las definiciones de terminado ("Definition of Done") para los ítems completados.

¿Qué resulta del Sprint?

Consideraciones sobre la duración del Sprint

¿Se puede cancelar un Sprint? Un Sprint puede cancelarse antes que el periodo de tiempo llegue a su fin. Algunas de las razones por las que se podría cancelar un Sprint son:

Consideraciones sobre la cancelación del Sprint


2. Planificación del Sprint (Sprint Planning)

¿De qué se trata la Planificación del Sprint?

La Planificación del Sprint es una sesión de trabajo en la que el equipo Scrum determina qué elementos del Product Backlog se trabajarán durante el próximo Sprint y cómo se abordarán, es decir un plan de trabajo, y este plan se crea mediante el trabajo colaborativo de todo el equipo Scrum.

En esta sesión se establece el alcance y el objetivo para las próximas semanas (Sprint Goal).

¿Cuál es la duración de la Planificación del Sprint?

Máximo 8 horas para un Sprint de un mes. Para Sprints más cortos, la duración se reduce proporcionalmente (por ejemplo, 4 horas para un Sprint de dos semanas).

¿Quiénes participan de la Planificación del Sprint y cómo se involucran?

¿Qué se necesita para la Planificación del Sprint?

Agenda de la Planificación del Sprint

1. ¿Por qué este Sprint es valioso?

2. ¿Qué puede hacerse en este Sprint?

3. ¿Cómo se conseguirá completar el trabajo seleccionado?

¿Qué resulta de la Planificación del Sprint?

Consideraciones adicionales sobre la Planificación del Sprint


3. Daily Scrum (Scrum Diario)

¿De qué se tratan los daily?

El Scrum Diario es una corta sesión diaria (15 minutos) que tiene como objetivo inspeccionar el progreso de los Developers hacia el Objetivo del Sprint (Sprint Goal) e identificando posibles impedimentos para la ejecución.

El Scrum Diario se realiza para cada día del sprint.

Nota: Si el Product Owner o el Scrum Master están desarrollando elementos del Sprint Backlog, entonces pueden participar como Developers.

¿Cuál es la duración de los daily?

Máximo 15 minutos.

¿Quiénes participan de los daily y cómo se involucran?

Nota: El Scrum Master y Product Owner pueden asistir, pero la reunión es principalmente para los Developers.

¿Qué se necesita para los daily?

Posible agenda de los daily

Nota: El Scrum Master y los Developers tienen la libertad de seleccionar la estructura y técnicas que deseen para la ejecución de esta reunión; sin embargo, el Scrum Master tiene la opción de hacer las siguientes preguntas a los Developers:

¿Qué resulta de los daily?

Consideraciones adicionales sobre los daily


4. Revisión del Sprint (Sprint Review)

¿De qué se trata la Revisión del Sprint?

Al final del Sprint se lleva a cabo la Revisión de Sprint en la que se inspecciona el Incremento que se produjo durante el Sprint y adaptar el Product Backlog si fuese necesario.

El Equipo Scrum realiza una demostración del incremento y se revisa el progreso con respecto al Objetivo de Producto; basándose en esto y en cualquier cambio que deba considerarse, los asistentes colaboran para determinar los elementos que podrían desarrollarse en el siguiente Sprint para optimizar el valor.

Se trata de una sesión de trabajo, no de una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación para el equipo Scrum y fomentar la colaboración.

El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo fijado.

¿Cuál es la duración de la Revisión del Sprint?

Normalmente, dura máximo 4 horas para un Sprint de 4 semanas (la duración suele ser proporcional al largo del Sprint, por lo que para Sprints de 2 semanas, suele ser de 2 horas).

¿Quiénes participan de la Revisión del Sprint?

¿Qué se necesita para la Revisión del Sprint?

Agenda de la Revisión del Sprint

¿Qué resulta de la Revisión del Sprint?

Consideraciones adicionales la Revisión del Sprint


5. Retrospectiva del Sprint (Sprint Retrospective)

¿De qué se trata una retrospectiva?

La Retrospectiva del Sprint es una sesión donde el equipo Scrum reflexiona sobre el Sprint que acaba de terminar para identificar oportunidades de mejora y planificar acciones concretas para próximos Sprints.

¿Cuál es la duración de una retrospectiva?

Suele durar alrededor de 3 horas para un Sprint de 4 semanas (puede ser proporcionalmente menos para Sprints más cortos, por ejemplo, alrededor de 45 minutos a 1.5 horas para Sprints de 2 semanas).

¿Quiénes participan y cómo se involucran?

¿Qué se necesita para el evento?

Agenda de una retrospectiva

¿Qué resulta de una retrospectiva?

Consideraciones adicionales de una retrospectiva

2. Modelo Core de Scrum

2.4 - Teoría de Scrum

Transparencia

El proceso y el trabajo deben ser visibles para aquellos que realizan el trabajo (equipo Scrum), así como para los que reciben el trabajo (cliente y partes interesadas). Con Scrum, las decisiones importantes se basan en el estado percibido de los artefactos. Los artefactos que tienen poca transparencia pueden conducir a decisiones que disminuyen el valor y aumentan el riesgo. La transparencia permite la inspección.

Inspección

Los artefactos de Scrum y el progreso hacia los objetivos deben ser inspeccionados con frecuencia y diligentemente para detectar varianzas o problemas potencialmente indeseables. Para ayudar con la inspección, Scrum proporciona cadencia en forma de sus cinco eventos.

En los proyectos Scrum se deben inspeccionar frecuentemente los artefactos y el progreso hacia un objetivo, para detectar variaciones.

La inspección no debe ser tan frecuente como para que interfiera en el trabajo, las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos en el mismo lugar de trabajo (normalmente el Scrum Master).

Adaptación

Si algún aspecto de un proceso se desvía fuera de los límites aceptables o si el producto resultante es inaceptable, el proceso que se está aplicando o los resultados que se producen deben ajustarse. El ajuste debe realizarse lo antes posible para minimizar la desviación adicional.

Si un inspector determina que uno o más aspectos de un proceso se desvían de límites aceptables, y que el producto resultante no será aceptable, el proceso o el material que está siendo procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.

Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la inspección y adaptación, tal y como se describen en la sección Eventos de Scrum de esta guía:

teoria scrum

La teoría de Scrum ha sido tomada de: https://scrumguides.org/

3. Scrum Master: Líder al servicio del equipo Scrum

En este capítulo, nos adentraremos en la función vital que desempeña el Scrum Master en la implementación de Scrum. El Scrum Master no solo asegura una adopción precisa de Scrum según lo delineado en la Guía de Scrum, sino que también facilita la comprensión y el respeto de su teoría y prácticas a todos los niveles organizacionales. A lo largo de este segmento, desplegaremos un análisis detallado de las diversas actividades, habilidades y responsabilidades que caracterizan esta función, ampliando lo ya explorado en el modelo core de Scrum. Puntos Clave de este Capítulo - Profundizar en la responsabilidad crítica del Scrum Master en la adopción y mejora de Scrum. - Analizar las actividades clave que el Scrum Master facilita dentro del equipo Scrum. - Estudiar las habilidades esenciales que un Scrum Master debe cultivar para liderar con eficacia. - Examinar las responsabilidades a nivel organizacional que incumben al Scrum Master.

3. Scrum Master: Líder al servicio del equipo Scrum

3.1 - Habilidades del Scrum Master

Un Scrum Master debería tener un conocimiento profundo del marco Scrum por varias razones:

Como scrum master (SM) es necesario brindar soporte y soluciones al Equipo Scrum y a la organización en general; para esto debe contar con aptitudes y actitudes que contribuyan al liderazgo, a continuación se muestran algunas habilidades que tiene un SM:

Habilidades de liderazgo

Las habilidades de liderazgo en un Scrum Master se refieren a la capacidad de liderar y guiar al equipo para que alcance sus metas y objetivos. Algunas de las habilidades de liderazgo esenciales para un Scrum Master incluyen:

Ejemplo: Durante un proyecto, el equipo se siente inseguro respecto a la nueva tecnología que están utilizando. El Scrum Master, reconociendo la necesidad de liderazgo, organiza una serie de sesiones de capacitación con expertos para familiarizar al equipo con la tecnología, estableciendo así objetivos claros y proporcionando apoyo y orientación.

👉 Tip
Recuerda que un buen líder no sólo dirige, sino también inspira y motiva. Ser un líder en Scrum significa servir al equipo, eliminando obstáculos y ayudando a cada miembro a dar lo mejor de sí.

Habilidades de facilitación

El SM logra que todas las acciones, procesos y tareas sean fáciles de entender para el equipo, además de asegurar que se cuente con el entorno y herramientas necesarias para trabajar. Es necesario que actúe de manera:

Ejemplo: Durante la retrospectiva, algunos miembros del equipo discuten sobre qué metodología de trabajo es la más eficiente. El Scrum Master, como facilitador, interviene para asegurar que todos tengan una oportunidad de expresarse y que la discusión se mantenga centrada en la mejora continua, evitando desviarse hacia debates improductivos.

El Scrum Master facilitando los eventos

El SM como facilitador debe tener en cuenta los siguientes aspectos al momento de moderar un evento:

Habilidades de comunicación

Las habilidades de comunicación en un Scrum Master se refieren a la capacidad de comunicarse de manera efectiva con todas las personas con las que trabaja. Algunas de las habilidades de comunicación esenciales para un Scrum Master incluyen:

Ejemplo: Uno de los desarrolladores, Juan, ha estado teniendo dificultades con una tarea específica. En vez de señalarlo abiertamente y ponerlo en una situación incómoda, el Scrum Master se acerca de manera privada, ofrece feedback constructivo sobre lo que ha observado y escucha activamente las preocupaciones de Juan, buscando soluciones conjuntas.

👉 Tip
Recuerda que la comunicación no es solo hablar, sino también escuchar. Establece canales de comunicación abiertos, promueve la retroalimentación constante y verifica siempre que los mensajes hayan sido entendidos correctamente por todos los miembros del equipo.

Habilidades para la resolución de problemas

Las habilidades de resolución de problemas en un Scrum Master se refieren a la capacidad de identificar y resolver problemas que puedan surgir durante el trabajo con el equipo, esto considerando que No puedes impedir que aparezcan conflictos o problemas, pero puedes gestionarlos para minimizar el impacto al equipo, para esto debes desarrollar:

👉 Tip
En lugar de brindar soluciones inmediatas, guía al equipo a través del proceso de descubrimiento de soluciones. Esto empodera al equipo y les ayuda a desarrollar habilidades de resolución de problemas por sí mismos.

El Scrum Master como Eliminador de impedimentos

Un impedimento es cualquier cosa que obstruye el flujo de trabajo generando retrasos.

Es importante que el SM pueda remover los impedimentos del equipo para garantizar el flujo y a su vez el éxito del Sprint.

Ejemplo: El equipo enfrenta un bloqueo técnico que ha detenido el progreso. El Scrum Master organiza una sesión de tormenta de ideas (brainstorming) donde todos pueden compartir posibles soluciones. Se anima al equipo a pensar de manera creativa, y juntos, logran encontrar un enfoque innovador que resuelve el problema.

Desafíos para el Scrum Master al eliminar impedimentos:

Desafío ¿Cómo lo puedes abordar?
El equipo Scrum no reporta el impedimento.
Por lo tanto el SM desconoce la situación real del ambiente y no puede solucionar oportunamente.
- Preguntar para identificar falencias del equipo.
- Trabajar en conjunto para solucionar
- Fortalecer las habilidades de comunicación
El equipo se estanca con un impedimento fácil de resolver.
El SM puede actuar oportunamente, hablando con el equipo sin afectar el flujo del proceso, brindando soluciones en tiempo real.
- Encontrar soluciones aplicables
- Hacer una pausa para despejar la mente
- Analizar el impedimento de manera creativa con el equipo
Falta capacidad y autoorganización en el equipo.
El SM debe conocer la cultura y el contexto organizacional, procesos, proyectos y otros equipos de trabajo para apoyarse y buscar una solución al impedimento.
- Buscar personal idóneo para completar la capacidad del equipo
- Apoyarse en otros equipos para encontrar la solución al impedimento

Habilidades de enseñanza

El SM debe animar al equipo para aprender nuevos conocimientos, esto permite que el equipo sea multidisciplinario y no se estanque fácilmente. Es necesario que el Scrum Master:

👉 Tip
Aprovecha los momentos informales para enseñar y compartir conocimientos. En ocasiones, una conversación casual puede ser una oportunidad dorada para impartir una lección valiosa. Recuerda, el aprendizaje no siempre tiene que ser estructurado o formal; a veces, los momentos espontáneos dejan las enseñanzas más duraderas.

El Scrum Master como coach y mentor

Como SM sueles entrenar a todo el equipo según sus habilidades y su estilo de trabajo.

Como coach: Su enfoque está en enseñar a los demás a mejorar. Un coach no necesariamente sabe más, busca ayudarte a sacar lo mejor de ti, para que encuentres mejores soluciones con tus propias habilidades.

Como mentor: Su enfoque está en ayudar y guiar a quienes tienen menos experiencia. Un mentor sí es alguien que sabe más que los demás sobre un determinado dominio y usa su conocimiento para guiar a los demás.

Ejemplo: Sara, una nueva integrante del equipo, no está familiarizada con las prácticas de Scrum. El Scrum Master organiza sesiones individuales y grupales de capacitación para enseñarle los conceptos clave. A través de ejercicios prácticos y discusiones, el Scrum Master asegura que Sara comprenda no sólo los procesos sino también los valores y principios detrás de Scrum.


Habilidades complementarias

👉 Tip
Como Scrum Master, predica con el ejemplo en cuanto a la gestión del tiempo. Utiliza herramientas de planificación, establece prioridades claras, aprende a decir "no" cuando sea necesario para asegurarte de que las tareas cruciales se cumplan dentro de los plazos. ¡Recuerda, trabajar inteligentemente es tan importante como trabajar arduamente!
3. Scrum Master: Líder al servicio del equipo Scrum

3.2 - Los valores del equipo

Es importante que entre los miembros del equipo se genere y mantenga una filosofía basada en valores que fomenten la confianza, la comunicación y la entrega de resultados. A continuación, se relacionan los valores que se deben promover en un equipo Scrum:

Nota: El Scrum Master promueve los valores en el equipo.

En un equipo Scrum, los valores juegan un papel central en la construcción de una base sólida para la colaboración y la entrega efectiva.

Ejemplo: Tras la planificación de un Sprint, el equipo se da cuenta de que una de las historias de usuario comprometidas es más compleja de lo que inicialmente pensaban. En lugar de relegarla o dividirla, el equipo decide organizarse de forma diferente, redistribuyendo algunas tareas para asegurarse de que todos los elementos comprometidos se entreguen a tiempo.

Ejemplo: A mitad de un sprint, la dirección de la empresa sugiere una nueva funcionalidad que considera urgente. El equipo decide mantenerse enfocado en las tareas comprometidas para ese sprint y propone discutir la nueva solicitud en la próxima reunión de planificación, asegurando que la dirección actual del sprint no se vea comprometida.

Ejemplo: Al final de un sprint, una característica desarrollada no cumple con los estándares de calidad esperados. En lugar de intentar "maquillar" los resultados o posponer la revisión, el equipo comunica abiertamente la situación en la Revisión del Sprint, expone las causas del problema y propone una estrategia de corrección.

Ejemplo: Un miembro nuevo se une al equipo con una forma diferente de trabajar y con herramientas con las que el equipo no está familiarizado. En lugar de resistirse o desestimar su enfoque, el equipo respeta y se toma el tiempo para entender las ventajas que podría traer este nuevo método, valorando la diversidad de experiencia que el nuevo miembro aporta.

Ejemplo: Después de varios días trabajando en una característica, el equipo se da cuenta de que la solución que estaban desarrollando no es óptima. Aunque revertir y cambiar de rumbo podría parecer desalentador, el equipo decide correr el riesgo, ya que creen que es lo mejor para el producto final. Hacen frente al desafío y trabajan juntos para encontrar una solución más adecuada.

Estos valores no sólo fortalecen la relación del equipo sino que también potencian su rendimiento, creando una cultura de excelencia. Cuando estos valores son asimilados por el equipo de Scrum (reforzados continuamente) y con las personas con las que trabajan, la teoría de Scrum que enfatiza en la transparencia, inspección y adaptación se materializa construyendo confianza.

3. Scrum Master: Líder al servicio del equipo Scrum

3.3 - Los Pilares de Scrum

Si bien, los 12 principios del manifiesto ágil describen una orientación sobre los principios que se siguen en Scrum, hay 5 elementos que son clave para el buen funcionamiento de este marco de trabajo.

Estos pilares junto a los 12 principios del manifiesto ágil se deberían conocer y aplicar por los miembros del Equipo Scrum. El Scrum Master suele ser el responsable de que estos pilares hagan parte de la cultura del equipo.

1. Auto-gestión en el Equipo Scrum

Para Scrum, es altamente recomendable que el equipo tenga la capacidad de auto-gestionarse, esto significa que son los miembros del equipo quienes eligen la mejor opción de llevar a cabo su trabajo sin ser dirigidos por personas externas al equipo.

La auto-gestión es una característica definitoria de los equipos Scrum, centrada en la confianza, autonomía y responsabilidad de sus miembros. Aquí es donde los equipos no sólo toman decisiones sobre cómo abordar su trabajo, sino que también asumen la responsabilidad de esas decisiones.

A continuación, se listan algunos elementos clave que hace posible la Auto-Gestión del Equipo Scrum:

👉 Tip para el Scrum Master
Las mejores prácticas y herramientas evolucionan con el tiempo. Dedica tiempo para la formación continua y asegúrate de que el equipo esté al día con las últimas tendencias y técnicas en Scrum.

Propiedad y responsabilidad colectiva del producto

Para garantizar una colaboración constante y evitar con el tiempo la aparición de una cultura de la culpa, es importante fomentar una propiedad colectiva del producto, esto significa que todo el Equipo Scrum es dueño del producto, y por tanto cualquiera de sus integrantes podría contribuir al desarrollo de cualquier parte del producto aun cuando no haya sido quien lo desarrolló inicialmente.

Así mismo no deberían existir reconocimientos individuales a los miembros del equipo por sus contribuciones al producto.

👉 Tip para el equipo
Evita la cultura de la culpa: En lugar de buscar a quién culpar, enfócate en cómo resolver el problema.

Colaboración de equipo

La colaboración se da gracias a la constante comunicación que existe en los Equipos Scrum, tanto entre sus miembros como con las Partes interesadas del Proyecto, este concepto es parte integral del Manifiesto Ágil "La forma más eficiente y efectiva de transmitir información hacia y dentro del Equipo de Desarrollo es la conversación cara a cara".

El Scrum Master es el rol responsable de garantizar una sana comunicación entre todas las partes interesadas del proyecto, en especial de su Equipo de Desarrollo.

👉 Tip para el equipo
Fomentar una cultura de feedback constante puede simplificar muchos aspectos del trabajo. Las correcciones tempranas y la orientación adecuada evitan la complejidad de corregir errores más adelante.

Se debe considerar que, según la naturaleza del proyecto, las necesidades de la organización e incluso factores externos, se determinan la ubicación de los miembros del Equipo:

Equipos multifuncionales

Los equipos multifuncionales (también llamadas células ágiles) tienen todas las competencias y habilidades necesarias para llevar a cabo el trabajo sin depender de otras personas que no formen parte del equipo.

Contrario a lo que piensa un equipo multifuncional, no se trata de que todos sus integrantes hagan de todo, se trata de que los integrantes adquieran conocimiento en distintas disciplinas (aplicables a los proyectos de la organización) y así puedan contribuir eficazmente con la colaboración.

La realidad es que incluso cuando un equipo sea experto técnico, siempre necesitarán capacitación adicional, así es que el Product Owner deberá decidir si aprobará el dinero y el tiempo para capacitarse o por el contrario serán los miembros del equipo quienes se encargarán del tema.

Colaboración con el cliente

En los proyectos tradicionales, los clientes por lo general se mantenían a distancia y solo se involucraban al principio y al final del proyecto. En Scrum es altamente recomendable que el cliente participe de las revisiones del producto y brinde retroalimentación en todos los puntos de "inspección y adaptación". Esto minimiza el riesgo y le brinda más opciones al cliente y a las partes interesadas.

Por ejemplo, en otros Marcos Ágiles como XP, es obligatorio que el Cliente forme parte del equipo.

El cliente (o sus representantes) deberían trabajar junto al Product Owner para definir las historias de usuario y detallar dichas historias antes o durante las reuniones de planificación.

El cliente y las partes interesadas por lo general participan en la Reunión de Revisión de los Sprint y, dependiendo de la relación entre el cliente y el Product Owner, el Cliente incluso podría participar de algunas reuniones de Retrospectiva de los Sprint.

Gestionar el conocimiento

Dado que los equipos autogestionados se responsabilizan de su aprendizaje y crecimiento, la gestión del conocimiento se convierte en un aspecto crucial. Esto puede tomar la forma de compartir habilidades, aprender nuevas tecnologías o técnicas, o incluso la formación entre pares.

Gestionar el conocimiento permitirá identificar, recopilar, organizar, transferir y retener el conocimiento necesario para dar soporte a todo el personal en sus actividades laborales, para la toma de decisiones bien fundadas y para aumentar la productividad.

👉 Tip para el Developer
Si bien es esencial documentar, es fundamental preguntarte: "¿Esta documentación agrega valor?". Evita la creación de documentos extensos y en su lugar, apunta a documentaciones claras y concisas que sean realmente útiles.

Motivación del equipo

Los equipos Scrum se caracterizan por mantener un enfoque hacia la entrega frecuente de resultados; y aunque los miembros del equipo son conscientes de la responsabilidad que esto implica, existe un factor de fondo que facilita el impulso y el esfuerzo para cumplir con los objetivos: la motivación.

La motivación hace referencia a que los miembros del equipo mantengan determinada conducta y estado de ánimo que propicien las interacciones sanas y el alto rendimiento en el proyecto.

Según cómo se maneje la motivación en el equipo Scrum, eventualmente la motivación extrínseca tiende a convertirse en motivación intrínseca, pues los miembros del equipo van adaptando su conducta y mejorando su rendimiento para cumplir los objetivos sin necesidad de que todo el tiempo estén recibiendo recompensas o algo a cambio.



2. Simplicidad

Scrum no sería considerada una metodología ágil de no ser por su simplicidad, es por ello que se intenta al máximo reducir la burocracia en sus prácticas, se trabaja con los artefactos que son esenciales para el equipo y se sigue un flujo de prácticas simple, sin descuidar todos los elementos necesarios para la correcta gestión del producto, eliminando cualquier trabajo superfluo o que no aporte valor.

👉 Tip para el Product Owner
Simplicidad en la Arquitectura del Producto: Una arquitectura bien diseñada y simple facilita la adición de nuevas características y la corrección de errores. La sobrecarga arquitectónica puede ralentizar considerablemente el desarrollo.

A través de la simplicidad, se puede acelerar la entrega, mejorar la comunicación y reducir los riesgos asociados con la complejidad.

Algunos elementos que hacen posible la Simplicidad en Scrum son:

Maximizar el trabajo no realizado

La simplicidad no solo trata de hacer las cosas de manera simple, sino también de identificar y eliminar cualquier tarea que no sea esencial para alcanzar los objetivos del producto. Es una forma de ser eficiente y focalizado, dedicando recursos solo a lo que realmente importa.

Clara definición de "Hecho" (terminado)

Una definición clara y concisa de lo que significa "hecho" para un elemento del producto ayuda a evitar el trabajo innecesario. Si el equipo entiende perfectamente cuándo un ítem está completo, se evita el esfuerzo extra y las revisiones innecesarias.

Priorización

La simplicidad se logra también a través de una adecuada priorización de las tareas. Al centrarse en lo que realmente aporta valor al cliente o usuario final, el equipo puede evitar la complejidad y concentrarse en lo esencial.

Comunicación efectiva

Las soluciones simples a menudo emergen de una comunicación clara y efectiva. Al fomentar un diálogo abierto y honesto entre los miembros del equipo y con los interesados, se pueden identificar y eliminar obstáculos, malentendidos y redundancias.

👉 Tip para el equipo
Cuanto más dependencias existan entre tareas o equipos, más complejo se vuelve el trabajo. Al minimizar estas dependencias, no solo se simplifica el proceso, sino que se mejora la velocidad y fluidez del trabajo.

Refactorización continua

La simplicidad también está en el código. Refactorizar regularmente el código para mantenerlo limpio y manejable es esencial. Un código más simple es más fácil de entender, modificar y mantener.

Limitar el trabajo en progreso (WIP)

Al limitar la cantidad de trabajo en progreso, los equipos pueden centrarse en finalizar tareas antes de comenzar nuevas. Esto reduce la complejidad y facilita una entrega más rápida y eficiente.

Usar herramientas de software

Las herramientas de software dedicadas a la gestión de proyectos ágiles se han consolidado como elementos cruciales para simplificar procesos y tareas. Estas herramientas ofrecen diversas ventajas, entre las cuales destacan:

👉 Tip para el equipo
No todas las herramientas sofisticadas son las mejores. A veces, las herramientas más simples, pero funcionales, pueden ser más eficaces y fáciles de usar para el equipo.


3. Enfoque en el valor para los interesados

Dentro del marco Scrum, centrarse en entregar valor constante y significativo para los interesados es primordial. Este pilar se fundamenta en la premisa de que la satisfacción del cliente debe ser prioritaria y continua.

Para asegurarse de que el equipo está en la dirección correcta, es esencial tener en cuenta los siguientes puntos:

👉 Tip para el Scrum Master
Reconoce y celebra cuando el equipo entregue valor real a los interesados. Esto motiva al equipo y refuerza la cultura centrada en el valor.
👉 Tip para el Product Owner
Después de la entrega de un incremento o producto completo, realice encuestas para comprender qué tan satisfechos están los interesados y qué áreas se pueden mejorar.


4. Disciplina

La disciplina es esencial en Scrum para garantizar que el equipo trabaje armoniosamente y cumpla con los objetivos trazados. Esta rigurosidad no sólo asegura la satisfacción del cliente sino también el funcionamiento fluido del equipo.

Lineamientos que forman parte de la disciplina del equipo:

👉 Tip para el Scrum Master
La disciplina no significa rigidez: Si un lineamiento o práctica no está funcionando, el equipo debe sentirse empoderado para discutirlo y hacer los ajustes necesarios.

Lineamientos establecidos por el equipo Scrum

Estos son los acuerdos o reglas internas que el Equipo Scrum define para garantizar una colaboración y comunicación eficaces entre sus miembros. Por ser autoimpuestos, estos lineamientos refuerzan el pilar de auto-gestión y aseguran que el equipo se adueñe de su proceso. Gracias al pilar de la auto-gestión, son los miembros del Equipo Scrum, quienes establecen sus propios lineamientos, claro, considerando el cumplimiento de las reglas establecidas por la organización.

Los lineamientos del equipo suelen registrarse en un “Plan de Colaboración del equipo Scrum”. Estos lineamientos pueden abordar aspectos como los métodos y herramientas de comunicación preferidos, los horarios de las reuniones, la asignación de roles específicos dentro del equipo, penalizaciones por incumplimientos, los valores del equipo, o las normas sobre cómo y cuándo se realizarán ciertas tareas.

👉 Tip para el Scrum Master
Los lineamientos pueden requerir ajustes a medida que el equipo madura. Dedique tiempo en las retrospectivas para revisar y actualizar estos acuerdos.

Lineamientos establecidos por la organización (reglas de negocio):

Estas son las directrices o reglas que la organización establece, y que todos los equipos, incluidos los Equipos Scrum, deben seguir. Pueden abordar áreas como los estándares de codificación, las políticas de seguridad de la información, los procedimientos de aprobación y revisión, entre otros. Estas reglas aseguran que, aunque el equipo tenga autonomía, su trabajo sigue estando alineado con los objetivos y requisitos más amplios de la organización.

Bloques de tiempo (time-box)

El marco de Scrum hace un uso extensivo del concepto de time-boxing, donde cada evento tiene una duración máxima asignada. Este enfoque garantiza que las ceremonias o eventos no se prolonguen innecesariamente y que el trabajo se realice de manera puntual y eficiente. Respetar estos bloques de tiempo es crucial para mantener la disciplina y el ritmo del equipo.

Algunas ventajas de establecer y cumplir los Bloques de Tiempo asignado son los siguientes:

Recuerda los bloques de tiempo de los eventos de Scrum:

Definición de terminado (DoD) y criterios de aceptación

La Definición de Terminado es una lista acordada de criterios que deben cumplirse para que una tarea o característica se considere "terminada". Asegura que todo el trabajo cumpla con un estándar mínimo de calidad y esté listo para ser entregado al cliente o puesto en producción.

Los criterios de aceptación, por otro lado, son requisitos específicos que una tarea o característica debe cumplir para ser aceptada por el cliente. Estos criterios ayudan a aclarar las expectativas y garantizar que el equipo esté trabajando hacia el mismo objetivo.

👉 Tip para el Developer
Aunque puede ser tentador manejar múltiples tareas a la vez, la multitarea puede disminuir la calidad y eficiencia del trabajo. Enfócate en una tarea a la vez y asegúrate de que se complete según la Definición de Terminado.


5. Desarrollo iterativo

Dentro de Scrum, el proceso de trabajo se lleva a cabo mediante ciclos repetitivos conocidos como Sprints. Estos Sprints son el núcleo del enfoque iterativo de Scrum, permitiendo flexibilidad y adaptabilidad a lo largo del proyecto.

A diferencia de un enfoque de desarrollo tradicional, que busca tener un plan detallado desde el comienzo, el enfoque iterativo reconoce la naturaleza cambiante del desarrollo de productos y servicios. Al adoptar un enfoque de desarrollo iterativo, Scrum permite a los equipos responder a los cambios y adaptarse a las necesidades emergentes de los clientes, el mercado y la organización.

Ventajas del Desarrollo Iterativo:

👉 Tip para el Scrum Master
Promueve una cultura donde cada miembro del equipo esté comprometido con la mejora continua, no sólo en términos del producto sino también en términos de procesos y colaboración.
3. Scrum Master: Líder al servicio del equipo Scrum

3.4 - El Scrum Master y los eventos

En Scrum cada evento (ceremonia) tiene un propósito específico, diseñado para maximizar la transparencia, la colaboración y la eficiencia. El Scrum Master, a menudo considerado como el guardián de la agilidad del equipo, juega un papel esencial en estos eventos. Su responsabilidad no se limita a la simple organización o facilitación; va mucho más allá, actuando como un catalizador que asegura que cada ceremonia genere el máximo valor, alineando al equipo con los valores de Scrum.

En esta sección, exploraremos en detalle cómo el Scrum Master navega por cada evento, qué se espera de él y cómo su participación activa puede marcar la diferencia en la dinámica y resultados del equipo Scrum.

El Scrum Master en la Planificación del Sprint

Caso práctico: Durante una sesión de planificación del sprint, algunos desarrolladores muestran confusión sobre una historia de usuario. El Scrum Master, Pablo, interviene: "Vamos a aclarar esta historia antes de continuar". Facilita una sesión de preguntas rápidas con el Product Owner, María, eliminando las dudas. Cuando llega el momento de las estimaciones, Pablo propone un "Planning Poker", logrando consenso. Al finalizar, recalca la importancia de mantener la comunicación abierta durante el Sprint.

👉 Tip para el Scrum Master
Asegúrate de que todas los elementos seleccionados para el Sprint estén claros y bien definidos. Si notas que hay dudas o incertidumbre, tómate un momento para clarificarlas con el Product Owner antes de que el equipo empiece a estimar.

El Scrum Master en el Daily

Caso práctico: Al tercer día del Sprint, los Developers se reúnen puntualmente para el Daily Scrum. Pablo, el Scrum Master, se asegura de que todos estén presentes y de que se inicie a tiempo. Cuando Sofía, una Developer, menciona que está teniendo problemas técnicos con una herramienta, Pablo toma nota del impedimento para tratarlo después del Daily. Aunque Pablo está trabajando en una tarea específica de este Sprint, mantiene su participación breve y centrada, como si fuera otro Developer. Al finalizar, Pablo recuerda a todos la importancia de ser consistentes con la hora y el lugar del Daily, reforzando la rutina y previsibilidad.

👉 Tip para el Scrum Master
Si durante el Daily un Developer empieza a profundizar demasiado en un impedimento, tú como Scrum Master debes intervenir amablemente y recordar al equipo que el Daily tiene una duración limitada. Sugiere abordar el impedimento en detalle justo después del Daily o programar un momento específico para tratarlo, asegurando que el foco del Daily se mantenga en la actualización rápida de cada miembro del equipo.

El Scrum Master durante el desarrollo del Sprint

Caso práctico: A mitad del Sprint, Pablo, el Scrum Master, nota que el equipo está un poco detrás de lo planificado. Un impedimento principal es la falta de acceso a un servidor que se identificó en el Daily. Pablo toma la iniciativa, habla con el equipo de infraestructura y resuelve el acceso al servidor al día siguiente.

Días después, observa una discusión entre Sofía y Jorge (dos Developers) sobre la mejor manera de implementar una función. Pablo facilita una breve sesión para comprender los puntos de vista y logra que ambos lleguen a un acuerdo, manteniendo el ambiente armonioso.

Finalmente, al aproximarse el final del Sprint, Pablo realiza pequeñas revisiones con los Developers para asegurarse de que todos los elementos del trabajo estén alineados con los criterios de aceptación y la Definición de Terminado (DoD).

👉 Tip para el Scrum Master
Mantente disponible y accesible. Los impedimentos pueden surgir en cualquier momento, y tu capacidad para actuar rápidamente puede hacer la diferencia entre un Sprint exitoso y uno problemático.

El Scrum Master en la Revisión del Sprint

Caso práctico: Al finalizar el Sprint, es momento de la revisión. Pablo, el Scrum Master, asegura que la sala de reuniones está lista y que todos los recursos tecnológicos funcionan correctamente para evitar interrupciones.

Mientras Carla, el Product Owner, se prepara para revisar las características que completaron los Developers durante el Sprint, Pablo se mantiene alerta para moderar y garantizar que se respeten los tiempos y que todos los miembros tengan la oportunidad de participar.

Pablo también se encarga de recopilar comentarios y preguntas que surgen durante la presentación, y se asegura de que, al finalizar, el equipo y los stakeholders (si los hay) discutan el progreso en relación con el Objetivo de Producto.

Una vez terminada la revisión, Pablo recoge feedback sobre la revisión, buscando oportunidades de mejora para las próximas sesiones.

👉 Tip para el Scrum Master
No te enfoques únicamente en lo que se completó: Asegúrate de celebrar los logros del equipo y reconoce los esfuerzos. Al mismo tiempo, fomenta una discusión abierta sobre lo que no se logró y las razones detrás de ello, para crear un ambiente de aprendizaje continuo.

El Scrum Master en la Retrospectiva del Sprint

Caso práctico: Tras la Revisión del Sprint, Pablo, el Scrum Master, organiza la Retrospectiva. Pablo comienza recordando la importancia de la sinceridad y el respeto mutuo durante el evento, y decide emplear la técnica "Estrella de Retro" para abordar distintas facetas del trabajo del equipo. Como facilitador, cuando un punto particularmente delicado sale a la luz, Pablo interviene para asegurarse de que la discusión sea productiva y enfocada en las soluciones, y va tomando notas de lecciones aprendidas y áreas de mejora. Al final, se asegura de que todos los acuerdos se registren y sean visibles para el próximo Sprint. Agradece al equipo por su compromiso y les anima a implementar las mejoras acordadas.

👉 Tip para el Scrum Master
Cultiva un ambiente seguro y de confianza: Recuerda que la Retrospectiva no es un espacio para señalar errores individuales, sino para identificar áreas de mejora como equipo. Fomenta la empatía y escucha activa, evitando juicios prematuros o asumir posturas defensivas.
3. Scrum Master: Líder al servicio del equipo Scrum

3.5 - Técnicas útiles para el Scrum Master

Para guiar el Daily Scrum

Una de las dudas al momento de llevar a cabo el daily es saber quién se supone que debe hablar primero y en qué orden, cómo mantener la atención, por lo que se proponen las siguientes estrategias:

Pasa la ficha (token de habla)

Esta técnica busca estructurar la comunicación y asegurar una participación activa y ordenada de todos los miembros. Se utiliza un objeto (pelota, juguete, etc.) para determinar quién habla a continuación. Sólo la persona que tiene el objeto puede hablar y lo entrega aleatoriamente a otra persona para asegurar que todos prestan atención. Con esta estrategia se evitan interrupciones, se asegura que todos sean escuchados y puede agregar un elemento de diversión a la reunión que puede aliviar la tensión y hacer que la reunión sea más amena.

Toma una carta

Esta es una técnica útil para evitar la monotonía y dar a todos una oportunidad de hablar en diferentes órdenes cada día. Al comienzo del Daily, se reparten cartas numeradas a los miembros del equipo. El número en la carta determinará el orden de habla.

Caminar por el tablero

En lugar de que cada miembro del equipo simplemente responda las tres preguntas tradicionales, el equipo puede "caminar" por el tablero de Scrum, abordando cada historia de usuario o tarea, desde la más alta prioridad hacia abajo (será imprescindible que el tablero esté actualizado). Con esta estrategia se mantiene el enfoque en el trabajo real, se pueden identificar bloqueos de manera efectiva y se garantiza que las tareas más críticas sean discutidas.

Estas técnicas no son excluyentes y se pueden combinar según las necesidades del equipo. Lo más importante es mantener el propósito del Daily Scrum: asegurarse de que el equipo esté alineado, identificar bloqueos y tomar medidas para avanzar eficazmente hacia el objetivo del sprint.

Recomendaciones adicionales para el Daily Scrum

A continuación se presentan recomendaciones para mejorar la ejecución del daily, lograr que se cumpla con los objetivos de este evento, y mantener la atención del equipo:

Para guiar la Retrospectiva del Sprint

Es muy común que el equipo pueda perder el interés en participar en la retrospectiva por considerarla aburrida, por lo que existen diversas técnicas que facilitan la transparencia y la adaptación.

Retrospectiva de las 4L's

Algunos miembros del equipo suelen decir cosas como "si tan solo tuviéramos...", "Ojalá tuviéramos...", o tal vez digan cosas como "adivina lo que descubrí ...", "realmente me encantó ..."

La retrospectiva de 4Ls está diseñada para que las personas compartan esos pensamientos con el objetivo de mejorar continuamente.

Retrospectiva del barco rápido (speed boat)

Speed Boat es una técnica en la que los miembros del equipo simulan que son tripulantes en un barco, el cual debe llegar a una isla (que representa el Objetivo del Producto). Es una forma visual y metafórica de identificar lo que ayuda y obstaculiza al equipo.

Nota: Se pueden usar notas adhesivas para identificar cada aspecto.

Comenzar, Detener, Continuar (Start, Stop, Continue)

Los miembros del equipo escriben acciones que les gustaría que el equipo comience a hacer, detenga y continúe haciendo. Esta técnica es sencilla, pero efectiva, para identificar rápidamente áreas de mejora y aquellas en las que el equipo está yendo bien.

Mad, Sad, Glad

Esta técnica busca revelar las emociones del equipo sobre eventos, decisiones y circunstancias que ocurrieron durante el Sprint. Se prepara un tablero dividido en tres secciones: Mad (Enojado), Sad (Triste) y Glad (Feliz). Se puede usar un tablero físico con post-its o mediante herramientas digitales.

Cada miembro del equipo reflexiona sobre el sprint pasado y escribe en tarjetas o post-its individuales las cosas que les hicieron sentir enojados, tristes o felices (una tarjeta por cada sentimiento); y colocan sus tarjetas en la sección correspondiente del tablero. Cuando todos hayan terminado, uno por uno explica brevemente por qué escribió cada punto.

Una vez que todos han compartido sus sentimientos se discuten los patrones o temas recurrentes que surgen. ¿Hay muchos post-its sobre un tema particular en la sección "Mad"? Eso podría ser una señal de un problema que necesita ser abordado. Al profundizar en las causas subyacentes de los sentimientos, especialmente en los que generan emociones fuertes,puede revelar problemas más profundos o áreas de mejora.

Basándose en la discusión, se identifican las acciones específicas que el equipo puede tomar para abordar los problemas o circunstancias que causaron emociones negativas y para reforzar lo que causó emociones positivas.

Estrella de Retro (Starfish Retrospective)

Esta técnica ayuda al equipo a reflexionar sobre diferentes áreas y decidir qué deben comenzar a hacer, dejar de hacer, continuar haciendo, hacer más y hacer menos.

Dibuja una estrella o estrella de mar en un tablero con cinco secciones: "Comenzar", "Detener", "Continuar", "Hacer más" y "Hacer menos". Cada miembro del equipo escribe en tarjetas o post-its sus opiniones o comentarios sobre lo que el equipo debe comenzar a hacer, dejar de hacer, etc. y los colocan en la sección correspondiente de la estrella.

Se conduce una discusión sobre cada sección. ¿Hay consenso sobre ciertos puntos? ¿Hay ideas contradictorias? Se identifican y priorizan las acciones específicas que surgieron de la discusión.

3. Scrum Master: Líder al servicio del equipo Scrum

3.6 - Emisores de información útiles para el Scrum Master

El término "emisor de información" no hace parte de los conceptos core de Scrum. Sin embargo, en el contexto de la comunicación y la gestión ágil de producto, los emisores de información son herramientas diseñadas para mostrar el estado actual de los Sprints o del producto en su totalidad.

Estos instrumentos ofrecen una visualización clara y concisa de tareas, progresos y obstáculos, facilitando la transparencia y permitiendo un seguimiento y control efectivos. Sirven como medios esenciales para que todos los involucrados, desde el equipo Scrum hasta los stakeholders, tengan una comprensión clara del avance y estado del trabajo.

El Scrum Board

El Scrum Board o también conocido como tablero Scrum es una adaptación del tablero Kanban que nos permite dar seguimiento a cada Sprint Backlog dentro del equipo Scrum.

El Scrum Board es un emisor de información que le permite al Equipo garantizar la transparencia en los Sprints, mantiene la coordinación y permite realizar al Scrum Master sus labores de Inspección.

Comúnmente está compuesto por 4 columnas: Pendiente (to do), En Progreso (in progress), En Prueba (testing), Terminado (done).

scrum-board

Cada elemento por desarrollar debe ponerse en una tarjeta individual, y dado que el Scrum Board se actualiza constantemente, todas las tarjetas deberán pasar por las 4 columnas. (No se pueden hacer saltos de columnas).

Aclaraciones sobre el Scrum Board

Burndown chart del Sprint

El “Burndown Chart” es un emisor de información que muestra la cantidad de trabajo pendiente en el Sprint actual en función del tiempo.

Es un emisor gráfico de 2 dimensiones:

burndown-chart

Al inicio del Sprint, la cantidad de trabajo restante es la más alta y, a medida que se avanza el Sprint, esta cantidad debería disminuir, "quemándose" (burn) el trabajo hasta llegar a cero al final del Sprint.

El Burndown Chart es una herramienta esencial para los equipos Scrum ya que les permite visualizar diariamente su progreso, identificar posibles problemas y ajustar su ritmo de trabajo si es necesario para cumplir con el Objetivo del Sprint (Sprint Goal).

Aclaraciones sobre el Burndown Chart

Diagrama de flujo acumulado

El Diagrama de Flujo Acumulado (CFD - Cumulative Flow Diagram) es un emisor de información bastante útil para la elaboración de informes y el seguimiento de los resultados del proyecto; y se originó a partir de la metodología Kanban.

Este emisor de información muestra el progreso del producto respecto a los ítems del Product Backlog, y se construye un único diagrama de flujo acumulado por producto.

Este gráfico se compone de dos ejes; el eje vertical "Y" muestra la cantidad de ítems (como tareas, características, user Historias de Usuario). El eje horizontal "X" muestra el tiempo, usualmente días, semanas o meses.

flujo-acumulado

Cada área coloreada en el gráfico representa un estado o categoría diferente del flujo de trabajo:

Aclaraciones sobre el Diagrama de Flujo Acumulado:

Registro de obstáculos/impedimentos

El registro de obstáculos, o también llamado registro de impedimentos es una herramienta que se utiliza para llevar un registro y seguimiento de los obstáculos o bloqueos que impiden o ralentizan el progreso del equipo Scrum. Estos impedimentos pueden ser cualquier cosa que obstruya el flujo de trabajo del equipo, desde problemas técnicos hasta cuestiones organizativas.

Un impedimento es cualquier factor que impide que el equipo alcance su productividad potencial. Puede ser algo interno, como un desafío técnico o falta de habilidades específicas, o externo, como la espera de una aprobación de otro equipo o departamento.

Mantener un registro de impedimentos ayuda a asegurar que los problemas no se pasen por alto y que se les dé la debida prioridad. También proporciona una visión histórica que puede ser útil para futuras retrospectivas y para identificar patrones o problemas recurrentes.

Aclaraciones sobre el registro de impedimentos

Registro de lecciones aprendidas

Registrar las lecciones aprendidas es una parte fundamental para la mejora continua de las prácticas Scrum dentro de una organización. En esta herramienta se registran las prácticas, experiencias, conocimientos y recomendaciones que favorecieron el desempeño del equipo en términos de costo, tiempo y calidad, también se registran aquellos errores que se cometieron y a los que se les dió solución. Estas soluciones hacen parte de las lecciones aprendidas, útiles para resolver problemas similares en el futuro.

Las lecciones aprendidas, además, favorecen el aprendizaje organizacional y la gestión del conocimiento. Así que las lecciones aprendidas deben almacenarse, alimentarse y transferirse de manera apropiada. Para esto, es importante que cada lección tenga una estructura para facilitar su búsqueda, como por ejemplo:

Aclaraciones sobre el registro de lecciones aprendidas:

Portafolio de proyectos

El portafolio de proyectos consiste en un registro de información histórica, esta información podría ser útil (por ejemplo) cuando la organización empieza un proyecto similar a uno que haya ejecutado en el pasado y por tanto algunos elementos sean similares, esto reduce el tiempo de planificación, desarrollo, revisión, implementación y/o cierre, además de hacer uso de las lecciones aprendidas y brindar los insumos para la gestión del conocimiento.

Al igual que las lecciones aprendidas, el portafolio de proyectos debería tener información detallada y organizada que permita su alimentación, almacenamiento y transferencia. Un software específico para la gestión del portafolio de proyectos es útil, por lo que una organización debería considerar esta posibilidad.

Algunos de los elementos que podrían incluirse en el portafolio de proyectos son:

4. Product Owner: Gestión ágil de productos

La responsabilidad del Product Owner es crucial en Scrum, fungiendo como el principal enlace entre las partes interesadas y el equipo Scrum, con la meta de maximizar el valor generado a través del desarrollo del producto. Un Product Owner posee la autoridad y el conocimiento profundo necesarios para articular y defender las necesidades y expectativas de los stakeholders con precisión. En este capítulo, exploraremos las responsabilidades, habilidades y actividades de un Product Owner. Esto brindará una comprensión ampliada que complementa lo ya discutido en el modelo Core de Scrum, orientándote en cómo un Product Owner puede liderar efectivamente la visión del producto a través de colaboración efectiva, liderazgo estratégico y toma de decisiones basada en datos. Puntos clave de este capitulo: - Comprender la importancia estratégica de la responsabilidad del Product Owner en el desarrollo de productos ágiles. - Identificar las habilidades cruciales que un Product Owner necesita cultivar para liderar con eficacia. - Profundizar en las actividades específicas y diarias que definen la labor del Product Owner. - Analizar cómo un Product Owner puede funcionar como un puente eficaz entre el equipo Scrum y las partes interesadas, garantizando una entrega de valor maximizada.

4. Product Owner: Gestión ágil de productos

4.1 - Gestión ágil de producto

La gestión de productos, o "Product Management" en inglés, es una disciplina que se centra en guiar el desarrollo, la estrategia y la entrega de productos.

La gestión de producto se pueden manejar con enfoque tradicional o con enfoque ágil: El Agile Product Management (Gestión ágil de producto) está diseñado para entornos y mercados que cambian rápidamente, donde la adaptabilidad y la respuesta rápida son esenciales. Mientras que el Product Management tradicional puede ser más adecuado para industrias o productos donde los requisitos son menos volátiles y el desarrollo puede planificarse con bastante antelación.

Muchas empresas modernas están adoptando un enfoque ágil, al reconocer los beneficios de la adaptabilidad y la iteración rápida.

La gestión ágil de producto permite establecer estrategias para crear productos en un entorno ágil, manteniendo un enfoque adaptable para que la organización y el equipo propiamente puedan responder rápidamente a la retroalimentación de los clientes y crear mejores productos.

A diferencia de las técnicas de desarrollo tradicionales, la gestión ágil se centra en la adaptabilidad, permitiendo que el equipo responda rápidamente a la retroalimentación de los clientes.

👉 Tip para el Product Owner
Valora más una entrega temprana y frecuente que esperar hasta que el producto esté "perfecto".

Beneficios de la gestión ágil de producto

La gestión ágil proporciona un enfoque más flexible en comparación con la planificación y el desarrollo tradicional, lo que permite que se construyan productos en incrementos cortos.

Algunos beneficios clave de la gestión ágil de productos:

👉 Tip para el Scrum Master
Anima al equipo a adoptar una mentalidad de mejora y aprendizaje constante, utilizando cada sprint y retroalimentación como una oportunidad de crecimiento.

Ecosistema de la gestión ágil de producto

Cada producto requiere un enfoque único y personalizado, tiene sus propios objetivos y retos, lo que se traduce en una gestión de productos basada en lograr la conexión entre las expectativas de negocio, una gran experiencia de usuario y el aprovechamiento de la tecnología.

El diseño y la investigación de la Experiencia de Usuario aseguran que el producto esté alineado con las necesidades y expectativas del usuario y del negocio. Las Expectativas de Negocio definen la dirección y los objetivos, proporcionando un marco dentro del cual el diseño y la tecnología deben operar. La Tecnología es el medio que permite que las expectativas respecto a la Experiencia de Usuario y del negocio se materialicen, proporcionando soluciones que cumplan con las expectativas del usuario y los objetivos de negocio.

👉 Tip para el equipo
En escenarios de desarrollo de software es importante implementar técnicas de Integración Continua y Entrega Continua (CI/CD) para acelerar el proceso de desarrollo y despliegue.

La gestión ágil de producto en una organización

El enfoque jerárquico en comparación con el enfoque de la gestión ágil de producto abarca diferencias sustanciales en cómo se organizan, operan y toman decisiones las organizaciones:

Enfoque Jerárquico Enfoque de gestión ágil de producto
Toma de decisiones Las decisiones vienen desde los niveles superiores de la organización y se transmiten hacia abajo.
Demora en la toma de decisiones por necesidad de aprobación en múltiples niveles.
Decisiones descentralizadas tomadas por Product Owner en colaboración con su equipo y stakeholders.
Se promueve la autonomía y la toma de decisiones basadas en datos.
Estructura Departamentos o divisiones con roles claramente definidos. Equipos multifuncionales centrados en productos o características específicas.
Comunicación Comunicación vertical (de arriba hacia abajo y viceversa).
Silos de información y desafíos en la comunicación.
Comunicación abierta y transparente entre todos los niveles y departamentos.
Respuesta al cambio Los cambios suelen ser más lentos y requieren aprobación en varios niveles. Los cambios pueden implementarse rápidamente en función de la retroalimentación del usuario y las métricas del producto.
Cultura Centrada en procesos, estructuras y cumplimiento de tareas asignadas. Centrada en el valor para el cliente y negocio, y la entrega continua de características útiles.

Principios de la gestión ágil de producto

Riesgos de no adoptar la gestión ágil de producto

¿Qué debo evitar en el Agile Product Management (Gestión ágil de producto)?

El Product Management es un área crucial que determina en gran medida el éxito de un producto. Sin embargo, hay ciertas trampas en las que como Product Owner puedes caer y que se deben evitar:

Actores involucrados en la gestión ágil de producto

En la gestión ágil de producto existen actores complementarios al equipo Scrum, que son necesarios y usualmente definidos en las organizaciones para cubrir todas las necesidades y requerimientos de las partes interesadas:

Equipo Scrum:

En su concepción más básica, Scrum se centra en cómo un equipo puede trabajar de manera eficiente para entregar productos de alta calidad en ciclos iterativos y rápidos. Para hacerlo, Scrum establece tres responsabilidades: Product Owner, Developers y Scrum Master. Cada uno contribuye al flujo ágil de trabajo.

Sin embargo, cuando se trabaja con Scrum en un entorno empresarial real, con múltiples productos, interdependencias y expectativas de diversas partes interesadas, rápidamente nos damos cuenta que existen muchas otras consideraciones que no son cubiertas por el equipo Scrum.

Actores organizacionales o del cliente:

El equipo Scrum no trabaja totalmente aislado: existen roles adicionales, a menudo anclados en la estructura organizacional o en las necesidades del cliente, que desempeñan funciones críticas para asegurar que los esfuerzos del equipo Scrum se mantengan alineados con los objetivos del negocio y las expectativas del cliente.

Estos roles organizacionales o del cliente actúan como puentes, facilitando la comunicación, alineación y toma de decisiones entre el equipo Scrum y el ecosistema empresarial más amplio en el que operan. Entre los roles adicionales comúnmente podemos encontrar:

👉 Tip para el Product Owner
Asegúrate de mantener una comunicación fluida con los actores externos al equipo (Business Managers, Line Managers, Analistas de Negocio) para garantizar que la visión del producto esté alineada con los objetivos de negocio.
4. Product Owner: Gestión ágil de productos

4.2 - El Product Owner y los eventos

En Scrum, cada evento (ceremonia) está diseñado con un propósito específico para maximizar la transparencia, la colaboración y la eficiencia. El Product Owner, es fundamental para representar la voz del cliente y los intereses del negocio, y desempeña un papel crucial en estos eventos.

Su responsabilidad va más allá de simplemente definir y priorizar el trabajo; es el vínculo esencial que asegura que el equipo esté trabajando en las características más valiosas, alineando la entrega de producto con los objetivos del negocio.

En esta sección, exploraremos en detalle cómo el Product Owner se involucra en cada evento, qué se espera de él y cómo su aporte activo puede influir positivamente en la dinámica y los resultados del equipo Scrum.

El Product Owner en la Planificación del Sprint

Caso práctico: Durante la planificación del sprint, el equipo está indeciso sobre qué funcionalidades priorizar. El Product Owner, Carlos, comparte recientes feedbacks de clientes y argumenta: "Nuestro principal competidor acaba de lanzar una funcionalidad similar, y debemos responder". Desglosa los elementos del Product Backlog, aclarando cualquier duda. Luego, al definir el Sprint Backlog, surge un debate sobre la carga de trabajo. Carlos, con base en la prioridad y la visión del producto, guía al equipo para acordar un Sprint Goal centrado en el impacto y valor para el usuario.

👉 Tip para el Product Owner
La preparación es clave: Asegúrate de entender muy bien los elementos del Product Backlog que has pre-seleccionado para discutir en la Planificación del Sprint, y ten a mano toda la información relevante para aclarar cualquier duda que puedan manifestar los Developers.
También asegúrate de que las historias de usuario y las tareas estén bien definidas, claras y priorizadas. Las más prioritarias deben tener suficiente detalle para que el equipo pueda trabajar en ellas.

El Product Owner en el Daily

Nota aclaratoria: Si el Product Owner está trabajando activamente en los elementos del Sprint, entonces participa como un Developer, de lo contrario no participa en este evento.

En caso que el Product Owner participe del Daily, es posible que pueda:

Caso práctico: Durante un Daily, el equipo de desarrolladores discute un desafío relacionado con una historia de usuario. No están seguros de cómo implementar una funcionalidad específica. Laura, la Product Owner, quien ocasionalmente asiste a los Dailies, rápidamente comprende la confusión. Después del Daily, aparta a los miembros del equipo involucrados y proporciona una aclaración detallada con ejemplos del comportamiento esperado, resolviendo el desafío. Además, toma nota para mejorar la descripción de historias similares en el futuro.

👉 Tip para el Product Owner
Si decides asistir al daily, escucha activamente pero evita interrumpir o desviar la conversación a menos que sea estrictamente necesario. Si escuchas sobre desafíos o problemas relacionados con el Product Backlog, toma notas para refinar y mejorar el Backlog después del daily.
Si ves que hay confusiones o malentendidos sobre el Product Backlog, busca un espacio después del Daily para resolver las dudas.

El Product Owner durante el desarrollo del Sprint

Caso práctico: Mientras el equipo está a mitad de camino en el Sprint actual, Tomás, el Product Owner, ya está en conversaciones con un stakeholder sobre las características de un futuro elemento que se desarrollará para el siguiente sprint. Tras obtener un entendimiento claro, programa una reunión de refinamiento con dos Developers para abordar este elemento. Laura, una de las Developers, sugiere una implementación que podría simplificar el trabajo. Tomás ajusta el elemento en el Product Backlog. Cuando llega el momento de la planificación del siguiente sprint, este elemento se discute con mayor fluidez y claridad, gracias a la planificación en paralelo que Tomás llevó a cabo.

👉 Tip para el Product Owner
Inicia el refinamiento y priorización de los elementos de los próximos sprints con anticipación, esto garantiza que estén listos cuando llegue el momento de la Planificación. Al trabajar en paralelo, es crucial que tanto el equipo como las partes interesadas tengan una visión clara del producto y cómo encajan las piezas.

El Product Owner en la Revisión del Sprint

Caso práctico: Durante la revisión del sprint se presenta una funcionalidad de una aplicación de e-commerce. Un stakeholder clave menciona que, aunque la funcionalidad es lo que se pidió, el diseño podría ser más intuitivo para usuarios no técnicos. Laura, la Product Owner facilita el diálogo, para entender mejor la situación y añade esta observación al Product Backlog. Adicionalmente se encuentra un elemento en deuda técnica, por lo que Laura, reajusta el Product Backlog según el feedback recibido.

👉 Tip para el Product Owner
Si se identifica deuda técnica, trata de comprender su origen y considera estrategias para gestionarla en futuros sprints. También asegúrate de registrar las observaciones y feedback para que puedan ser considerados en futuras decisiones y planificaciones.

El Product Owner en la Retrospectiva del Sprint

Caso práctico: En la retrospectiva, Miguel, el Product Owner, resalta cómo el equipo logró superar un desafío técnico particular durante el Sprint. Sin embargo, surge que algunos Developers sintieron que no se comunicaron suficientemente bien los objetivos de negocio detrás de ciertas tareas. Patricia, una Developer, menciona que esto llevó a algunas decisiones técnicas que, de haber tenido toda la información, habrían sido diferentes. Miguel reconoce esta brecha y propone sesiones breves de alineación antes de cada Sprint para garantizar que el contexto del negocio esté claro. El equipo acuerda intentarlo en el próximo Sprint y evaluar su efectividad en la siguiente retrospectiva.

👉 Tip para el equipo
La Retrospectiva NO es un espacio para culpar, sino para identificar oportunidades de mejora.
4. Product Owner: Gestión ágil de productos

4.3 - Las Historias de Usuario

Las Historias de Usuario (User Story) son la forma recomendada en entornos ágiles para escribir los requisitos del producto desde la perspectiva del usuario. Dado que son afirmaciones breves, simples y fáciles de entender, resultan en una mejor comunicación entre los Stakeholders y el equipo Scrum.

Una de las principales ventajas de las Historias de Usuario es su estructura simplificada y orientada a la acción. Debido a que se centran en entender "¿quién solicita la funcionalidad?", "¿qué necesita/requiere?" y "¿por qué o para qué lo necesita?", las Historias de Usuario proporcionan una vista clara y contextualizada de lo que se espera, eliminando ambigüedades comunes en los requisitos tradicionales.

Los criterios de aceptación, que acompañan a cada Historia de Usuario, definen las condiciones específicas que deben cumplirse para que la historia se considere satisfactoriamente implementada o desarrollada. Actúan como una guía para el equipo, aterrizando las expectativas del Product Owner sobre el comportamiento o funcionalidad que debe tener esa historia. Mientras que, la Definición de Terminado (DoD) es la que establece cuándo una historia o tarea se considera completa en su totalidad.

Las Historias de Usuarios centran la atención en los usuarios finales, por lo que no utilizan un lenguaje técnico, con el fin de facilitar el entendimiento para los usuarios y asimismo ofrecer un contexto suficiente para guiar el esfuerzo de los Developers.

Mike Cohn, uno de los pioneros en el desarrollo ágil, menciona que "Las historias de usuario permiten a los equipos trabajar en un lenguaje compartido, y eso hace que toda la experiencia de desarrollo sea más orientada al usuario y al valor. En lugar de ser una mera lista de tareas, las historias son llamadas a la acción para resolver desafíos específicos para los usuarios".

Estructura de una Historia de Usuario

Las Historias de Usuario suelen expresarse como una frase simple y breve que cumple con la siguiente estructura:

Como: Describe el Rol del Stakeholder que solicita (o usaría) la funcionalidad o requerimiento.

Quiero: Describe la necesidad o requerimiento del usuario, por lo general, es una frase corta.

Para: Describe el beneficio esperado por el Stakeholder una vez se desarrolle el requerimiento

Ejemplos de Historias de Usuario

Como: Cliente, Quiero: pagar mi suscripción mensual vía sitio web por medio de transferencia bancaria o tarjeta de crédito, Para: evitar el desplazamiento hasta la sucursal de pago.

Como: Supervisor de ventas, Quiero: consultar un listado de los pedidos de venta que han sido registrados y aún no han sido procesados, Para: Tener un reporte detallado a la mano.

Como: Ejecutivo de cuenta, Quiero: consultar los datos de un cliente suministrándole al sistema únicamente su documento de identidad o código de cliente, Para: facilitar el proceso de búsqueda y reducir el tiempo de atención.

Como: asesor de ventas, Quiero: disponer de una diadema inalámbrica, Para: poder levantarme regularmente de mi puesto y disminuir el estrés y el cansancio.

Componentes adicionales de una Historia de Usuario

Una Historia de Usuario puede tener componentes adicionales que permitan mejorar su entendimiento tanto para el usuario como para los Developers. Estos componentes también garantizan una ejecución precisa y acorde a las expectativas. Usualmente estos componentes son:

1. Criterios de aceptación (detalle técnico)

Microsoft define a los criterios de aceptación como las condiciones que un producto de software debe satisfacer para ser aceptado por un usuario, cliente o stakeholder.

Para Google, son estándares pre-establecidos o requerimientos que un producto o proyecto debe satisfacer.

Cada historia de usuario debe ir acompañada de sus criterios de aceptación. Estos criterios son esenciales para garantizar que todos en el equipo tengan el mismo entendimiento de lo que se espera. Ayudan a delimitar el alcance de una historia y a definir cómo se verificará que se ha cumplido con la necesidad o requerimiento descrito.

Concretamente en Scrum, se los define como un conjunto de sentencias redactadas de tal manera que conduzcan a una respuesta clara de "aceptado/rechazado". Detallan las especificaciones técnicas de cada Historia de usuario o Tarea.

El Product Owner es el responsable de redactar los criterios de aceptación para cada Historia de Usuario en conjunto con el cliente y/o los interesados, para posteriormente confirmarlos con los Developers antes de iniciar el desarrollo. Esta confirmación se realiza durante la Planificación del Sprint.

Los criterios de aceptación ayudan a los Developers a entender el funcionamiento del producto, de manera que estimarán mejor el trabajo necesario, además de servir como guía para tomar decisiones más acertadas de acuerdo con lo que se espera de cada Historia de Usuario.

Un criterio de aceptación debe poder probarse o testearse. Cuando no es posible probar algún criterio de aceptación es un claro indicio de una mala redacción.

Se debe tener en cuenta que al probar una Historia de Usuario frente a un criterio de aceptación se obtiene una respuesta binaria: Cumple o No cumple; no existe el concepto de cumplir parcialmente un criterio de aceptación.

Algunos beneficios de contar con buenos criterios de aceptación:

👉 Tip para el Developer
No esperes hasta la Planificación del Sprint para hacer preguntas. Si un criterio de aceptación no especifica algo, no lo asumas. Es mejor preguntar y obtener claridad.
Si durante el desarrollo encuentras que un criterio de aceptación no es viable o requiere mucho más trabajo del estimado, comunica esto al Scrum Master lo antes posible.

Una manera opcional de construir los criterios de aceptación es la siguiente:

Cuando (Rol) hace (Acción) consigue (Resultado / Comportamiento esperado)

Veamos un ejemplo:

Historia de Usuario: Como cliente, quiero pagar mi suscripción mensual vía sitio web por medio de transferencia bancaria o tarjeta de crédito, para evitar el desplazamiento hasta la sucursal de pago.

Criterios de Aceptación:

👉 Tip para el Product Owner
En la discusión de las historias de usuario, puedes emplear la técnica de las 3 C's: Card (Tarjeta), Conversation (Conversación) y Confirmation (Confirmación). Esta técnica ayuda a mantener la simplicidad, ya que la información se mantiene ligera (tarjeta), se clarifica a través del diálogo (conversación) y se verifica (confirmación).

2. Estimaciones

Las estimaciones se refieren al tiempo o esfuerzo necesario para completar una Historia de Usuario o una tarea. Los equipos Scrum a menudo usan puntos de historia, horas o días para estimar la complejidad y el esfuerzo necesario.

Es muy importante realizar la estimación del trabajo requerido para desarrollar las Historias de Usuario y las tareas relacionadas, de esta manera se logran planificaciones más precisas.

La estimación NO es determinada por el cliente o el Product Owner, sino que son los Developers en conjunto con el Scrum Master y el Product Owner, quienes definen las estimaciones ya que ellos son quienes ejecutarán directamente el trabajo necesario.

👉 Tip para el Product Owner
Recuerda que las estimaciones son relativas y no deben interpretarse como compromisos rígidos. Sirven como guías basadas en la información y experiencia actual del equipo.

Para garantizar una estimación más precisa, se pueden considerar elementos como:

Uno de los problemas más comunes con la estimación de las Historias de Usuario, es sólo se estimar la dificultad (puntos de historia), o sólo estimar la duración (horas / días); por lo que es altamente recomendable estimar los dos. Muchos equipos prefieren unificar esto mediante una relación entre los puntos de historia y la duración, es decir que para cada punto de historia se asigna un tiempo determinado.

👉 Tip para el Scrum Master
Si sientes que las estimaciones consistentemente no reflejan el esfuerzo real de los Developers, aborda el tema en la retrospectiva del sprint. Analiza y ajusta el proceso de estimación en conjunto con el equipo según sea necesario.

El manejo que se da a los puntos de historia es específico de cada equipo, y es crucial entender que las estimaciones están íntimamente ligadas a la experiencia, conocimientos y dinámicas específicas de cada equipo, por lo que NO es recomendable comparar diferentes equipos basados en sus estimaciones: Incluso si dos equipos trabajan en el mismo producto o en productos similares, su ritmo de trabajo puede variar.

En Scrum el ritmo de trabajo también se conoce como la "velocidad" y se basa en cuántos puntos de historia, en promedio, un equipo puede completar en un Sprint. La velocidad no solo se basa en la capacidad de producción; también se ve influenciada por la comunicación dentro del equipo, las herramientas disponibles, las interrupciones externas, entre otros factores.

¿Por qué no comparar equipos basados en estimaciones? Comparar equipos basados en sus puntos de historia o velocidad puede llevar a interpretaciones erróneas. Si un equipo A completa 50 puntos de historia en un Sprint y el equipo B completa 30 puntos, no significa necesariamente que el equipo A sea más productivo o eficiente. Puede que el equipo B esté manejando tareas más complejas o enfrentando desafíos que el equipo A no tiene. Comparar equipos de esta manera puede llevar a decisiones injustas y a presiones innecesarias, lo que puede afectar negativamente la moral y la productividad.

A continuación se muestra un ejemplo de ello:

Supongamos que tenemos dos equipos, Equipo A y Equipo B, ambos trabajando en diferentes funcionalidades del mismo producto.

El equipo A, con base en sus experiencias anteriores y en la comprensión que tienen sobre su capacidad y velocidad de trabajo, definió la siguiente tabla de estimaciones:

estimacion1

Por otro lado, el equipo B, que puede tener una composición diferente en términos de habilidades, experiencia y conocimientos técnicos, definió la siguiente tabla de estimaciones:

estimacion2

Durante la sesión de estimación, el Equipo A asigna 5 puntos a una historia de usuario específica, mientras que el Equipo B asigna 8 puntos a una historia similar. Esto no significa necesariamente que el Equipo B vea la historia como más complicada o que sean menos eficientes. Es posible que el Equipo B, basado en experiencias pasadas, considere ciertos riesgos o complejidades adicionales que el Equipo A no ha experimentado. Por otro lado, el Equipo A puede tener un experto en una herramienta o tecnología relevante que reduce la percepción de esfuerzo.

Si bien ambos equipos trabajan en el mismo producto, tienen distintas experiencias, habilidades y contextos que influyen directamente en cómo ven y estiman el trabajo.

👉 Tip para el Developer
Primero la calidad: No sacrifiques la calidad de tu trabajo para cumplir con una estimación. Si una historia de usuario necesita más tiempo del estimado para ser completada adecuadamente, es mejor discutir esto con el Scrum Master para ajustar el plan que entregar un producto inferior.

3. Prototipos, Diagramas, etc

Los prototipos, diagramas o esquemas de una Historia de Usuario nos sirven para mostrar un acercamiento al resultado que se espera obtener cuando los Developers ejecuten su trabajo, de esta manera se puede probar el producto antes de construirlo para identificar posibles errores y generar un mejor entendimiento para los Developers.

Prototipo: Es una representación preliminar de un producto, que muestra cómo se verá y funcionará, sin necesidad de que esté completamente funcional. Puede ser desde un boceto en papel hasta una versión interactiva digital.

Diagrama: Son representaciones gráficas que muestran las relaciones entre diferentes componentes, actores o flujos de un sistema o proceso.

Estos elementos visuales sirven como herramientas de comunicación entre el equipo, el Product Owner y los stakeholders, y pueden ser vitales para reducir la ambigüedad y mejorar la calidad del producto final.

👉 Tip para el equipo
Un prototipo no tiene que ser perfecto ni estar completo: La idea es que sea una representación aproximada que pueda modificarse fácilmente en función de los comentarios recibidos.

Beneficios de usar prototipos:

👉 Tip para el equipo
No todos los elementos o características necesitarán un prototipo o diagrama. La decisión de cuándo usarlos dependerá de la complejidad de la historia, los recursos disponibles y las necesidades del equipo y los stakeholders.
Es importante recordar que, aunque estas herramientas son valiosas, deben usarse de manera estratégica para maximizar su valor sin desperdiciar esfuerzos en detalles innecesarios.

Épicas

Una épica es una gran pieza de trabajo que se puede desglosar en un conjunto de tareas más pequeñas (historias de usuario) que estan relacionadas entre sí. Puede considerarse como un contenedor para historias de usuario que están relacionadas y que, una vez completadas, cumplirán un objetivo o función más grande y más complejo.

Algunas ideas de las que se podrían definir las épicas son: • Módulos. • Componentes. • Hitos. • Entregables. • Funcionalidades.

Se puede decir que una épica es un nivel de agrupación por encima de las historias de usuario que permite clasificarlas por funcionalidades, módulos, subsistemas, etc.

Las épicas:

El propósito de identificar épicas es ayudar a gestionar y organizar el trabajo del Product Backlog de manera más efectiva. Se trata de simplificar la complejidad y proporcionar una visión clara del objetivo final, permitiendo a los equipos trabajar de manera más coordinada y eficiente.

Recomendaciones sobre las épicas:

Ejemplo de épica: Renovar la experiencia de pago del sitio web para simplificar el proceso de compra y reducir el abandono del carrito.

Historias de Usuario derivadas de la Épica:

... (y así sucesivamente, hasta que todas las facetas de la renovación de la experiencia de pago estén cubiertas).

Guía para identificar épicas sin morir en el intento ☝

4. Product Owner: Gestión ágil de productos

4.4 - Refinamiento del Product Backlog

Estamos a puertas de iniciar con el desarrollo del producto, tenemos una comprensión general del producto y contamos con un Product Backlog que contiene elementos cortos y concretos. Tú como Product Owner los entiendes claramente, pero: ¿el resto del equipo también los entienden?

El refinamiento del Product Backlog es una actividad continua en la que el equipo Scrum colabora con las diferentes partes interesadas para crear un entendimiento compartido sobre lo que el producto hará y no hará (historias de usuario y tareas), sobre el esfuerzo que requerirá su implementación (estimaciones) y el orden en que lo hará (priorización).

El equipo puede llevar a cabo el refinamiento paralelamente al desarrollo del actual sprint, con esto se logrará que la planificación del siguiente sprint sea muchísimo más eficiente.

Si bien el Product Owner lidera el proceso de refinamiento del Product Backlog, es vital que cuente con la colaboración activa de los Developers y el Scrum Master. Esta colaboración multidisciplinaria no solo enriquece el proceso con diversas perspectivas y habilidades, sino que también promueve un entendimiento compartido y una toma de decisiones más informada, lo que es esencial para el desarrollo exitoso del producto.

¿Por qué es importante el refinamiento del Product Backlog?

Caso de estudio: ¿Por qué deberíamos refinar? En una reconocida empresa de software, la omisión del refinamiento del Product Backlog llevó a consecuencias graves. Sin una adecuada claridad y detalle en los ítems del backlog, el equipo de desarrollo frecuentemente enfrentaba obstáculos en la implementación, resultando en retrasos significativos y una acumulación de tareas mal definidas. Esto no solo generó frustración entre los miembros del equipo, sino que también impactó negativamente en la satisfacción del cliente debido a entregas de productos por debajo del estándar esperado. Este caso resalta la necesidad vital de la inclusión activa y continua del Product Owner, el Scrum Master y los Developers en el proceso de refinamiento del backlog para asegurar un flujo de trabajo fluido y entregas exitosas.

👉 Tip para el Product Owner: Mantener una lista de "ítems de refinamiento listos para discusión
Estos ítems pueden ser abordados en las sesiones con el equipo. Esto garantiza que siempre haya un flujo constante de ítems listos para ser trabajados y que las sesiones de refinamiento sean eficientes y focalizadas. Además, no dudes en retirar elementos que ya no añaden valor, manteniendo así un Backlog limpio y centrado en las prioridades actuales.

¿Qué se hace en el refinamiento del Product Backlog?

Algunas de las cosas que se puedan hacer en el refinamiento son:

👉 Tip para el Product Owner: No olvides involucrar a todo el equipo Scrum en el proceso de refinamiento.
Aunque como Product Owner tienes la responsabilidad de mantener y priorizar el Product Backlog, el conocimiento y la perspectiva de los Developers y del Scrum Master pueden ayudar a enriquecer los ítems del backlog, proporcionando detalles técnicos y apuntando posibles obstáculos desde una etapa temprana, facilitando una entrega más fluida y exitosa del producto.

¿Cuándo es el mejor momento para el refinamiento del Product Backlog?

El refinamiento del Product Backlog es una actividad continua, no solo para el Product Owner, sino para todo el equipo. El Product Owner puede refinar los elementos del Product Backlog en cualquier momento, dentro o fuera de una reunión, dependiendo de lo que sea más conveniente para el equipo.

Nota: La forma y momento en que se haga el refinamiento depende del equipo Scrum.

Es vital destacar que la planificación en Scrum ocurre de manera paralela Mientras los Developers están inmersos en la construcción del actual incremento de producto, el Product Owner se encuentra activamente trabajando en el refinamiento de los próximos elementos del backlog, identificando nuevas oportunidades y ajustando prioridades, garantizando así un flujo constante y eficiente de trabajo para futuros sprints.

4. Product Owner: Gestión ágil de productos

4.5 - Técnicas y herramientas útiles para el Product Owner

Herramienta 1: User stories mapping (Mapeo de historias de usuario)

Esta técnica es vital para organizar y visualizar de manera clara y estructurada los elementos del Product Backlog, agrupándolos según su funcionalidad y dependencia, lo que a su vez facilita su proyección a lo largo del tiempo.

El proceso de mapeo se desarrolla típicamente en sesiones de trabajo que duran entre 2 y 4 horas. Durante estas sesiones, se utiliza un lienzo y post-its para facilitar la categorización y priorización de los elementos que integrarán el producto.

Una de las grandes ventajas de este método es que asiste en la programación de los sprints, proporcionando una perspectiva clara para los stakeholders sobre qué se realizará y cuándo, aunque sea de manera aproximada.

La técnica de Mapeo de Historias de Usuario (User Stories Mapping) sirve como una herramienta crucial para estructurar y definir el MVP (Producto Mínimo Viable), permitiendo una visualización clara de las funcionalidades esenciales que deben ser implementadas en primera instancia para satisfacer las necesidades centrales del cliente.

¿Cómo construir el mapa de historias?

Antes de comenzar, es fundamental establecer el estado objetivo del producto (Product Goal), ya que esto determinará el contexto dentro del cual se desplegará el producto. Posteriormente, es necesario identificar las funcionalidades o componentes principales que constituirán el producto, conocidos como "épicas".

Pasos para crear un Mapa de Historias de Usuario

  1. Definición del Product Goal: Establece claramente el objetivo principal del producto que guiará todas las decisiones futuras, recuerda basarte en el problema que se pretende solucionar.
  2. Identificación de Épicas: Determina las grandes funcionalidades o componentes que conformarán el producto.
  3. Creación de Historias de Usuario: Desarrolla historias de usuario que describan cada función desde la perspectiva del usuario.
  4. Organización de Historias: Organiza las historias de usuario identificadas en una estructura visual, categorizándolas según su funcionalidad y dependencia.
  5. Priorización: Establece las prioridades de las historias de usuario, decidiendo cuáles deben abordarse primero basándote en su valor y complejidad.
  6. Revisión y Ajustes: Durante las sesiones de refinamiento del Product Backlog, revisa y ajusta el mapa según sea necesario, incorporando los aprendizajes y cambios que surjan durante el desarrollo.

Herramienta 2: Técnica para priorizar - MoSCoW (Must have, Should have, Could have, Would have)

La técnica MoSCoW es un método efectivo para priorizar los elementos del Product Backlog, ayudando a discernir lo esencial de lo deseable. Aquí está desglosada en sus componentes:

Este enfoque facilita la toma de decisiones durante el refinamiento del backlog, permitiendo una distribución más estratégica de los recursos y esfuerzos del equipo.

¿Cuándo aplicar MoSCoW en Scrum?

La técnica MoSCoW puede aplicarse en varias etapas del ciclo de Scrum:

Herramienta 3: Modelo Kano

El Modelo Kano es una herramienta útil para identificar y categorizar las necesidades del cliente en el desarrollo del producto. Se clasifica en las siguientes categorías:

Al aplicar el Modelo Kano, el Product Owner puede obtener una comprensión más profunda de lo que realmente desea el cliente, lo que puede ayudar a priorizar de manera efectiva las funcionalidades en el Product Backlog.

Herramienta 4: Customer Journey Maps (Mapas del Viaje del Cliente)

El Customer Journey Map es una herramienta visual que representa la experiencia total del cliente con un producto o servicio desde el primer contacto hasta la interacción final. Ayuda a comprender las necesidades, las emociones y los obstáculos que el cliente podría enfrentar en cada etapa. Aquí está su estructura general:

El uso de los Customer Journey Maps permite al Product Owner:


Otras herramientas / técnicas útiles para el Product Owner


5. Developer: Desarrollo ágil de productos

Los Developers tienen la responsabilidad vital de dar vida a los incrementos generados en cada Sprint, construyendo los elementos que eventualmente conformarán el producto final. Es imperativo que posean las habilidades y competencias necesarias para realizar este trabajo de manera efectiva. En este capítulo, nos sumergiremos en el mundo de los Developers, destacando las actividades, habilidades y responsabilidades esenciales que delinean su función dentro del equipo Scrum, complementando lo ya discutido en el modelo core de Scrum. Puntos clave de este capítulo: - Identificar las responsabilidades centrales de los Developers en el proceso Scrum. - Explorar las habilidades y competencias que los Developers deben cultivar. - Analizar las actividades diarias y estrategias que facilitan un desarrollo de producto exitoso. - Comprender cómo los Developers colaboran para alcanzar los objetivos de los Sprint y contribuir al producto final.

5. Developer: Desarrollo ágil de productos

5.1 - Desarrollo ágil de producto

En el dinámico mundo actual, la figura del Developer se transforma constantemente, abrazando roles más estratégicos y creativos. En este escenario, el desarrollo ágil de productos emerge como un enfoque que no sólo refina tus habilidades técnicas, sino que potencia tu capacidad para contribuir activamente en la creación de soluciones innovadoras.

En este módulo, te invitamos a explorar cómo, como developer, puedes ser un actor clave en este proceso. Desde participar activamente en la definición de la arquitectura del producto, hasta adoptar prácticas de documentación eficientes y ser un protagonista en la implementación de pruebas continuas, tu responsabilidad es esencial para el éxito del producto.

Prepárate para sumergirte en un camino donde tu conocimiento técnico se une con una visión estratégica, permitiéndote participar de manera significativa en la entrega continua de valor. ¡Adelante!

5.1.1 - Autogestión y Gestión del Tiempo: Claves en un buen Scrum Developer

Dentro de un equipo Scrum, se espera que los Developers sean proactivos y asuman un papel central en la autogestión de su tiempo y esfuerzos. Esto no solo fomenta la responsabilidad individual, sino que también promueve una cultura de colaboración y respeto mutuo.

Caso práctico: Imagina un escenario donde un Developer, Carlos, se da cuenta de que una tarea específica está consumiendo más tiempo del esperado, lo cual puede afectar la entrega oportuna del incremento planeado para el Sprint. En lugar de esperar a ser dirigido, toma la iniciativa de comunicar la situación al equipo, proponiendo una sesión de brain-storming para encontrar una solución eficiente. Gracias a esta proactividad, el equipo pudo reajustar y repriorizar las tareas, garantizando la entrega exitosa del incremento.

Tips para una Efectiva Autogestión y Gestión del Tiempo

La autogestión, combinada con una efectiva gestión del tiempo y priorización, no solo facilita la entrega oportuna de productos de alta calidad, sino que también contribuye a un ambiente de trabajo más armonioso y productivo.



5.1.2 - Consideraciones clave para el desarrollo ágil de productos

En el trayecto de construcción de productos ágiles, es imperativo tener en cuenta varios factores esenciales que influenciarán el éxito del producto final. Aquí te presentamos tres preguntas centrales que todo Developer debería tener en mente:

¿Por qué debería definirse la arquitectura de producto

La "Arquitectura del Producto" puede definirse como el esquema estructural que ilustra cómo se organizarán y interactuarán las distintas partes o componentes de un producto. Esta estructura no solo comprende la organización de elementos técnicos, sino también la definición de las relaciones y dependencias que existen entre ellos. El establecimiento de una arquitectura sólida desde el principio, ayuda a prever desafíos y facilita el proceso de incorporación de cambios o ajustes en etapas posteriores del desarrollo. En pocas palabras, funciona como el mapa guía que orienta el desarrollo del producto de una manera organizada y estratégica, asegurando que todas las piezas encajen de manera óptima para cumplir con los objetivos propuestos.

Definir la arquitectura del producto no es solo una cuestión de organización, sino que establece una hoja de ruta clara que facilita la identificación y solución de posibles problemas antes de que surjan. Permite una colaboración fluida entre los miembros del equipo y garantiza que todos trabajen hacia una visión unificada, optimizando los recursos y el tiempo disponible.

Antes de iniciar la construcción del producto es importante identificar la relación entre todos los componentes que harán parte del mismo. Definir una correcta arquitectura permitirá que los equipos de trabajo sepan como organizar sus entregables, se facilitará la integración y la mejora continua.

Es indispensable que, antes de iniciar con el desarrollo se defina el diseño técnico del producto o del incremento de producto a desarrollar. Esta actividad podría hacerse de forma iterativa antes de desarrollar los incrementos en los distintos Sprint, o de forma global al inicio del desarrollo.

Para garantizar que la arquitectura de producto cumple exactamente con los requerimientos y necesidades del cliente se debe hacer en conjunto entre los Developers y el Product Owner.

👉 Tip para el Developer
Involúcrate activamente en las discusiones sobre la arquitectura del producto. Tu conocimiento técnico es vital para diseñar una arquitectura que no solo cumpla con los requisitos del cliente, sino que también sea sostenible y escalable a largo plazo. No dudes en compartir tus ideas y sugerencias.

La arquitectura está estrechamente relacionada con el objetivo del producto (Product Goal). El diseño arquitectónico del producto o sistema sienta las bases para lograr los objetivos y metas del producto, asegurando que se puedan implementar las características y funcionalidades deseadas de manera efectiva.

Ejemplo de arquitectura 1: Construyendo un vehiculo electrico

Al embarcarse en la construcción de un vehículo eléctrico, es vital analizar cuidadosamente los siguientes aspectos cruciales y entender cómo interactuarán entre sí y quién será responsable de su desarrollo, algunos ejemplos que debes considerar al definir la arquitectura son:

Ejemplo de arquitectura 2: Construyendo un software LMS

Una empresa de desarrollo de software planea construir una aplicación para realizar cursos virtuales. Al ser un proyecto de software, en la definición de arquitectura se deberán tener en cuenta los siguientes elementos:

Ejemplo de arquitectura 3: Construcción: Diseño de una Casa Moderna


¿Qué debo considerar respecto a la documentación del producto?

La documentación es una herramienta vital en el desarrollo de productos, ya que facilita la trazabilidad y comprensión de las funcionalidades y características del producto. Es importante considerar no solo qué documentar, sino cómo hacerlo de una manera que sea accesible y útil para todos los involucrados. Además, incentivar la documentación proactiva puede ser un método efectivo para garantizar que se mantenga actualizada y relevante.

La documentación es una herramienta indispensable que, aunque a veces despreciada, puede ser un salvavidas en el ciclo de vida del desarrollo de productos. Vamos a desglosar cómo puede realizarse de manera eficiente y sin dolor:

👉 Tip para el Developer
Considera la documentación como una herramienta que te ayudará, no como una tarea tediosa. Al mantener una documentación precisa y bien organizada, facilitas la gestión de la calidad y la colaboración efectiva en tu equipo.

Caso práctico Pedro, uno de los developers, toma la iniciativa de crear una Wiki para almacenar toda la documentación del proyecto. A medida que el proyecto avanza, el equipo la mantiene actualizada, facilitando la incorporación de nuevos miembros al equipo y sirviendo como una valiosa referencia para revisar decisiones pasadas.

Caso Práctico: Motivando la Documentación Laura, una developer experimentada, notó que el equipo evitaba la documentación, lo que causaba confusión y retrasos. Para remediarlo, instauró junto al Scrum Master sesiones dedicadas a la documentación en cada sprint, complementándolo con un sistema de recompensas para el miembro que más contribuyera. Este enfoque transformó la documentación de una tarea despreciada a una actividad valorada que mejoraba la eficiencia del equipo.



¿Qué implican exactamente las pruebas del producto?

Las pruebas no son una fase aislada en el proceso ágil, sino una integración continua que asegura la calidad y el valor del producto en cada etapa del desarrollo. Los Developers deben adoptar una postura proactiva hacia la realización de pruebas, asegurando que cada incremento cumpla con los estándares de calidad establecidos y contribuyendo al éxito a largo plazo del producto.

Una prueba es la forma de comprobar el correcto funcionamiento del producto o uno de sus incrementos.

👉 Tip para el Developer
Adopta un enfoque proactivo hacia las pruebas, viéndolo como una oportunidad para mejorar continuamente el producto, en lugar de una tarea de última hora. Incorpora pruebas regulares en tu flujo de trabajo para garantizar que cada incremento del producto sea de alta calidad.
👉 Tip para el Developer
Recuerda que las pruebas no son una tarea aislada o exclusiva de un equipo de pruebas; eres co-responsable de la calidad de los entregables. Aprovecha tu conocimiento y habilidades para integrar pruebas continuas. Considera que las pruebas son exclusivas para proyectos de software, sino en todas las facetas del desarrollo de productos. Esto asegurará que el producto no solo funcione como se espera, sino que también cumpla con los estándares de calidad desde el inicio.

Caso práctico: Cuando no se hacen pruebas o no son suficientes En un equipo, inicialmente se pasaba por alto la fase de pruebas o se realizaban de manera muy superficial, lo que llevaba a múltiples errores en las versiones finales del producto. Pero, al establecer definiciones de terminado (DoD) centradas en procesos específicos, se creó una pauta clara para realizar pruebas exhaustivas en cada incremento. Esto no solo redujo los errores sino que también facilitó que cada miembro del equipo pudiera llevar a cabo pruebas efectivas de sus propios entregables, mejorando así la calidad general del producto.

5. Developer: Desarrollo ágil de productos

5.2 - Los Developers y los eventos

El desarrollo de un producto exitoso es una jornada colaborativa, y los Developers están en el corazón de este viaje. En el contexto de Scrum, su participación activa en los diversos eventos es crucial, no solo por su papel en la construcción del producto sino también por su contribución a la planificación, adaptación y mejora continua que Scrum fomenta.

En esta sección, desglosaremos cómo los Developers se involucran y contribuyen en cada uno de los eventos de Scrum. Desde la planificación del Sprint, donde establecen las bases del trabajo a realizar, hasta la retrospectiva del Sprint, donde reflexionan sobre el progreso y buscan formas de mejorar. A través de su compromiso y colaboración en cada fase, garantizan que el producto en desarrollo esté alineado con los objetivos establecidos y se adapte eficazmente a las cambiantes demandas y expectativas.

👉 Tip para los Developers
Durante los eventos de Scrum, toma un papel activo en la comunicación y colaboración. No sólo compartas el progreso técnico, sino también busca feedback y aporta ideas para potenciar el valor del producto en desarrollo. La colaboración efectiva entre Developers y otras responsabilidades en el equipo Scrum puede ser la clave para la creación de soluciones innovadoras y de alto impacto.

Los Developers en la Planificación del Sprint

Caso práctico: Durante la planificación del Sprint, el equipo se reúne para discutir las metas del próximo Sprint. Daniela, una Developer, sugiere que se enfoquen en un conjunto particular de historias de usuario que, según su análisis, pueden agregar un valor significativo al producto. Aprovecha este momento para clarificar dudas técnicas con el Product Owner y garantiza que todos los elementos están bien definidos. Juntos, como equipo, realizan una sesión de estimación basada en su experiencia y conocimientos técnicos, asegurando una comprensión compartida de la carga de trabajo y de los objetivos del Sprint.

👉 Tip para los Developers
En la planificación del Sprint, no te limites a hacer caso a lo propuesto por el Product Owner, adopta una postura proactiva en identificar las historias de usuario que podrían agregar más valor al producto. Utiliza este tiempo no sólo para entender el "qué" sino también el "por qué" detrás de cada elemento del Product Backlog, alineándolos estratégicamente con el Objetivo del Sprint (Sprint Goal) y el Objetivo de Producto (Product Goal) a largo plazo.

Los Developers en el Daily

Consejo: Recuerda que el objetivo del Daily no es supervisar sino facilitar la colaboración y el flujo de información. Anima a los Developers a que se apropien de este espacio, compartiendo no sólo avances sino también aprendizajes y retos, promoviendo una cultura de transparencia y confianza mutua, y evitando la percepción de que se trata de una herramienta de supervisión.

👉 Tip para los Developers
Evita la Monotonía: Para prevenir que los Daily se conviertan en encuentros monótonos, varía la estructura ocasionalmente. Por ejemplo, puedes introducir una breve sesión de brainstorming para solucionar un problema específico o facilitar una rápida actividad de team-building que fomente la colaboración y la energía positiva en el equipo.

Los Developers durante el desarrollo del Sprint

Consejos para Developers durante el Desarrollo de un Sprint

Caso Práctico: Durante el desarrollo del Sprint, Laura, una Developer, se da cuenta de que una funcionalidad que están implementando podría beneficiarse de una integración con una herramienta externa, lo que potencialmente podría ahorrar tiempo y esfuerzo en el futuro. Acción: Laura discute esta idea con el resto del equipo durante una sesión de trabajo. Juntos, evalúan los pros y los contras de la implementación de esta integración en este momento, teniendo en cuenta el Objetivo del Sprint y las capacidades del equipo. Resultado: Después de una discusión constructiva, deciden adaptar el plan de Sprint para incorporar esta mejora, ajustando las historias de usuario y las tareas asociadas según sea necesario. Esto les permite entregar un incremento de mayor valor al final del Sprint, demostrando una adaptabilidad y una perspectiva centrada en el valor.

Los Developers en la Revisión del Sprint

Consejos para Developers durante la Revisión del Sprint

Caso práctico: En una sesión de revisión del Sprint, los Developers se encuentran presentando el incremento de producto que lograron durante el Sprint. Laura, una de las Developers, toma la iniciativa de explicar cómo abordaron ciertos retos técnicos y lograron cumplir con los criterios de aceptación establecidos. A medida que se presentan los elementos, Juan, otro Developer, muestra ejemplos prácticos de las funcionalidades implementadas, permitiendo que las partes interesadas tengan una comprensión más clara del progreso. Juntos, los Developers colaboran para asegurar que todas las voces sean escuchadas y que el feedback recibido sea adecuadamente integrado en las consideraciones para el próximo Sprint.

Los Developers en la Retrospectiva del Sprint

Aclaración: Una retrospectiva no solo incluye la identificación de problemas, sino también la colaboración proactiva para diseñar soluciones viables y establecer metas claras para mejorar en áreas específicas.

👉 Tip para el Developer en la Retrospectiva
Cambia el Entorno y Añade un Toque Personal: No permitas que las retrospectivas se conviertan en una rutina aburrida. Sugiere realizar estas sesiones en una herramienta de colaboración gráfica, donde el equipo pueda visualizar de manera creativa los puntos de mejora, o incluso fuera de la oficina en un ambiente más relajado. Además, ¿por qué no agregar un elemento de diversión? Podría ser organizar una comida especial o un snack diferente para cada retrospectiva, fomentando un ambiente más ameno y relajado que puede ayudar a que fluyan mejor las ideas y la comunicación.
Consejos para Developers durante la Retrospectiva del Sprint

Caso práctico: En la retrospectiva, algunos miembros del equipo mencionan que sienten que no hay mucho que discutir o mejorar, mientras que otros sienten que hay problemas pero son reacios a hablar de ellos para evitar situaciones incómodas. Acción: Laura, una de las developers, decide tomar la iniciativa. Ella comparte honestamente algunos desafíos que ha notado durante el Sprint, aunque son temas sensibles. Su apertura anima a otros a compartir sus propias observaciones y preocupaciones, lo que lleva a una discusión enriquecedora. Resultado: El equipo logra identificar varios aspectos cruciales para trabajar y mejorar en el próximo Sprint. Además, se dan cuenta de que, enfrentando los temas incomodos, pueden encontrar soluciones conjuntas y fortalecer la dinámica del equipo.

5. Developer: Desarrollo ágil de productos

5.3 - Técnicas y herramientas útiles para los Developers

En el dinámico mundo de Scrum, las responsabilidades de los Developers trascienden las fronteras de las tareas convencionales. Se espera que estén equipados para abordar una amplia variedad de desafíos, adaptándose con agilidad a las demandas cambiantes del proyecto. En esta sección, exploraremos algunas técnicas y herramientas cruciales que pueden facilitar a los Developers esta navegación a través del vibrante entorno de Scrum. Dentro de ellas veremos:

Consejo Al seleccionar y emplear diversas técnicas y herramientas, es vital hacerlo con un enfoque centrado en el valor y la eficiencia. Considera la compatibilidad con las necesidades del organización, la facilidad de integración y cómo pueden potenciar una colaboración efectiva y una entrega ágil de incrementos de alta calidad. A menudo, una herramienta simple pero bien elegida o una técnica aplicada con pericia puede marcar una significativa diferencia, optimizando procesos y fomentando un ambiente de trabajo más productivo y armonioso.

5.3.1 - Para el desarrollo ágil

En esta sección, exploraremos técnicas y herramientas que pueden facilitar un proceso de desarrollo más fluido y colaborativo, promoviendo la calidad y eficiencia en cada incremento.

Nota: Para aquellos interesados específicamente en el ámbito del desarrollo de software, les invitamos a consultar nuestra otra publicación enfocada especialmente en este sector, disponible a través de CertMind, donde profundizamos en técnicas y herramientas adaptadas a las particularidades del desarrollo de software.

Programación por parejas – Pair programming

La programación por parejas es una técnica de desarrollo ágil en la que dos desarrolladores colaboran en la misma tarea, trabajando en un único equipo o computadora. Este enfoque fomenta la colaboración, la comunicación directa y un intercambio fluido de ideas, lo que a menudo resulta en soluciones más innovadoras y eficientes.

Aunque puede parecer que esta técnica reduce la cantidad de funcionalidad producida, en realidad, tiende a mejorar notablemente la calidad del resultado final. Al tener dos pares de ojos revisando el trabajo en tiempo real, es más probable que se identifiquen y corrijan errores en una etapa temprana, lo que puede prevenir costos adicionales a largo plazo.

👉Tip para el Pair Programming
La programación por parejas no es una sesión de enseñanza; de hecho, funciona mejor cuando ambos desarrolladores tienen un nivel similar de conocimiento y habilidades. Esto permite una colaboración más fluida y equitativa, donde ambos pueden contribuir significativamente al progreso de la tarea. Asegúrate de emparejar a desarrolladores con niveles de habilidad compatibles para aprovechar al máximo esta técnica.

El pair programming no solo se usa en programación de software

Caso práctico: El pair programming puede ser agotador En una empresa de tecnología, se instauró la técnica de programación por parejas como una actividad regular pero no constante. Los equipos encontraron que trabajar en parejas durante periodos específicos (como por la mañana o en sesiones de no más de dos horas) era beneficioso sin ser agotador. Esta moderación permitió mantener altos niveles de energía y concentración, favoreciendo la calidad y eficiencia del trabajo realizado.

Caso práctico: Cambiando de pareja En una startup, se estableció una rotación de parejas de programación con cada nuevo Sprint. Esta rotación no solo permitió que los Developers fortalecieran sus relaciones interpersonales, sino que también promovió una comprensión más profunda y diversificada del proyecto en su conjunto, ya que cada miembro del equipo tuvo la oportunidad de trabajar y aprender de diferentes perspectivas y enfoques a lo largo del tiempo.

👉Tip: el Pair Programming no se aplica a todas las tareas
El "Pair Programming" no es una regla fija que deba aplicarse a todas las tareas. Es una herramienta especialmente efectiva para abordar desafíos complejos, explorar nuevas tecnologías o desarrollar funcionalidades críticas. Considera implementarlo estratégicamente, especialmente en situaciones donde la colaboración directa puede potenciar la creatividad, la calidad y la eficiencia. Recuerda, la clave es usarlo donde agregue el mayor valor al proceso de desarrollo del producto.

La refactorización

La refactorización, en un contexto más amplio que el desarrollo de software, puede ser entendida como el proceso de revisar, ajustar y mejorar las estructuras existentes de un proyecto o sistema para hacerlo más eficiente, manejable o adaptable a nuevas necesidades, sin alterar su función fundamental. Esto puede aplicarse a una variedad de ámbitos, como procesos empresariales, estrategias de marketing, estructuras organizativas, etc.

Ejemplo: Antes de la Refactorización Un equipo utiliza una plantilla de informe densa y complicada, que contiene una cantidad significativa de campos irrelevantes. Esto no solo consume tiempo sino que también dificulta la comprensión clara de los puntos clave. Después de la Refactorización - El equipo decide revisar y simplificar la plantilla, eliminando los campos innecesarios y dando prioridad a la información más crítica. Como resultado, los informes ahora son más concisos, centrados y fáciles de leer, facilitando la toma de decisiones y la comunicación efectiva dentro del equipo.

👉Tip: La refactorización debe ser vista como una actividad continua
La refactorización es un compromiso con la mejora constante. No es un "arreglo único", sino un proceso en el que se está siempre atento a las oportunidades de optimizar y ajustar para alcanzar una mayor eficiencia y efectividad. Además, es vital evitar la "refactorización por refactorización". Cada cambio debe tener un propósito claro y estar orientado a lograr mejoras tangibles, evitando alteraciones que no agregan valor significativo.


5.3.2 - Para estimar el trabajo

La estimación consiste en definir entre todos una suposición lo más precisa posible, de lo que se puede lograr y en cuanto tiempo.

La estimación permite:

Nota: El momento en que se realiza la estimación es durante la Planificación del Sprint.

Estimar con Planning Poker

El póker de planificación consiste en un conjunto de tarjetas numéricas que sirven para realizar la estimación de tareas o historias de usuario.

El póker puede ir numerado de 1 a 10 o utilizando la sucesión de Fibonacci

Estimar por afinidad

Consiste en encontrar las similitudes de las Historias de Usuario y tareas que se van a estimar. Lo que hace el equipo es agrupar los elementos que son similares. La mejor manera de “encontrar similitudes” es visualizar el panorama completo y luego agrupar elementos.

Estimar con Tallas de camiseta (t-shirt)

Se asigna una talla de camiseta a cada Historia de Usuario o tarea (desde XS hasta XXL) que representará el esfuerzo relativo de ese trabajo.

Con esta técnica se elimina la necesidad de la precisión de un modelo numérico, por lo que el equipo puede pensar de manera más abstracta en las estimaciones del trabajo a estimar.

¿Qué pasa cuando se Subestima/Sobreestima un Sprint?

Cuando los equipos Scrum son nuevos, o tienen poca experiencia es típico que sucedan las siguientes 2 situaciones:

Sobreestimación: Cuando los Developers proponen demasiado tiempo para el trabajo del Sprint y acaban mucho antes de la Revisión del Sprint. En este caso el Product Owner agregará más trabajo al Sprint en curso (para que la Revisión no se cambie de fecha).

Subestimación: Cuando los Developers proponen muy poco tiempo para el trabajo del Sprint, lo que puede causar que el incremento no esté completamente terminado. En este caso la Revisión se hace sobre los elementos que se hayan completado y los demás quedan pendientes para ser terminados en el próximo Sprint (la revisión NO se aplaza).



Otras posibles técnicas que podrían ser útiles para mejorar el flujo de trabajo durante un Sprint

6. Consideraciones finales

A medida que llegamos al final de este recorrido, es imperativo que nos detengamos un momento para contemplar el viaje transformador que People Information LLC emprendió, un espejo del potencial que Scrum tiene para revolucionar las operaciones comerciales. Desde las recomendaciones pragmáticas para la adopción de Scrum hasta el desglose conciso de términos vitales, hemos cubierto terreno significativo, allanando el camino para futuros éxitos en el ámbito ágil. Puntos clave de este capítulo: - Recomendaciones para Adoptar Scrum: Estrategias fundamentadas para una transición exitosa a Scrum. - Glosario y Términos Usados: Clarificación de términos y conceptos centrales en Scrum. - Caso de Éxito de People Information LLC: Una mirada a los beneficios tangibles y la transformación alcanzada por People Information LLC con la adopción de Scrum.

6. Consideraciones finales

Consideraciones finales sobre el uso y adopción de Scrum

Al llegar al final de nuestro trayecto a través del marco de trabajo Scrum, es vital detenerse a considerar las profundas implicaciones que tiene la adopción de Scrum en una organización. Es mucho más que simplemente asimilar nuevas técnicas; se trata de cultivar un cambio cultural que impregne de agilidad y eficiencia cada rincón de la empresa.

En este último capítulo, analizaremos aspectos críticos para tener en cuenta durante la adopción de Scrum, desde entender su verdadera esencia hasta cómo puede escalar eficazmente, sin olvidar la vitalidad de mantener un equipo motivado. Además, subrayaremos la necesidad de una optimización continua para asegurar una travesía fructífera a largo plazo en el mundo ágil.

Ahora, vamos a explorar estas consideraciones cruciales que pueden determinar el éxito de tu travesía con Scrum.

¿Scrum se implementa o se adopta?

El marco de trabajo Scrum consiste más en un cambio cultural en toda la organización que en simplemente la implementación de las herramientas o técnicas aquí descritas, así que es erróneo pensar en la “implementación” de Scrum, lo más apropiado es hablar de la “adopción” de Scrum, ya que se necesita poner en marcha las prácticas propuestas, realizar experimentos y estar ajustando continuamente el marco de trabajo a las necesidades cambiantes de la organización.

Para la adopción de las prácticas Scrum se requiere el apoyo de toda la organización, esta cultura orientada hacia lo ágil está basada en la simplicidad, el valor y el alto rendimiento.

¿Es valioso trabajar con procesos?

Si bien, en muchas organizaciones trabajar con procesos es visto como una gran ventaja porque asegura el buen desempeño de sus colaboradores, cuando hablamos de entornos ágiles, tendremos que ver la situación desde otro punto.

Las organizaciones cuentan con modelos de operación que tienden a comportarse de manera “estática”, en los que generalmente encontramos una estructura de jerarquías y burocracia, donde de manera rutinaria los colaboradores conocen los productos/servicios de la organización y saben cómo operar en el día a día para garantizar su adecuada entrega; sin embargo con los proyectos no siempre ocurre lo mismo debido a que los miembros del equipo de proyecto comúnmente se enfrentan a nuevos desafíos que los impulsa a cambiar constantemente y tomar una conducta autónoma en determinadas situaciones.

Por otro lado, vemos que las organizaciones fácilmente pueden percibir los beneficios de los procesos (facilitan las revisiones de calidad, la inducción del personal, las auditorías, etc) siempre y cuando estos procesos se lleven a la práctica y no permanezcan como simples documentos, ya que por sí solos no traen valor a la organización. Esta premisa aplica tal cual, a los ambientes ágiles, pues cuando hablamos de procesos debemos mantener un enfoque hacia la práctica (que sean interiorizados y ejecutados naturalmente por todos los miembros).

burocracia

Es importante mantener un sano equilibrio entre la típica burocracia organizacional (que desfavorece la agilidad) y la anarquía (que disminuye la credibilidad en el equipo). Cuando se encuentra y mantiene el punto medio entre estas dos, el equipo se encuentra en un entorno de agilidad: sin burocracia absoluta y sin anarquía absoluta.

Escalabilidad de Scrum

Scrum puede ser utilizado en grandes proyectos sin importar la cantidad de personas o actividades a desarrollar, esto siempre y cuando se respete la regla de formar pequeños equipos de personas, ya que este tipo de equipos son muy flexibles y adaptivos. Las fortalezas de los equipos Scrum que permiten su fácil escalamiento son:

Ahora bien, existen múltiple publicaciones donde puedes encontrar más información sobre este tema, citamos algunas a continuación:

Motivación del equipo

Cuando se trabaja en entornos de trabajo multidisciplinarios, la motivación es uno de los aspectos más importantes a tener en cuenta para conseguir un entorno de trabajo colaborativo y altamente competitivo, para lo cual es necesario promover a través del aprendizaje y la confianza, el desarrollo de habilidades de comunicación entre el colaborador y la empresa que garanticen el cumplimiento de las metas y retos individuales de cada una de las partes.

Es aquí donde queremos destacar el esfuerzo realizado por el autor Jurgen Appelo, en su publicación “Management 3.0”.

¡Hasta la Próxima Aventura Ágil!

Ha sido un viaje enriquecedor, explorando juntos las diversas dimensiones de Scrum. Esperamos que este manual no solo haya ampliado tu conocimiento, sino que también haya sembrado una semilla de curiosidad y pasión por continuar profundizando en el universo ágil.

Queremos expresar nuestro más sincero agradecimiento por permitirnos ser parte de tu travesía en el mundo de Scrum. No es una despedida, sino un hasta pronto, porque la agilidad es un viaje continuo de aprendizaje y crecimiento.

¡Gracias por confiar en CertMind para guiarte en esta fase de tu camino ágil! Esperamos reencontrarnos en futuras exploraciones, aventuras y descubrimientos.

¡Hasta la próxima!

6. Consideraciones finales

Anexo A: Adopción de Scrum en People Information LLC

Caso de Éxito: Transformación Ágil en People Information LLC

En la etapa inicial, People Information LLC se encontraba en una encrucijada crítica, lidiando con demoras significativas en la entrega de productos y una comunicación fragmentada entre los equipos. Los proyectos a menudo se desviaban de su curso, acumulando costos adicionales y minando la moral del equipo.

En este escenario crítico, la empresa reconocía que necesitaba una reestructuración significativa de su enfoque de gestión de proyectos. Por lo tanto, decidieron embarcarse en una jornada de transformación ágil, seleccionando Scrum como el catalizador de este cambio. Con el desarrollo de su próximo producto, un sofisticado software HRM en el horizonte, era imperativo que encontraran un enfoque más efectivo y ágil para gestionar el desarrollo del mismo.

Aunque no estuvieron exentos de enfrentar desafíos significativos.

En el camino, se toparon con una resistencia cultural significativa, con algunos miembros del equipo resistiéndose a dejar los métodos de trabajo anteriores. Además, hubo una comprensión inicial inadecuada de Scrum, lo que llevó a algunos malentendidos y aplicaciones incorrectas de sus principios en las primeras etapas.

Fase 1: Sensibilización y Formación Los empleados fueron capacitados en los fundamentos de Scrum, aunque enfrentaron problemas de falta de compromiso de algunos líderes senior, lo que ralentizó el proceso inicial de formación y sensibilización.

Fase 2: Planificación y Mapeo Se estableció un Product Goal claro, pero surgieron desafíos en cuanto a la gestión del Product Backlog, con algunos ítems insuficientemente definidos o incorrectamente priorizados. Esto condujo a ciertos problemas en la fase de mapeo, con equipos luchando por definir un MVP coherente y alcanzable.

Fase 3: Implementación y Adaptación Se formaron pequeños equipos multifuncionales que comenzaron a trabajar en sprints de dos semanas. A pesar de los problemas iniciales de colaboración y algunos conflictos derivados de una cultura organizacional inicialmente rígida, los equipos comenzaron a encontrar su ritmo, aprendiendo a colaborar más efectivamente y a adaptarse con más flexibilidad a los cambios.

A lo largo de la adopción, People Information LLC trabajó arduamente para superar estos obstáculos, ajustando su enfoque y aprendiendo de los errores iniciales. En pocos meses, notaron una entrega de productos más rápida y eficiente, junto con una mejora significativa en la satisfacción del cliente y la colaboración entre equipos.

La adopción de Scrum no solo transformó su proceso de desarrollo de productos sino que también cultivó una cultura de colaboración y adaptabilidad en toda la organización, demostrando que, a pesar de los desafíos, la adopción de Scrum puede conducir a resultados positivos y significativos.


Algunos elementos clave que ayudaron a People Information LLC a alcanzar el éxito a pesar de los desafíos:

  1. Liderazgo Comprometido: Los líderes de la organización estuvieron firmemente comprometidos con la adopción de Scrum, proporcionando el apoyo necesario para superar obstáculos.
  2. Formación Continua: Implementaron programas de formación continua para asegurar que todos los miembros del equipo estuvieran bien versados en los principios y prácticas de agilidad (no solo recibieron formación en Scrum).
  3. Comunicación Mejorada: A pesar de los problemas iniciales, trabajaron para mejorar la comunicación entre equipos y eliminar los silos de información.
  4. Ciclos Iterativos de Mejora: Utilizaron los ciclos iterativos de Scrum para aprender y ajustar continuamente su enfoque, permitiéndoles mejorar con cada sprint.
  5. Feedback del Cliente Incorporado: Aseguraron que el feedback del cliente estaba incorporado de manera regular en el proceso de desarrollo, lo que les ayudó a crear un producto más alineado con las necesidades del cliente.
  6. Cultura de Colaboración: Fomentaron una cultura de colaboración, donde cada miembro del equipo estaba motivado para trabajar juntos hacia un objetivo común.
  7. Resiliencia y Adaptabilidad: A pesar de los desafíos, mostraron una notable resiliencia y adaptabilidad, ajustándose a las lecciones aprendidas y perseverando a pesar de los obstáculos.

Estos elementos clave no solo ayudaron a People Information LLC a superar los desafíos de la adopción de Scrum, sino que también fueron fundamentales para su eventual éxito. Espero que estos puntos reflejen bien el espíritu de su transformación ágil.

6. Consideraciones finales

Glosario y anglicismos

Anglicismos

En este libro se utilizan varios términos utilizados originalmente en inglés, esto con el fin de no causar confusiones con las distintas traducciones que a estos se les pueden dar. A continuación, se encuentra el listado de términos que NO fueron traducidos en esta publicación, es decir, que se mantienen en su forma original: