viernes, 17 de abril de 2026

Agilidad Agéntica (Agentic Agile)



Estamos descubriendo formas mejores de desarrollar software potenciados con IA.  Vivimos en un tiempo de "Agilidad Agéntica" ("Agentic Agile") donde la integración de la IA generativa con Agile, potencia sus principios fundamentales. El objetivo no es eliminar la intervención humana del proceso de desarrollo, sino crear equipos altamente eficaces, potenciados por la IA, que combinen la creatividad y el pensamiento estratégico humanos con la velocidad y el poder analítico de la IA. El futuro inmediato del desarrollo de software pertenece a quienes adoptan esta sinergia.


El manifiesto ágil no está deprecado, sino que evoluciona. Todavía es necesario potenciar "Individuos e interacciones" solo que ahora se agrega IA a la sinergia, entregar "Software funcionando" sigue siendo prioridad y ahora puede hacerce en menos de dos meses, como siguiere el manifiesto, o inluso menos de una semana (en horas), "colaborar con el cliente" sigue siendo crucial solo que ahora los ciclos de feedback son más rápidos y efectivos, y "responder al cambio" se convierte en una capacidad de adaptación extrema. Hoy en día, la incertidumbre y la aceleración del cambio son extremas. Sin embargo, la forma en que se manifiestan estos valores se transforma radicalmente con la IA.

Los valores de la Agilidad Agéntica se adaptan a esta nueva realidad:

  • Valor 1: Individuos e interacciones → Orquestación Humana de Agentes IA
  • Valor 2: Software funcionando → Arquitectura Coherente y Especificaciones Ejecutables
  • Valor 3: Colaboración con el cliente → *Validación Continua de Valor Híbrida
  • Valor 4: Respuesta ante el cambio → Adaptación Extrema y Gobernanza de Riesgos

Valores de la Agilidad Agéntica


💎  Valor 1: Individuos e interacciones → Orquestación Humana de Agentes IA
La agilidad ya no depende solo de cómo colaboran los humanos entre sí, sino de cómo los humanos orquestan, gobiernan y se comunican con los agentes de IA aplicando «ingeniería agéntica». El valor se traslada de la mera interacción a la dirección estratégica: los humanos definen el "qué", el "por qué" y "cómo" crear arquitecturas agénticas, mientras la IA ejecuta el "cómo" táctico. Esto requiere habilidades de prompting, ingeniería agéntica, validación crítica y supervisión ética. La orquestación efectiva convierte a los equipos en centros de control de un ecosistema de agentes especializados.

💎 Valor 2: Software funcionando → Arquitectura Coherente y Especificaciones Ejecutables
Con IA generando código masivamente, el verdadero cuello de botella ya no es la implementación, sino la claridad arquitectónica. El software debe ser resiliente, mantenible y alineado con el negocio. Esto se logra mediante especificaciones ejecutables (Spec‑Driven Development) que actúan como fuente de verdad para los agentes de IA. El valor cambia de "que funcione" a "que esté bien estructurado y gobernado", evitando la deuda técnica acelerada.

💎 Valor 3: Colaboración con el cliente → Validación Continua de Valor Híbrida
La IA permite ciclos de feedback ultrarrápidos: los prototipos y features se generan en minutos, no en semanas. La colaboración se intensifica porque los humanos pueden dedicar más tiempo a entender las necesidades profundas del cliente y a validar hipótesis de valor. La validación es híbrida: la IA produce, el cliente reacciona, y el equipo ajusta la estrategia en tiempo real. El valor se centra en la frecuencia y calidad del aprendizaje conjunto, no en la entrega masiva de código.

💎 Valor 4: Respuesta ante el cambio → Adaptación Extrema y Gobernanza de Riesgos
Responder al cambio ya no es solo reaccionar, sino anticiparse. La IA permite modelar escenarios, simular impactos y sugerir rutas de adaptación antes de que el cambio ocurra. El valor evoluciona hacia una gobernanza proactiva del riesgo, donde los humanos definen "guardrails" (límites y políticas) y la IA explora alternativas dentro de ellos. La adaptación extrema combina velocidad de ejecución con control estratégico, transformando la incertidumbre en una ventaja competitiva.

Metodologías en la Era de la Agilidad Extrema con Ingeniería Agéntica


Metodologías como Scrum, Kanban, XP, FDD, BDD y TDD siguen siendo relevantes, pero su aplicación se transforma.

  • Scrum: Por ejemplo, en Scrum los sprints pueden ser más cortos en lugar de semanas. Se podrían trabajar verdaderamente con slicing vertical o con historias de usuario más grandes pero mejor especificadas. Podríamos entregas épicas enteras en un sprint de una o dos semanas. Y las ceremonias (eventos) se enfocan más en la alineación estratégica, la especificación usando IA, y la revisión de resultados generados por IA que en la gestión de tareas manuales. Los ciclos ultra cortos permiten la Validación Continua de Valor Híbrida. Y ahora los líderes facilitadores de Scrum también deben ser expertos en orquestación de agentes IA, asegurando que la colaboración humano-IA sea fluida y efectiva.
  • Kanban: En Kanban, el flujo de trabajo se optimiza para la colaboración humano-IA. Se agregan validaciones y revisiones humanas en todo el flujo. Las tarjetas representan no solo tareas humanas, sino también "tareas de IA" que pueden ser asignadas a agentes específicos. El enfoque se desplaza hacia la gestión del flujo de valor a través de esta colaboración, con métricas que reflejan tanto la eficiencia humana como la eficacia de la IA. Tal vez la IA se lleva mejor con el sistema Kanban, con señales, flujos de trabajo, coordinación mediante tableros visuales y métricas de rendimiento que se adaptan a su naturaleza dinámica; y juntos permiten la **Orquestación Humana de Agentes IA**. Admeás, los maestros del flujo Kanban también deben ser orquestadores de humanos y agentes IA.
  • FDD, BDD y TDD: Estas metodologías de desarrollo orientadas a la especificación y validación se vuelven aún más críticas. La IA puede generar código, pero la calidad y alineación con los requisitos del negocio dependen de especificaciones claras. FDD (Feature‑Driven Development) se enfoca en características bien definidas, BDD (Behavior‑Driven Development) asegura que el comportamiento del software esté alineado con las expectativas del cliente, y TDD (Test‑Driven Development) garantiza que el código generado por IA sea confiable y mantenible. Estas metodologías actúan como "guardrails" para la generación de código, asegurando que la IA produzca resultados coherentes y valiosos. Estas metodologías se pueden ver potenciadas por la automatización y la generación de código, y a su vez brindan la posibilidad de **Arquitectura Coherente y Especificaciones Ejecutables**.

La Agilidad Extrema con Ingeniería Agéntica no es una ruptura con el pasado, sino una evolución que amplifica sus principios fundamentales con el poder de la IA. La clave del éxito en esta nueva era es la capacidad de los equipos para orquestar esta sinergia de manera efectiva, manteniendo el enfoque en la entrega de valor real y sostenible y gestionando los riesgos que la IA puede introducir.

Hoy en día, la agilidad extrema con ingeniería agéntica es la nueva frontera del desarrollo de software, y aquellos que la dominen estarán mejor posicionados para prosperar en un mundo cada vez más impulsado por la tecnología. Los líderes de esta era no solo serán expertos en metodologías ágiles, sino también en la orquestación de agentes IA, la gestión de riesgos y la creación de arquitecturas coherentes que permitan a sus equipos alcanzar niveles de productividad y calidad sin precedentes. Para eso es necesario adoptar una mentalidad de aprendizaje continuo, experimentación y adaptación, donde la colaboración entre humanos y máquinas se convierta en el núcleo de la innovación y el éxito en el desarrollo de software. Los líderes debemos ser innovadores y "early adopters".


jueves, 31 de julio de 2025

Remoción de impedimentos: El iceberg de los problemas

 

El iceberg de los problemas

En el día a día de un equipo ágil, nos topamos constantemente con obstáculos. A menudo usamos términos como "bloqueo" e "impedimento" de forma intercambiable, pero entender sus diferencias es crucial para una gestión y una remoción efectiva de impedimentos. Además, si no llegamos a la "causa raíz", solo estaremos apagando incendios superficialmente.


Vamos a aclarar estos conceptos fundamentales basadis en el "Iceberg de los problemas".


1. Bloqueos

Un bloqueo es una situación actual que detiene completamente el progreso inmediato de un artículo de trabajo (historia de usuario o tarea) . Es una barrera infranqueable que impide que el equipo o un miembro del equipo avance en su tarea. El trabajo se detiene "aquí y ahora".

Características:

  • Detiene el progreso: El trabajo no puede continuar.

  • Actual y directo: Es un problema presente y concreto.

  • Alta visibilidad: Suele ser obvio que el trabajo está parado.

Ejemplos comunes:

  • Fallas del entorno técnico: El entorno de desarrollo está caído.

  • Dependencia de otro equipo/miembro: Necesita la entrega de un componente crítico de otro equipo para continuar su tarea, y esa entrega no está disponible.

  • Errores graves de ACL o seguridad: No tienes los permisos necesarios para acceder a un recurso vital para tu trabajo.

  • Recurso no disponible: El servidor de pruebas está caído y nadie puede trabajar en él.


2. Impedimentos

Un impedimento es un obstáculo o dificultad que ralentiza o dificulta el progreso del equipo o de las tareas , pero no necesariamente las detiene por completo. Puede ser una fricción, una ineficiencia o un problema recurrente. Los bloqueos son un tipo de impedimento, pero no todos los impedimentos son bloqueos.

Características:

  • Ralentiza/dificulta: No necesariamente detiene por completo.

  • Puede ser recurrente: A menudo son problemas sistémicos.

  • Más amplio que un bloqueo: Puede afectar a varias tareas o al flujo general del equipo.

Ejemplos comunes:

  • Reuniones improvisadas/excesivas: Consumen tiempo valioso y rompen el foco del equipo.

  • Falta de habilidades necesarias: El equipo carece de una habilidad específica para una tarea, lo que los ralentiza.

  • Problemas de hardware/software (sistema lento, fallas de internet): Dificultan la productividad, pero no la desconectada por completo.

  • Cambios frecuentes en los requisitos: Obligan a retrabajo y rompen el flujo.

  • Malentendidos entre miembros del equipo: Generan fricciones y comunicación ineficiente.

  • Presión por parte de la dirección: Puede llevar a atajos o crunch mode .

  • No saber hacer una "Solicitud de cambio" para desplegar en producción: Ralentiza el despliegue.

  • No tener un entorno de pruebas habilitado que suelen ser pedidos a un equipo de DevOps o Infraestructura: Si bien es un cuello de botella, el trabajo puede avanzar en otras áreas mientras se espera.

  • Equipo desmotivado: Impacta la productividad general.


3. Riesgos

Un riesgo es un evento o condición incierta que, si ocurre, tendrá un efecto positivo (oportunidad) o negativo (amenaza) en los objetivos del proyecto o del producto. No ha sucedido aún; es una posibilidad futura.

Características:

  • Incierto: Puede ocurrir o no.

  • Futuro: No es un problema presente, sino potencial.

  • Potencial de impacto: Si se materializa, tendrá consecuencias.

Ejemplos comunes:

  • Complejidades que no pudieron preverse con antelación: Existe la posibilidad de que una funcionalidad sea más compleja de lo estimado.

  • Dependencia futura de software de terceros: Existe el riesgo de que una librería externa necesaria no esté lista a tiempo.

  • Miembro del equipo enfermo (planeado): Saber que un experto clave estará de vacaciones en el futuro crea un riesgo de capacidad.

  • Arquitecturas deficientes (potenciales): La arquitectura actual no puede escalar a futuro, lo que es un riesgo para el crecimiento.


4. Causas Raíz

Una causa raíz es el origen o la razón fundamental de un problema (bloqueo, impedimento, riesgo materializado) . Es el factor subyacente que, si se elimina, previene la recurrencia del problema o reduce su impacto. No es el síntoma, sino la razón más profunda por la que aparece el síntoma.

Características:

  • Origen del problema: Es la causa fundamental.

  • Profundo: No es superficial, requiere información.

  • Eliminación evita recurrencia: Abordarla previene futuros problemas.

Ejemplos:

  • Falta de Seguridad Psicológica en el ambiente de trabajo.

  • Una API Legacy : Existe una API Legacy que tiene alta probabilidad de fallar por usar tecnologías obsolteas y arquitectura monolítica y con deudas técnicas que no soporta la sobrecarga de peticiones.


El rol de los líderes:

Hay roles que tienen como parte de su función la remoción de impedimentos. El Scrum Master, por ejemplo, es el principal responsable de ayudar al Equipo Scrum y a la organización a abordar los bloqueos e impedimentos que dificultan el progreso y la adopción de agilidad. Esto incluye no solo eliminarlos, sino también identificar los riesgos antes de que se materialicen y, principalmente, llegar a las causas raíz para implementar mejoras sistémicas. Sin esta claridad, los equipos se limitan a "apagar incendios" sin resolver los problemas de fondo.

Otros roles y cualquier líder ágil debería pensar sistémicamente para mejorar la organización solucionando los problemas de causa raíz. Una herramienta del pensamiento sistémico es el Iceberg del pensamiento sistémico. 

El iceberg del pensamiento sistémico es un modelo de pensamiento útil para los líderes que abordan problemas insolubles que parecen no desaparecer. Parte del desafío reside en lo que el modelo denominado "eventos": problemas superficiales que están constantemente presentes, que en esencia sirven para apagar incendios, pero que nunca abordan las verdaderas causas.

Entender estas diferencias y el modelo propuesto es el primer paso para transformarse en un removedor de impedimentos efectivo y un agente de cambio para llevar a tu organización a otro nivel.



Referencias:











miércoles, 30 de julio de 2025

Estimación con Historia Pivote

 

¿Historias de Usuario Gigantes? ¡Domina la Estimación Relativa con la "Historia Pivote"!

¿Alguna vez te has enfrentado a un Product Backlog lleno de historias de usuario enormes, sin una idea clara de cuánto trabajo representan? O quizás, tu equipo tiene dificultades para llegar a un consenso en las estimaciones, con debates que se alargan sin fin. ¡No estás solo! En el mundo ágil, estimar la complejidad de una manera eficiente y colaborativa es un desafío común.

Aquí es donde entra en juego una técnica sencilla pero increíblemente potente: la Estimación por Analogía utilizando una "Historia Pivote" (variante simple de "Bucket System Estimation") .

La Historia Pivote: Tu Ancla para la Estimación

Imagina que estás en medio del océano y necesitas saber dónde estás. Necesitas un punto de referencia. La historia pivote es exactamente eso para tu equipo: una historia de usuario que todos conocen bien, que ya se ha completado o cuyo esfuerzo y complejidad son comprendidos por todo el equipo.

Esta historia de referencia es tu "ancla". Debe medir un valor intermedio, idealmente 3 o 5 Story Points, para que sirva como un buen punto de comparación para otras historias, tanto más grandes como más pequeñas.

La clave es que todos en el equipo sepan:

  • Qué significa: Su alcance, dependencias, y el "Definition of Done".

  • Cómo se desarrolló: Las tareas necesarias y el esfuerzo real que implicó.


¿Cómo Funciona la Estimación con Historia Pivote?

Una vez que tienes tu historia pivote definida, el proceso para estimar una nueva historia se vuelve sorprendentemente intuitivo:

  1. Comparación Directa: Al mirar una nueva historia de usuario, la pregunta fundamental es: "¿Es menor, igual o mayor que nuestra historia pivote (por ejemplo, de 5 Story Points)?"

  2. Afinando la Comparación:

    • Si es mayor: "¿Es el doble de mayor, más del doble, o solo un poquito mayor?"

    • Si es menor: "¿Es la mitad, menos de la mitad, o más de la mitad?"

  3. Asignación Relativa: Con base en esta comparación intuitiva, el equipo elige un valor relativo (en Story Points) que mejor represente el tamaño y la complejidad de la nueva historia.

Este proceso aprovecha la capacidad natural de nuestro cerebro para comparar elementos relativos, lo cual es mucho más eficiente que intentar dar una estimación absoluta desde cero para cada nueva funcionalidad.


La Sinergia con otras Técnicas Ágiles

La estimación con una historia pivote no es una técnica aislada; de hecho, complementa a la perfección otras maneras de estimar como el Planning Poker.

En una sesión de Planning Poker, después de leer una historia, el equipo puede referirse a la historia pivote para anclar sus discusiones. Si las estimaciones varían, el debate no se centra en "por qué tu 8 es diferente de mi 5", sino en "¿por qué crees que esta es el doble de grande que nuestra historia pivote, mientras que yo la veo solo un poco más grande?". Esto lleva a conversaciones más ricas sobre los detalles, la incertidumbre y los supuestos subyacentes.

Al integrar la historia pivote en tu proceso de estimación, no solo harás tus sesiones más rápidas y consistentes, sino que también fomentarás un entendimiento más profundo y compartido del trabajo entre todos los miembros de tu equipo. ¡Anímate a encontrar la historia pivote de tu equipo y observa cómo tus estimaciones se vuelven más ágiles!






viernes, 18 de julio de 2025

Agile BRD y Lean Business Case

 

¡Adiós al Papeleo! Cómo Transformar tu BRD y Business Case a la Agilidad


¿Tu equipo está adoptando metodologías ágiles como Scrum, pero sigues ahogado en documentos de requisitos kilométricos y planes de negocio que se quedan obsoletos antes de ver la luz? No te preocupes, no estás solo. El Documento de Requisitos Comerciales (BRD) y el Business Case tradicional, nacidos en la era predictiva, pueden convertirse en un lastre en el mundo de la agilidad.

Pero la solución no es eliminar la necesidad de entender qué construir y por qué. Es transformar la forma en que lo hacemos. ¡Es hora de darle un giro ágil a tu gestión de requisitos y justificación de negocio!

¿Por Qué el BRD y el Business Case Tradicional No Funcionan en Agile?

Los enfoques tradicionales, aunque útiles en su contexto, chocan frontalmente con los principios ágiles:

  • Son Estáticos: Se asume que los requisitos se pueden definir completamente al principio y que no cambiarán. ¡Error fatal en un mercado dinámico!

  • Enfoque en el "Input" (Documento): Se valora más la completitud del documento que la entrega de valor real.

  • Fomentan el "Big Design Up Front" (Gran Diseño por Adelantado): Se intenta planificar y detallar todo antes de empezar a construir, generando burocracia y demoras.

  • Crean Silos: El BRD a menudo es entregado de "negocio" a "TI", creando una separación que va en contra de la colaboración continua.

  • Basados en Supuestos, No en Aprendizaje Validado: Las decisiones de inversión se toman con base en proyecciones y suposiciones no probadas, aumentando el riesgo de construir lo incorrecto.

La Transformación Ágil: De la Especificación a la Colaboración y la Evidencia

En un entorno ágil, no eliminamos la necesidad de claridad y justificación, sino que las infundimos con flexibilidad, empirismo y aprendizaje continuo:

1. Del BRD a un Product Backlog Vivo y Escenarios Gherkin

Olvídate del BRD como un documento estático. Su esencia se descompone y se integra en el día a día del equipo:

  • De redacción aislada a Discovery colaborativo: se propone hacer descubrimiento inicial y contínuo.

  • De justificación de beneficio comercial a hipótesis de resultados esperados: justificación de iniciativas grandes hacia un enfoque más ágil, impulsado por el valor, basado en hipótesis y que busca la adaptación continua midiendo el éxito de forma empírica.

  • De Requisitos Exhaustivos a Historias de Usuario: Las funciones se describen como Historias de Usuario concisas ("Como [rol], quiero [funcionalidad], para [beneficio]"). No se detallan exhaustivamente al inicio, sino que se refinan progresivamente.

  • De Anexo de Detalles a Criterios de Aceptación Ejecutables: Los criterios de aceptación se vuelven el nuevo "detalle". Se escriben Just-in-Time (justo a tiempo) en un formato claro como Gherkin (Dado-Cuando-Entonces). Estos escenarios son tan precisos que sirven como base para pruebas automatizadas, garantizando que el "qué" se construye es el "qué" se acordó.

  • Del Control de Cambios Burocrático al Refinamiento Continuo: El Product Backlog no se "congela". Es un artefacto vivo que se refina continuamente en colaboración con el Equipo de Desarrollo, permitiendo la adaptación constante a nuevas informaciones y aprendizajes.

2. Del Business Case Tradicional a un Lean Business Case

El Business Case, esa "biblia" financiera de justificación, también evoluciona. Deja de ser un documento rígido de promesas a largo plazo para convertirse en una serie de hipótesis que se validan continuamente:

  • De Proyecciones Financieras Fijas a Hipótesis de Beneficio: En lugar de prometer un ROI exacto a 3 años, se formula una Hipótesis de Beneficio clara y medible: "Creemos que [esta solución] logrará [este beneficio] para [estos clientes], lo que sabremos cuando veamos [esta métrica/KPI]."

  • Del Plan de Inversión Único a la Financiación por Valor (Lean Budgets): La inversión no se aprueba de golpe para todo el proyecto. Se asignan fondos de manera incremental a iniciativas de valor, permitiendo pivotar o perseverar basándose en el aprendizaje validado.

  • De la Validación al Final a la Experimentación Temprana: El éxito no se mide solo al final. Se construyen Productos Mínimos Viables (MVP) para probar las hipótesis más arriesgadas con la menor inversión posible. El objetivo es aprender rápido si la idea genera valor antes de escalar.

¡El Futuro es Flexible, No Fijo!

Transformar tu BRD y Business Case a un marco ágil no significa dejar de lado la disciplina; significa adoptarla de una manera más inteligente y efectiva. Puedes manejar un Agile BRD y/o Lean Business Case si los necesitas o distribuir su información en diferentes artefactos evolutivos y empíricos (Product Wall, Portfolio, Product Backlog, etc.).

Es un cambio de mentalidad que te permite construir productos más valiosos, adaptarte más rápido a los cambios del mercado y asegurar que cada inversión se traduzca en resultados medibles.

Así que, Product Owner, es hora de tirar los viejos manuales y abrazar un enfoque más dinámico. ¡Tu producto y tu equipo te lo agradecerán!





viernes, 11 de julio de 2025

Planning Checklist

 

Las listas de verificación de eventos scrum o de ceremonias o cadencias son una herramienta útil para el aprendizaje y para guiar a los facilitadores en sus momentos de inicios o cuando se platean mejorar aspecto de cómo facilitan las reuniones de trabajo; y si se aplica a un nivel operativo y práctico, reduce la carga cognitiva y te permiten dedicar tiempo a tareas más relevantes. Lo ideal de un checklist es que sea simple, por eso a medida que evoluciones podrás hacer tus checklist más simples, como meros recordatorios y estructura para tu equipo. A continuación comparto una lista de verificación de la Planeación de Scrum más extensa solo como herramienta de aprendizaje.

LISTA DE VERIFICACIÓN DE PLANIFICACIÓN

(DE ITERACIÓN)


Preparación de la planificación del sprint:

  • desenfrenado

    Aborde el número de boletos abiertos en las columnas de "revisión de código" y "listas para aceptación". Solicite a los miembros del equipo que se centren en mover los boletos a "Listos" antes de comenzar a trabajar en nuevos boletos.

  • desenfrenado

    Pedir a los miembros del equipo que actualicen los tableros de Sprint.

  • desenfrenado

    Ejecutar la Revisión del Sprint. (Pregunta: ¿Logramos el Objetivo del Sprint? ¿Seguimos encaminados para alcanzar el objetivo del producto en el próximo Sprint?)

  • desenfrenado

    Ejecutar la retrospectiva del sprint. (Seleccionar acciones de mejora continua para el próximo sprint).

  • desenfrenado

    Refinamiento : Asegúrese de que el PO busque que los asistentes estén preparados para debatir los elementos más importantes del Backlog del Producto y su relación con el Objetivo del Producto. 

  • desenfrenado

    Invitados : El Equipo también puede invitar a otras personas a la Planificación del Sprint para que brinden asesoramiento.

  • desenfrenado

    DOD : Asegúrese de que el equipo tenga una Definición de Completo (DOD).

  • desenfrenado

    No “pre-asignar tareas” : La pre-asignación de tareas es una mala idea porque socava la autogestión, reduce la adaptabilidad y desvía la atención del objetivo del sprint.

  • desenfrenado

    Planifica un timebox : 8 horas para un Sprint de 1 mes. No debería exceder las 4 horas para Sprint de 2 semanas.

  • desenfrenado

    La agenda se determina con antelación y está disponible para todos los asistentes.

  • desenfrenado

    Recordar a todos los miembros del equipo la planificación del sprint de mañana.


Durante la planificación del sprint:

  • desenfrenado

    Configuración : Inicie la planificación del Sprint compartiendo una sesión de videoconferencia para aquellos miembros del equipo que no puedan participar en la planificación del Sprint en persona.

  • desenfrenado

    Cerrar el Sprint anterior :

    • desenfrenado

      Limpiar el tablero antiguo con todo el equipo Scrum: revisa el tablero, verifica el estado de cada ticket y muevelo si es necesario (Sincronizar el tablero offline con el tablero de Jira). 

    • desenfrenado

      Analice el posible impacto: ¿Siguen siendo valiosos los elementos inacabados (carry over) del Product Backlog? (Los impactos son una métrica adecuada para el equipo y un buen tema para una retrospectiva. Si persisten durante varios sprints, esto debería generar diversas discusiones en el equipo)

    • desenfrenado

      Mueva todos los elementos del Product Backlog que tendrán repercusiones a los grupos adecuados, por ejemplo, el próximo Sprint o el Product Backlog.

    • desenfrenado

      Limpia el tablero físico de los viejos recordatorios del Sprint anterior.

    • desenfrenado

      Si los elementos del Product Backlog no terminados no se trasladarán al próximo Sprint, entonces muévalos al Product Backlog o elimínelos/archívelos.

  • desenfrenado

    Crear nuevo Sprint : Si aún no está disponible, crea un nuevo “Sprint” (en Jira).

  • desenfrenado

    Iniciar Planificación del Sprint :

    • desenfrenado

      Capacidad : Como equipo Scrum, determina la capacidad disponible del equipo: ¿Quién puede contribuir con trabajo durante el próximo Sprint?

  • desenfrenado

    Objetivo de Sprint (¿ Por qué es valioso este Sprint?) :

    • desenfrenado

      Pídale al PO que comparta el objetivo comercial que el próximo Sprint debe lograr.

    • desenfrenado

      Todo el Equipo colabora para definir un Objetivo del Sprint .

    • desenfrenado

      Adecuar la capacidad del equipo Scrum al objetivo de negocio del PO: ¿es realista?

    • desenfrenado

      Si el objetivo comercial y la capacidad del equipo no coinciden, reduzca el alcance del Sprint.

    • desenfrenado

      Si el equipo no puede cumplir con el objetivo comercial propuesto, pídale al PO que proponga una meta realista.

    • desenfrenado

      Crear un objetivo de sprint en colaboración.

  • desenfrenado

    Selección de elementos para el Objetivo (¿ Qué se puede hacer en este sprint?) :

    • desenfrenado

      Tras hablar con el PO, los Desarrolladores seleccionan elementos del Backlog del Producto para incluirlos en el Sprint actual.

    • desenfrenado

      Refinar: el equipo puede refinarlos durante este proceso, lo que aumenta la comprensión y la confianza.

    • desenfrenado

      Dimensionar: determinar cuánto se puede completar en un sprint puede ser un desafío. Aquí puede usar alguna técnica de puntuación relativa (planning poker e historia pivote son ejemplos a usar).

    • desenfrenado

      Pregúntele al equipo si el alcance del trabajo deja tiempo libre para abordar problemas inesperados.

    • desenfrenado

      Pregunte al equipo si el alcance del trabajo permite abordar la deuda técnica y los errores. (Evite la trampa de una utilización superior al 95 %. No se convertirá en una fábrica de funciones a expensas de la calidad de la pila tecnológica).

    • desenfrenado

      El equipo crea notas adhesivas para el tablero físico. (Asegúrese de seguir los códigos de color para los diferentes tipos de notas adhesivas o tipo de emisión; las historias de usuario, las tareas, y los errores tienen colores distintos o tipos distintos).

    • desenfrenado

      Acciones de Mejora Continua : Resumir los resultados de la Retrospectiva del Sprint anterior y actualizar el nuevo tablero del Sprint con las acciones a tomar. (El Equipo Scrum comunicó abiertamente los resultados de su Retrospectiva).

  • desenfrenado

    Plan del cómo (¿ Cómo se realizará el trabajo elegido?) : Para cada elemento seleccionado del Product Backlog, los Desarrolladores planifican el trabajo necesario.

    • desenfrenado

      Pida que se converse técnicamente qué hay que hacer para cumplir el DOD.

    • desenfrenado

      Pida descomponer los elementos en elementos de trabajo más pequeños.

  • desenfrenado

    Acuerdo final (¿Estamos todos de acuerdo?) :

    • desenfrenado

      El Objetivo del Sprint debe definirse antes de finalizar la Planificación.

    • desenfrenado

      Discutir las modificaciones necesarias con el PO.

    • desenfrenado

      Votación (Voto romano) de consenso: 

      • desenfrenado

        ¿Todos se sienten cómodos con el plan? | 

¿La carga de trabajo es acorde a nuestra capacidad? | 

¿Podemos comprometernos todos con el Objetivo del Sprint? | 

¿Todo el equipo cree que el plan es alcanzable y el PO está satisfecho con las prioridades?

  • desenfrenado

    Cierre:

Inicia el Sprint formalmente.



Después de la planificación del sprint:

  • desenfrenado

    El objetivo del Sprint, los elementos del Product Backlog seleccionados para el Sprint y el plan para entregarlos se denominan en conjunto Sprint Backlog.

  • desenfrenado

    Asegurar la corrección del tablero y sprint en curso. Sincronizar el tablero offline con el online.

  • desenfrenado

    Comience a recopilar datos para la próxima Retrospectiva del Sprint, por ejemplo, configurando un buzón de correo del Sprint.

  • desenfrenado

    Encuesta (Puede ser parte de la retrospectiva):

  • desenfrenado

    Realiza una encuesta anónima sobre el Sprint anterior. La encuesta incluyó cuatro preguntas: 1. ¿Ofrecemos valor a nuestros clientes durante el Sprint reciente? 2. ¿Ha cambiado el nivel de deuda técnica durante el último Sprint? 3. ¿Recomendarías una vacante en esta organización a un buen amigo con mentalidad ágil? 4. ¿Cómo te sientes personalmente con respecto a tu situación laboral?

  • desenfrenado

    Recuerde a los miembros del equipo que participan en la encuesta de Sprint Destacado. (El número mínimo de participantes fue de ocho desarrolladores, más dos analistas de negocio, el Dueño del Producto y el Scrum Master).

  • desenfrenado

    Publicar los resultados de la encuesta de Sprint del Sprint anterior.



Consejos para el facilitador:

  • desenfrenado

    Si no hay claridad del objetivo de Sprint realiza preguntas:

    • desenfrenado

      ¿Qué sería lo único que tendríamos que entregar o hacer para obtener algún valor?

    • desenfrenado

      ¿Qué desafío podríamos asumir para lograr completar en un sprint?

    • desenfrenado

      Si hay muchos objetivos: ¿Cómo afecta trabajar en varios productos u objetivos en un Sprint tu capacidad para concentrarte en entregar software funcional a las partes interesadas?

    • desenfrenado

      ¿Hay alguna conexión entre objetivos del sprint, los objetivos/visiones del producto y la visión más amplia de la organización?

  • desenfrenado

    Trabajan como compañeros de equipo al definir el objetivo del sprint. No es cierto que el Scrum Master solo actúe como facilitador. El Scrum Master forma parte del Equipo Scrum, y este define el Objetivo del Sprint.

  • desenfrenado

    Si es necesario, orientarlos durante la elaboración de pronósticos, planteándoles preguntas impactantes, como cómo se sentirán si no cumplen con los pronósticos, lo que les ayudará a obtener un incremento potencialmente liberable. ¿Cómo planean trabajar en equipo? 

  • desenfrenado

    Asegúrese de que el equipo haya comprendido qué inspeccionar y adaptar durante la planificación del sprint. ¿Está el equipo inspeccionando el último incremento, la definición de completado, los compromisos retrospectivos y las combinaciones de equipos, etc.? 

  • desenfrenado

    Habilite la transparencia al explicarles cómo un buen backlog de sprint puede ayudar a que se preocupen por los demás y actúen como un radiador de información. 

  • desenfrenado

    Asegura transparencia con visualización compartida : Asegúrate de que el trabajo que se está planificando pueda ser visualizado remotamente por todos los miembros del equipo. Quien esté escribiendo los objetivos de la iteración debe compartir su pantalla para que todos puedan ver los objetivos a medida que se desarrollan.

  • desenfrenado

    Votación de confianza : Encuentra una forma amigable con el trabajo remoto para realizar una votación de confianza del equipo y asegúrate de discutir con curiosidad y sin juicio cualquier voto extremo.

  • desenfrenado

    Haz participar a todos : En las reuniones remotas, es fácil que los compañeros más callados hablen menos, busca participación mediante preguntas. Asegúrate de preguntar la opinión de los miembros más callados.

  • desenfrenado

    Mantén un ambiente agradable : pon música suave y divertida mientras tu equipo cierra la iteración anterior o escribe historias.

  • desenfrenado

    Mantén la energía alta : Anima a los miembros del equipo a traer snacks oa tomar un descanso en equipo para levantarse, estirarse o hacer una "fiesta de baile de un minuto". Toma descansos regulares si es necesario.

  • desenfrenado

    Celebren como equipo : cuando planifiquen por debajo de la capacidad, dejando espacio para el trabajo no planificado. Pueden repartir stickers, tener un snack especial o actualizar una métrica del equipo como "X iteraciones desde que hemos estado por encima de la capacidad".

  • desenfrenado

    Asegura un equipo NO sobrecargado : Si el equipo completo está rutinariamente por encima de su capacidad, presenta datos (Velocity, Cumplimiento, etc.) al equipo que demuestren con qué frecuencia el equipo está planificando por encima de su capacidad, o el trabajo que no se completa o se arrastra (carry over) cuando el equipo está por encima de su capacidad. Como equipo, hagan una lluvia de ideas sobre cómo pueden abordar este problema juntos. Los individuos capturarán sus ideas y decidirán sobre los elementos de acción a llevar a la próxima planificación de iteración. Pídele al equipo que actúe como compañeros de responsabilidad mutua mientras planifican la próxima iteración utilizando esos elementos de acción.

  • desenfrenado

    Asegura persona NO sobrecargada : Si un Miembro del Equipo está rutinariamente por encima de su capacidad: Formas de Superarlo: Trabajen como equipo para identificar historias que puedan esperar, ser desglosadas o ser tomadas por otra persona, de modo que un solo miembro del equipo no esté sobrecargado o experimentando agotamiento (burnout). La programación en parejas (pairing) para aumentar las habilidades en forma de "T" (habilidades en forma de T) con otros miembros del equipo puede disminuir un cuello de botella de habilidades en un solo miembro del equipo con el tiempo.

  • desenfrenado

    Garantizar que todos respetan el límite de tiempo, elaboran un objetivo del sprint y planifican los primeros días si es necesario.

  • desenfrenadoIdentifique antipatrones que de no poder tratarlos inmediatamente podrá analizarlos y trabajarlos en el futuro
  • ( https://age-of-product.com/scrum-sprint-planning-anti-patterns/ ).


Referencias: