Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Backlog de Sprint. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Backlog de Sprint. Mostrar todas las entradas

martes, noviembre 28, 2023

Los artefactos Scrum: un enfoque unificado para el éxito del producto

 

Fuente: https://www.linkedin.com/feed/update/urn:li:activity:7132793258551726080/

He tenido el privilegio de guiar a numerosos equipos y empresas a través de implementaciones exitosas de Scrum. Una de las preguntas más comunes que encuentro es: "¿Cuál es el artefacto principal en Scrum: el Product Backlog, el Sprint Backlog o el Incremento?"

En una encuesta reciente en LinkedIn realizada por Scrum Inc., a manera de trivia, el 74 % de los encuestados, incluyéndome, indicaron que los tres artefactos son igualmente críticos para el éxito de Scrum. Esto se alinea con mi propia experiencia, donde he sido testigo de cómo cada artefacto desempeña un papel distinto pero complementario a la hora de impulsar el desarrollo de productos.

Pero qué pasa con quienes dieron respuestas diversas: el 13% estaba a favor del Product Backlog, el 6% optó por el Sprint Backlog y otro 6% creía que el Incremento era el más crucial. Este último parece tener sentido, después de todo, se trata del objeto final de la iniciativa de producto, ir creándolo en pequeñas partes, pero ni siquiera tuvo una mayoría favorecedora dentro de los artefactos individuales.

La ilusión de la separación: un nombre inapropiado

Si bien cada artefacto posee sus propios méritos disímiles, la verdadera magia de Scrum radica en su interacción sinérgica. El Product Backlog proporciona una visión general, el Sprint Backlog traduce esa visión en tareas procesables y el Increment manifiesta esas tareas en valor tangible.

Es definitivo: la noción de que un artefacto reina sobre los demás es un error. Es como afirmar que los cimientos, las paredes o el techo de una casa son más importantes que los demás. Cada componente juega un papel crucial en la integridad de la estructura. De manera similar, cada artefacto Scrum contribuye al éxito general del proceso de desarrollo del producto.

El Product Backlog: la brújula visionaria

El Product Backlog sirve como base de Scrum y representa la visión en constante evolución del producto. Es una lista ordenada de características, requisitos y mejoras que definen el estado deseado del producto. Continuamente refinado y actualizado, el Product Backlog guía los esfuerzos del equipo, asegurando que estén alineados con la dirección estratégica del producto.

El Sprint Backlog: la hoja de ruta táctica

El Sprint Backlog, derivado del Product Backlog, traduce la visión del producto en tareas procesables para un solo sprint. Es una lista dinámica de historias de usuario, errores, tareas y otros elementos de trabajo que el equipo se compromete a completar durante el sprint. El Sprint Backlog proporciona enfoque y claridad, lo que permite al equipo ofrecer valor tangible al final de cada sprint.

El Incremento: la expresión concreta del progreso

El Incremento, la culminación de cada sprint, representa el producto funcional que está potencialmente disponible para los clientes. Es la manifestación tangible de los esfuerzos del equipo, que muestra las capacidades en evolución del producto y permite que se proporcione retroalimentación temprana para una mejora continua. El Incremento sirve como un faro de progreso, motivando al equipo y validando la dirección del producto.

Adoptando la naturaleza entrelazada de Scrum

El verdadero dominio de Scrum radica en reconocer la interconexión de estos artefactos. No son entidades aisladas sino más bien elementos interdependientes que se entrelazan para formar el tejido del éxito de Scrum. Descuidar un artefacto inevitablemente afecta a los demás, lo que dificulta la capacidad del equipo para entregar valor de manera consistente.

Cuando aceptamos el significado colectivo de los artefactos Scrum, liberamos el verdadero potencial del framework. Normalmente, capacito a los equipos para que naveguen por las complejidades del desarrollo de productos con agilidad, enfoque y mejora continua. Juntos, el Product Backlog, el Sprint Backlog y el Increment forman la piedra angular del éxito de Scrum, lo que permite a los equipos ofrecer productos que deleitan a los clientes e impulsan el crecimiento y la innovación en las empresas.

En mi experiencia, los intentos de aislar un artefacto como el más crucial a menudo conducen a una comprensión incompleta del enfoque holístico de Scrum. Cada artefacto juega un papel indispensable y su integración armoniosa forma la base del éxito de las iniciativas Scrum.

Estos instrumentos no son meras herramientas; son el alma de Scrum, son las expresiones tangibles de una mentalidad ágil. Encarnan los principios de mejora continua, colaboración y adaptabilidad, transformando el proceso de desarrollo de productos en un viaje de experiencias y evolución continuas.

Entonces, la próxima vez que reflexiones sobre la importancia relativa de los artefactos Scrum, recuerda que no son entidades aisladas sino hilos interconectados que tejen el tapiz del éxito de Scrum.

viernes, noviembre 12, 2021

illegitimus non-interruptus

Imagen de Christine Schmidt en Pixabay

Dentro de lo más común en los escenarios de alta incertidumbre, ambigüedad y volatilidad en los que trabajamos están las interrupciones a nuestro trabajo diario. Mal manejadas, estas obstrucciones se pueden convertir en un gran dolor de cabeza para la persona, para el equipo y para la organización y, por consiguiente, para el cliente final.

Entre otras consecuencias no menos graves, tenemos la pérdida de foco en lo que hacemos, con la consiguiente parálisis o alejamiento del objetivo del sprint. Además, el estrés ocasionado por las intermisiones puede llegar a ser contraproducente para la salud del producto, pero, más crítico aún, para la salud de las personas.

Algunas investigaciones [1] muestran que la multitarea ocasionada, entre otras cosas, por las interrupciones frecuentes en el trabajo, te hace estúpido y lento, al tiempo que aumenta el estrés y acelera el envejecimiento. Adicionalmente, la multitarea puede reducir la velocidad o el ritmo de un equipo tanto como a nada.

Fui desarrollador de software durante diecisiete años y sé bien que la multitarea siempre ha sido una parte inherente del desarrollo de software y la experimenté como la principal fuente de interrupciones debido al cambio continuo de tareas en los equipos de desarrollo de software.

Este trabajo implicaba para mí una combinación de tareas analíticas y creativas, y requería de una carga significativa en mi “memoria de trabajo” y en la toma de decisiones. Esto imponía una carga cognitiva que me hacía perder el enfoque y la concentración mientras trabajaba, lo que afectaba mi productividad. Perentorio.

Los invito a visitar este enlace, donde podrán ver de manera gráfica y cómica a la vez, por qué no deberías interrumpir a un programador cuando está haciendo su tarea:

https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

Pero estas dificultades no son propias solo del desarrollo de software. Como mencioné antes, todo trabajo bajo escenarios VUCA/BANI está supeditado a tener tales aprietos. ¿Entonces, qué hacer con estas interrupciones si son inherentes a nuestro trabajo?

Si estamos usando Scrum, las demandas de distintas áreas, combinadas con la interferencia de la gerencia, pueden causar una disfunción crónica en el equipo, fallas repetidas en sprints, incumplimiento en fechas de lanzamiento e incluso fallas en la empresa. Muchas veces un equipo Scrum sirve a muchos interesados, quienes compiten por la atención del equipo.

Patrones Scrum

En Scrum hemos aprendido a usar patrones, estos son modelos de comportamiento que nos ayudan a solucionar problemas comunes. Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, y luego describe el núcleo de la solución a ese problema, de tal manera que puedes usar esta solución un millón de veces, sin hacerlo dos veces de la misma manera. O algo así nos enseñó Christopher Alexander en su libro A Pattern Language. Alexander es conocido como el “padre de los patrones”. Para conocer un poco más sobre esto puedes ver mi presentación en:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

Un patrón nos ayuda a explorar:

·       El problema, su naturaleza, la causa raíz. El problema detrás del problema.

·       Las fuerzas que interactúan que afectan el problema (que lo hacen difícil), incomprensible a veces.

·       La solución. Y por qué funciona esta solución. En qué condiciones funciona. Y

·       El contexto resultante de aplicarlo en un escenario de la vida real.

illegitimus non-interruptus

A veces también llamado el patrón del búfer de interrupción (Interrupt Buffer). Es un hecho, cambiar las prioridades o los problemas en el campo a menudo interrumpe el trabajo de los equipos Scrum durante un sprint.

En general, un equipo Scrum es un equipo o recurso comunitario que satisface las necesidades de muchas partes interesadas. Además, es un recurso crítico para crear nuevos productos y mantener productos existentes [2]. A menudo, la propiedad deficiente del producto permite que las prioridades en competencia de una empresa lleguen a un equipo Scrum. Por estas y muchas otras razones, un equipo Scrum siempre está expuesto a interrupciones que obstaculizan la producción.

Figura 2: principales tipos de interrupción a un equipo

Dada esa situación, lo que hacemos, siguiendo los lineamientos de este patrón es asignar explícitamente tiempo para las interrupciones y no permitimos más trabajo del que cabe dentro de la asignación. Ahora bien, si el trabajo excede la asignación (se desborda el búfer), podemos tomar la decisión de abortar el Sprint. Si el búfer se excede, es posible que tengamos un problema mayúsculo, uno cuya solución seguramente necesite del uso de otros patrones o de cambios en la estrategia actual de trabajo. Una estrategia inicial que se aplica en estos casos es cancelar o abortar el sprint.

Veamos esta solución con un poco más de detalle…

1.    Lo primero es tener una idea aproximada de cuanto esfuerzo o tiempo necesitamos asignar al búfer. O sea, decidir el tamaño del búfer de interrupción en el sprint backlog. Una revisión tipo “Clima de ayer” nos puede dar una idea. Es decir, revisar qué tanto esfuerzo han requerido las interrupciones en el sprint anterior o quizás un promedio de los últimos tres sprints.

En la figura a continuación vemos, como ejemplo, que el búfer de interrupción se ha movido alrededor de los 7 puntos, tanto en el sprint anterior, como en los tres últimos. De hecho, la gráfica muestra un comportamiento similar en los últimos 7 sprints, pero esto es apenas una casualidad. Quizás se trate de un equipo con una alta sinergia y que tiene un histórico bastante bien conocido. Sin embargo, no es tan bueno considerar lo que ha pasado durante tiempos más extensos, más allá de dos o tres sprints, ya que las condiciones del equipo y del trabajo pueden haber cambiado de manera considerable.

Figura 3: gráfico de la velocidad del equipo en los últimos sprints. Incluye búfer de interrupción.

Entonces, aunque la velocidad del equipo, según la gráfica histórica, es de alrededor de 27 puntos (usando también el promedio de los tres últimos sprints), el equipo solo se comprometerá con 20 puntos de historia y considerará un tamaño de búfer de 7 puntos.

2.    ¿Y entonces qué hacemos cuando se presenta una interrupción? Respuesta: todas las solicitudes no triviales deben pasar por el Product Owner para su clasificación. Es importante esto de lo “no trivial”. No se trata de que el Product Owner “apruebe” todas las actividades no planeadas para el sprint. Pero sí las que sabemos que pueden impactar en negativo el recorrido hacia el objetivo del sprint.

Figura 4: comportamiento del búfer de interrupción en el sprint backlog.

3.    De manera natural vamos “midiendo” y evaluando el “llenado” del búfer de interrupción. Es una actividad que debe inyectarse al ADN del equipo, para que se haya sin mayores atribulaciones. Cuando el búfer se “llene” y comience a desbordarse, es decir, el Product Owner o el equipo pone un punto de más de los indicados en el búfer, el Scrum Team debe o debería abortar el Sprint, no sin antes, hacer el análisis de causa en una retrospectiva.

Lo que hemos comprobado es que esta estrategia ayudará al equipo a volver a planificar durante el Sprint para aumentar las posibilidades de entregar el Incremento completo del producto. Ya por lineamiento de Scrum habíamos aprendido que, durante el sprint, “el alcance se puede aclarar y renegociar con el Product Owner a medida que se aprende más”.

Recomendaciones

En la práctica, el búfer de interrupción puede ser un porcentaje de tiempo. Por ejemplo, el 7 % del tiempo del sprint, el 10 %, el 14 %, etcétera.

¿Cuánto tiempo? ¿Cuál es el tamaño ideal del búfer de interrupción? Esa es una cuestión cuya respuesta debe encontrar el equipo. Para considerar: el objetivo de todo equipo Scrum es entregar valor (un incremento de valor) al final de cada sprint.  Entonces, el foco del equipo debe estar en este aspecto: la entrega de valor. Pero, incluso más importante, son las tareas o actividades “kaizen”, sí, esas de mejoramiento, a las que también hay que dedicarles tiempo y esfuerzo y con una prioridad máxima.

En general, debería ser el Dueño del Producto quien equilibre el tamaño del búfer para no descompensar la satisfacción del cliente en el corto plazo y mucho menos disminuir la generación de ingresos para la organización. El objetivo de todo Product Owner virtuoso es mantener con el equipo un tamaño de búfer tal que no se impacte en negativo la entrega de valor.

Y no, las tareas de mejora continua (kaizen) no son consideradas como “de interrupción”. De hecho, estas actividades deben planificadas como las de mayor prioridad dentro de un sprint. De lo contrario, ¿cómo aseguramos que el equipo mejore en el mediano y largo plazo? ¿Cómo aseguramos que en el futuro las cosas se hagan mejor y haya tiempo para innovar o ser más disruptivos? (Ver en la imagen donde están estas tareas en el Sprint Backlog).

Lo ideal es que el búfer de interrupción tienda a no estar lleno, lo que permitirá que el equipo termine temprano y avance desde el trabajo atrasado o trabaje para eliminar los impedimentos. Y esto es primordial porque los equipos que terminan temprano aceleran más rápido. Este es otro patrón Scrum cuya información, por ahora, puedes revisar en:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

Finalmente, si el equipo usa el patrón el Clima de Ayer para dimensionar el búfer de interrupción, como lo expliqué en el paso 1, entonces el búfer casi nunca se llena y podemos empezar a pensar en reducir gradualmente su tamaño, lo que hará desaparecer el problema de interrupción. Aunque en la práctica, quizás nunca llegue a cero. Es lo que he experimentado.

Algunas referencias

[1] Darren Rowley and Manfred Lange. “Forming to Performing: The Evolution of an Agile Team.” In Proceedings of Agile 2007, Washington, D.C., 2007, pp. 408-414.

[2] Ver definición de Producto en la guía de Scrum.

 

Para conocer más de patrones Scrum, puedes ver esta presentación y video: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

En particular, para saber más del patrón Illegitimus non interruptus, puedes mirar esta otra presentación:

https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

El libro de los patrones Scrum, A Scrum Book, de Coplien, Sutherland y otros.

jueves, septiembre 10, 2020

Planificar historias de usuario en tareas


El trabajo a realizar durante el Sprint se planifica en la Planificación de Sprint. Este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.

En particular, en esta presentación  muestro algunos ejemplos de cómo descomponer historias de usuario de un backlog de producto en tareas de un backlog de sprint. También explico algunas prácticas y guías a tener en cuenta a la hora de la planificación.

Estas y otras ideas, en la presentación que puedes ver y descargar aquí.