#RespuestasAgiles ¿Y qué pasó con la Definition of Ready y la Definition of Done? ¿Pasaron de Moda?

¿Y qué pasó con la Definition of Ready y la Definition of Done?¿Pasaron de moda?

 

Hola a todos,

Hace rato no escribía, lo cierto es que sigo avanzando en diferentes proyectos con mi gran amigo Lucho Salazar, pero si algunos me siguen asiduamente, saben que continúo compartiendo notas, podcast y videos; pues este aprender y compartir es en doble vía, y siento un deber trabajar con la comunidad ágil para crecer y progresar juntos.

Bueno, quiero compartirles una disfunción que he visto emerger en muchos equipos Scrum y organizaciones ágiles, que uno supondría que está mitigada, pues en ellas se insiste insistentemente en los entrenamientos de Scrum y en los diferentes marcos de escalamiento que lo usan (y que también existe en el mundo Kanban (1)), y que por lo que estoy observando esta siendo ignorada o minimizada su importancia por los Scrum Masters, Facilitadores, Agile Coaches; y como lo "spoilié" con el título del artículo es: el no cumplir con la Definition of Ready (DoR) y la Definition of Done (DoD).

Continuamente en diversos escenarios, Product Owners y gerentes de área se me quejan de que sus equipos scrum no están funcionando, y para entender el contexto hago unas preguntas de rigor, como las del litmus test de la agilidad, y adicional incluyo estas cinco (entre muchas otras según me va llevando la conversación):

1. ¿Tienen Definition of Ready?
2. ¿La están cumpliendo?
3. ¿Tienen Definition of Done?
4. ¿La están cumpliendo?
5. ¿Y cada cuánto actualizan la Definition of Done? 

Siendo estas últimas en las que estoy encontrando mayor reincidencia, y casi todas teniendo como causa raiz la presión del negocio por entregar a como de lugar. Como se pueden imaginar, en estos escenarios de falla y queja, si se incumple en cualquiera de las primeras cuatro preguntas se esta incurriendo en errores de calidad que terminan pagando el producto, el cliente, el equipo y toda la organización, generando retrasos y reprocesos e inconformidad en todos los involucrados en el proceso Scrum; y si se incurre en la última pregunta, se tiene un equipo que no mejora sus estándares con el tiempo y en consecuencia se está desactualizando.

 

A continuación, comparto un listado de consecuencias de fallar en estos cinco aspectos:

Consecuencias de no tener o no cumplir la Definition of Ready

En Scrum, "Definition of Ready" (Definición de Listo) (2) es un criterio utilizado para determinar si un elemento del Backlog del Producto está en un estado adecuado para ser planificado y abordado en una próxima iteración o Sprint. Aunque ni en tradicional, ni en cascada, ni en ágil, Scrum o Kanban, etc., se recomienda trabajar con requisitos inestables o no definidos, pues¡No tiene sentido! ¡Es desperdicio de comienzo a fin!, veamos algunas consecuencias de no contar ni cumplir con la DoR

"Caminar sobre el agua y desarrollar software basado en especificaciones es fácil si ambos están congelados" - Edward V. Berard

• Entregas inconsistentes: El equipo puede encontrarse trabajando en elementos que no están bien preparados, lo que lleva a resultados inconsistentes y posiblemente de baja calidad.
• Ambigüedad en las expectativas: Si los elementos del Backlog del Producto no están claramente definidos antes de comenzar el trabajo, puede haber confusión en cuanto a las expectativas y los criterios de finalización, lo que puede llevar a malentendidos y retrabajos.
• Mayor tiempo de Sprint Planning: La falta de definición puede conducir a discusiones prolongadas durante la planificación del Sprint, ya que el equipo debe aclarar los requisitos y detalles de cada elemento.
• Riesgo de incluir elementos poco relevantes: Si los elementos no están bien definidos, existe la posibilidad de que se planifiquen tareas que no aporten un valor significativo al producto final.
• Acumulación de elementos no terminados: Si el equipo acepta elementos no preparados en el Sprint, existe una mayor probabilidad de que no puedan completarlos dentro del marco de tiempo del Sprint, lo que resulta en elementos no terminados y afecta la capacidad de entrega. Es frecuente ver que el Product Owner resuelve las inconsistencias o dudas durante el sprint y el equipo al estimarlas o trabajar desbordan la capacidad del equipo impactando otros elementos del sprint backlog o incluso el objetivo del sprint..
• Desperdicio de tiempo y esfuerzo: Trabajar en elementos no preparados puede dar lugar a un desperdicio de tiempo y esfuerzo, ya que el equipo podría descubrir problemas o requisitos faltantes durante el Sprint.
• Falta de transparencia: Una Definition of Ready clara es esencial para mantener la transparencia en el proceso de desarrollo. Sin ella, puede ser difícil para las partes interesadas y el equipo comprender el progreso y el estado del proyecto.
• Frustración y desmotivación del equipo: Si el equipo se ve constantemente lidiando con elementos mal definidos, esto puede llevar a la frustración y la desmotivación, lo que afecta negativamente la moral y la productividad.
• Frustración de los interesados: Se genera un producto de baja calidad y no se tienen claras las reglas de interacción con el equipo, generando expectativas que no son cumplidas frecuentemente.

Para evitar estas consecuencias, se sugiere:

• que el equipo Scrum y los interesados trabajen juntos para establecer una Definition of Ready 
• cumplir estrictamente la DoR y actualizarla cuando se observe pertinente.
• que los próximos elementos candidatos a ser sumados al sprint backlog se encuentren correctamente refinados y definidos.
• se realicen sesiones de refinamiento previas a la sprint planning.
• las dependencias con otros componentes sean resueltas y construidas al menos con un sprint de antelación.
• se trabajen en ítems de backlog pequeños (historias de usuario), pues esto permite la fácil identificación de áreas, escenarios, o criterios de aceptación, evitando áreas grises o no resueltas en el sprint planning.
• no incluir historias por presión del negocio que no complan la DoR.

Consecuencias de no tener o no cumplir con la Definition of Done

 La "Definición de Terminado" (3)(4) es un conjunto de criterios acordados que establece cuándo un incremento del producto se considera terminado y listo para ser entregado. Algunas de las consecuencias de no tener o no cumplir con esta definición son las siguientes:

"Cuando algo esta DONE, no me tengo que volver a preocupar de ello" - Alan Cyment

• Entregas de baja calidad: Si el equipo no cumple con los criterios de la "Definición de Terminado", es probable que los incrementos entregados no cumplan con los estándares de calidad requeridos. Esto puede llevar a problemas de funcionamiento, errores y dificultades para el usuario final.
• Acumulación de deuda técnica (6): Si se permite que el equipo entregue incrementos que no están completamente terminados, es probable que se acumule deuda técnica. La deuda técnica representa trabajo adicional que se requerirá más adelante para resolver problemas y mejorar la calidad del producto.
• Retraso en la entrega: La falta de cumplimiento con la "Definición de Terminado" puede llevar a retrasos en la entrega de incrementos completos y funcionales. Esto puede afectar la confianza del cliente y la capacidad del equipo para cumplir con los plazos establecidos.
• Dificultades en la planificación: Si el equipo no puede estimar con precisión el tiempo necesario para completar los incrementos debido a la falta de una "Definición de Terminado" clara, la planificación de futuros Sprints puede volverse complicada y menos confiable.
• Dificultades en la revisión del Sprint: Durante la revisión del Sprint, los incrementos se evalúan para determinar si cumplen con los criterios de la "Definición de Terminado". Si no se cumple, se pueden generar discusiones y conflictos innecesarios entre los interesados.
• Falta de transparencia: Una "Definición de Terminado" clara es esencial para mantener la transparencia en el proceso de desarrollo. Sin ella, puede ser difícil para las partes interesadas y el equipo comprender el progreso y el estado real del producto.
• Desmotivación del equipo: Si el equipo se ve obligado a entregar incrementos que no cumplen con los estándares de calidad, es probable que se sientan desmotivados y frustrados por no poder ofrecer un trabajo de alto nivel.
• Problemas de integración: Incrementos que no cumplen con la "Definición de Terminado" pueden generar problemas de integración con otros componentes del sistema, lo que dificulta el progreso general del desarrollo.
• Desconfianza de los interesados en el equipo y en el proceso Scrum: Al observar que el equipo Scrum no cumple entregando con calidad, se pierde confianza en el equipo y el proceso Scrum.

Para evitar estas consecuencias, se sugiere:

• que el equipo Scrum adopte y cumpla la DoD de la organización.
• en su defecto, el equipo Scrum la defina y todos responsablemente la promuevan, comenzando por el Scrum Master como agente de cambio.
• no contar como Done, algo que no fue finalizado.
• usar la retrospectiva como fuente de indagación para comprender por qué no se cumplió la DoD.
• por presión de agenda o del negocio, evitar a toda costa declarar como DONE algo que no lo es. 

Consecuencias de no actualizar la Definition of Done

"Entre más maduro y DevOps sea un equipo, más robusta es su Definition of Done" - Jorge Abad

No revisar y mejorar con cierta frecuencia la "Definición de Terminado" como lo sugiere la guía de Scrum puede tener varias consecuencias negativas que afectan al equipo de desarrollo y al producto final a lo largo del tiempo. Aquí están algunas de las consecuencias de no realizar revisiones y mejoras periódicas:

• Estancamiento de la calidad: Si la DoD no se revisa y actualiza regularmente, es probable que la calidad del producto se estanque. Los criterios pueden volverse obsoletos o insuficientes para mantener el nivel de calidad deseado.
• Deuda técnica: La falta de revisión puede conducir a la acumulación gradual de deuda técnica. A medida que el producto se desarrolla sin mejoras en la DoD, es más probable que se tomen atajos y se sacrifique la calidad para cumplir con los plazos, lo que crea deuda técnica que debe abordarse más adelante.
• Mayor incidencia de errores: Si la DoD no se ajusta a las necesidades cambiantes del producto o del cliente, es más probable que se produzcan errores y problemas que afecten negativamente la experiencia del usuario.
• Dificultades en la entrega: Si la DoD no se actualiza para reflejar las nuevas expectativas o requisitos del cliente, el equipo puede tener dificultades para cumplir con las demandas cambiantes del mercado.
• Conflictos con los interesados: Si la DoD no se revisa en función del feedback de los interesados, puede haber conflictos y desacuerdos sobre el nivel de calidad aceptable para el producto.
• Pérdida de transparencia: Si la DoD no se revisa y comunica de manera efectiva, puede haber una falta de transparencia en el proceso de desarrollo, lo que dificulta que los interesados comprendan el estado real del producto.
• Desmotivación del equipo: La falta de revisión y mejora puede llevar a que el equipo se sienta frustrado y desmotivado, ya que pueden enfrentar problemas recurrentes y dificultades para cumplir con los objetivos de calidad.
• Estancamiento en la mejora continua: La revisión y mejora de la DoD son esenciales para la mejora continua del equipo. Sin esta práctica, el equipo puede dejar de buscar oportunidades para optimizar su proceso de desarrollo y entregar un producto de mayor calidad.
• Trabajar en un producto obsoleto: Sin el ejercicio de revisión frecuente de la DoD, se puede incurrir en trabajar en un producto que se va desactualizando y quedando obsoleto con el tiempo.

Para evitar estas consecuencias, se sugiere:

• que el equipo Scrum revise con cierta cadencia su DoD, al menos una vez cada trimestre en una retrospectiva.
• revisar el entorno del mercado (realizar vigilancia tecnológica) para identificar mejoras al producto, prácticas o proceso que deban ser incluidas en la DoD.
• identificar qué prácticas de calidad se encuentran al final del proceso de desarrollo (por ejemplo: prebas especializadas previos a la salida a producción) que puedan ser includias tempranamente (shift-left) para mejorar la velocidaddel equipo y del producto.

Cerrando

Scrum tiene dos puntos de control de calidad clave, que son: la entrada de lo que se quiere construir y la salida o increments; el compromiso del equipo Scrum en hacer cumplir la DoR y la DoD, garantizan la calidad del producto, menos errores, mayor velocidad, más transparencia, menos deuda técnica, mejor satisfacción de todos los involucrados, planeaciones y ejecuciones más efectivas, en consecuencia un mejor Scrum y una entrega de calidad de impacta positivamente la generación de valor.

Deteriorar el cumplimiento de la DoR y la DoD generará, como lo vimos, desconfianza en el producto, el equipo y el proceso; consecuentemente deteriora el entorno de agilidad que se quiere construir.

"Agilidad sin calidad, son incrementos de desperdicio entregados en ciclos cortos" - Jorge Abad

Volver a lo básico e insitir sobre lo esencial, garantizará una mejor agilidad y desempeño de los equipos construyendo productos exitosos.

Saludos ágiles.

Jorge Abad.

Referencias, notas, aclaraciones y comentarios

1. En el mundo Kanban, la Definition of Ready y la Definition of Done conocen como Politicas y consiste en que una tarjeta no mueve hacia la derecha (o en la dirección del flujo) si las políticas no se cumplen.
2. Definition of ready (scrumbook) - https://scrumbook.org/value-stream/product-backlog/definition-of-ready.html
3. Definition of done (scrumbook) - https://scrumbook.org/value-stream/definition-of-done.html
4. Definition of done (Scrum guide)- https://scrumguides.org/scrum-guide.html.
5. Deuda Técnica - http://www.lecciones-aprendidas.info/search/label/deuda%20t%C3%A9cnica
6. Algunos textos acá presentados fueron curados utilizando IA.

¿Cuándo podríamos estimar una historia de usuario con mejor certeza? La matriz de Stacey, una técnica a usar en el Refinamiento

Hola a todos

La matriz desarrollada por Ralph Stacey, conocida como la Matriz de Stacey, permite entender cuando de acuerdo con los ejes de Requerimientos y Tecnología, podemos tener una aproximación de gestión simple, complicada, compleja;

Matriz de Stacey. Tomado de (1)

 

y dados estos escenarios, se ha usado en los últimos años, para justificar en que escenarios trabajar con métodos tradicionales y cuando con enfoques ágiles (existen cientos de artículos al respecto).

Matriz de Stacey. Tomado de (2)

Usando este mismo enfoque, podríamos identificar en un taller de Inception o de Refinamiento, cuando una historia de usuario o una épica incluye mucha o poca incertidumbre para ser estimada y, por ende, desarrollada, tanto desde el punto de vista de requerimientos, como de tecnología, proporcionándonos estimaciones indirectas sobre tiempos y esfuerzos requeridos (toda estimación incluye una probabilidad y una incertidumbre asociada).

La zona donde cualquier equipo de desarrollo, ágil o no, estima con confianza, es aquella donde hay alta certeza en los requerimientos y alto certeza en la tecnología y forma de construirlo. Los Product Owners deben procurar que la mayoría de las historias de usuario y épicas que llevan a un equipo se encuentran en esta zona. Ahora, si existe incertidumbre, podríamos hacer uso de técnicas de partición de historias de usuario (3) o de spikes para realizar investigaciones de aquellos elementos que no se encuentran claros al momento de desarrollar.

Los equipos ágiles deben preferir historias en esta zona de confianza, y estos elementos podría hacer parte de una Definición de Ready o Preparado adecuada, para que las historias puedan ser incluidas en el planning. Los siguientes criterios que garantizan esta zona de estimación con certeza: 

• Las historias cumplen cumplen INVEST y las 3C
• Existe un entendimiento consistente de parte del product owner y del equipo acerca de la historia de usuario.
• Las historias cuentan con claros criterios de aceptación 
• Se han resuelto las dependencias técnicas y funcionales
• Las ambigüedades se han resuelto
• El tiempo para construir-probar-desplegar la historia de usuario se encuentra en horizontes de tiempo menor o igual a 4 días-persona (esto es una heurística que he observado en los equipos ágiles, en este número de dias las estimaciones son más certeras y confiables. Habrá que hacer un estudio riguroso para confirmar mi experiencia e hipótesis).

Para cerrar, los invito a que usen esta matriz para realizar refinamiento de historias de usuario con sus equipos, asegúrense que existe certidumbre en la tecnologia y acuerdo en los requerimientos, de esta forma fluirán mejor sus sesiones de planning y no se enfrascarán en discusiones innecesarias.

Saludos ágiles,

Jorge Abad

Referencias

1. Entendiendo la complejidad: La matriz de Stacey - https://academy.jeronimopalacios.com/courses/145560/lectures/5315213
2. https://www.researchgate.net/figure/Stacey-Matrix-Stacey-1996-adapted-to-software-development_fig3_336899045
3. Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario

Respuestas Ágiles: vengo fallando los últimos 4 sprints ¿Qué hago?

Acomodando o Forzando Scrum para Equipos de Testing

Hola a todos (hace tiempo no escribía, discúlpen lo perdido que he estado)

Hoy hablare un poco de como he visto que se hacen proyectos de testing bajo el marco de Scrum o al menos ser ayudados por el marco. Comencemos.

------

PROLOGO

La tradicional forma de ver el software en cascada entre empresas,  en donde:

La empresa “X” construye el software (entregándolo probado),

y la empresa “Y” lo prueba y certifica

Va seguir viva en nuestro entorno por un tiempo más y la causa raíz de esto es sin duda la desconfianza, pues ya sea por procedimiento, requerimientos corporativos de seguridad ponemos a un tercero a que pruebe, generando la calidad de la calidad.*

NUDO

Recordemos, “en Ágil la idea es hacer la menor cantidad de software con calidad que genere el mayor valor de negocio**”, pero muchas veces, debido a estos  esquemas de desconfianza “CASCADIZAMOS ÁGIL” y se cae en que:

• un equipo hace desarrollo ágil cumpliendo su DEFINITION OF DONE
•  y otro prueba el DONE del anterior, cayendo en la calidad de la calidad, el proceso y reproceso, y por ende el desperdicio

Bajo esta premisa el equipo adicional de testing – de la empresa “Y” –

dice: “yo voy a probar usando Scrum”

¡ ¡ ¡OMG!!!

Seamos claros, ese equipo usará del framework de Scrum para realizar la gestión del proyecto realizando:

• Planeación
• Ejecución
• Revisión
• y Retrospectiva

Pero bajo este esquema “LOS EQUIPOS DE TESTING QUE EMPLEAN EL PROCESO DE SCRUM PARA PROBAR, REALMENTE NO HACEN SCRUM” pues Scrum sirve para construir productos, y bajo este esquema solo lo estamos probando.

Pero a pesar de lo anterior, procedamos a homologar lenguaje que equivaldría en este esquema:

• El Product Backlog es todo lo que hay que probar
• Casos de uso
• Historias de usuario
• Requisitos no funcionales
• El sprint backlog
• Es lo que se selecciona a probar durante el ciclo
• El team es un equipo de testing
•  Product Owner y Scrum Master conservan sus definiciones.

Entonces cual es la DEFINITION OF DONE de un equipo de testing bajo estas características

• Todos los casos de prueba de la HU o del CU diseñados
• Las evidencias asociadas a casos fallidos o exitosos registradas en el repositorio
• Reporte de incidencias encontradas actualizado.

Y la DEFINITION OF READY:

• Casos de uso o historias de usuario desarrollados y congelados en un ambiente para testing
• Documentación asociada congelada.

No dudo que este esquema sea efectivo, lo he visto:

• Potencializa más el trabajo en equipo, pero no se nota la fortaleza e interacción de un equipo multidisciplinario que construye software.
• Se mejora la predictibilidad de diseño y ejecución de casos de pruebas

Conclusión

En la medida que hagamos mejor ágil, un mejor DONE (procesos y practicas técnicas que aseguren los productos) estos esquemas comenzarán a desaparecer, al igual que los testers evolucionarán a testers que no solo hacen pruebas funcionales, sino que automatizan, realizan pruebas no funcionales y hacen parte crucial del equipo de desarrollo.

Notas

*si vamos a ser sensatos esto tiene todo el sentido en proyectos donde a la empresa “X” construía el software haciendo cascada, generando grandes cantidades de software, que  talvez entregado a la fuerza y en consecuencia, obligando al cliente a contratar a un tercero que le certifique que lo que le entregaron muchos meses después si sirve.

**y saliendo a producción lo antes posible, para generar el mayor RETORNO DE INVERSION (ROI)

Leído y Recomendado: La Definición de “Ready” es tan importante como la Definición de “Done”

Excelente artículo de Johnny Ordoñez

https://johnnyordonez.wordpress.com/2014/12/12/la-definicion-de-ready/

De colección, super-recomendado

Lo copio para tener registro...

_____

La Definición de “Ready” es tan importante como la Definición de “Done”

DECEMBER 12, 2014 / JOHNNY ORDÓÑEZ

Usted no puede empujar a nadie a subir la escalera a menos que esté listo para subir por él mismo. – Andrew Carnegie

Uno de los conceptos más importantes y conocidos en el desarrollo de software ágil -utilizando varios sabores como Scrum y Kanban- es la Definición de “Hecho” (o Definition of Done, o DoD). La definición de Done es un acuerdo del equipo, y en muchas ocasiones de la organización. Mediante el criterio de Done se puede conocer cuando una Historia de Usuario se encuentra “Hecha” para ser presentada al Producto Owner o Stakeholders. Brinda una guía al equipo sobre las condiciones necesarias que debe cumplir una historia para ser decentemente terminada presentada durante o al final de la iteración. Es una herramienta que brinda transparencia y permite un entendimiento común de lo que significa “Hecho”.

Ya en la práctica, consiste en una especie de checklist que reúne los criterios acordados por el equipo al que se somete cada historia antes de ser colocada en la preciada columna de Done en el Taskboard. En muchos tableros he visto también la columna “Done Done!” o “Accepted” dando así dos niveles de aprobación de la historia de usuario, Done significa que cumple todos los criterios establecidos por el equipo que normalmente incluyen: el código en el repositorio, todas pruebas unitarias y de aceptación en verde, documentación si fuera necesario, integración en el ambiente de pruebas, revisión por el tester en el ambiente de pruebas, etc.; y “Done Done” o “Accepted” cuando ha sido revisada y “firmada” por el Product Owner.

Varios agilistas sugieren  lo mínimo que debe contener la definición de Done, y les dejo algunos artículos para su revisión un poco más abajo; sin embargo, quiero con este post hablar de otra definición quizás no tan conocida pero desde mi punto de vista bastante útil; la “Definición de Listo”.

La Definición de “Ready” o DoR

Análoga a la Definición de “Hecho”, la definición de “Listo” es un acuerdo entre del equipo, especialmente entre el Product Owner y el equipo de Desarrollo donde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un sprint. Básicamente, es un conjunto de condiciones -y un checklist también- a la cual se somete una historia para ser tomada en un Sprint Planning.

¿Por qué es importante?

Varias razones. Desde la práctica, una historia de usuario no está lista a la primera. El product Backlog es orgánico y necesita un tiempo de maduración. Significa que mientras el equipo de desarrollo está trabajando en las historias comprometidas en el Sprint Planning anterior,  el Product Owner está trabajando en refinar su backlog y poner a punto las historias para la siguiente y subsiguiente iteración (pienso que un buen PO prepara historias para un par de sprints adelante). Esto es, comprender el objetivo y el alcance funcional con los usuarios, expertos del dominio, UX designers, Product Managers; priorizar la historias usando técnicas apropiadas, descomponiendo historias en un tamaño apropiado para el equipo, estableciendo criterios de aceptación, identificando dependencias entre los items de su backlog y otros backlogs, colaborando con otros POs, entendiendo y revisando desafíos de arquitectura o técnicos con el arquitecto o Líder Técnico y trabajando junto con el equipo en el grooming del backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.

Bob Galen habla mucho del “Readiness Criteria” en varios artículos y en su libro Agile Reflections y sugiere una lista de Ready como la siguiente (a estos puntos les daré mi modificación desde mi criterio en paréntesis, pero la lista original la colocaré en las referencias):

• Historias bien definidas y con al menos 5 criterios de aceptación (este valor es heurístico, igual se puede establecer un número máximo de criterios de aceptación);
• Historias de un Tamaño apropiado, que entre dentro de un sprint (un tamaño adecuado con que el equipo se sienta cómodo y mejore su throughput, un buen tamaño que permita un mejor entendimiento, mejores criterios de aceptación, más fácil de probar, más fácil revisar, mejora la moral del equipo);
• Que el equipo haya revisado las historias en una sesión de Grooming, donde se haya comprendido la naturaleza, el valor y desafíos técnicos;
• De ser necesario, que la historia haya tenido un spike para explorar las implicaciones de diseño, arquitectónicas o tecnológicas (cuando el equipo no tiene mucha incertidumbre sobre lo que implica técnicamente la historia, es apropiado un spike; luego de eso la historia se puede revisar nuevamente, estimar y pasar a la columna de Ready);
• Que la historia sea transversal, es decir que describa un comportamiento end-to-end (que sea “visible” para le negocio);
• Que el equipo comprenda el enfoque para las pruebas tomando en cuenta aspectos funcionales y no funcionales;
• Que se haya identificado dependencias con otras historias dentro del mismo backlog u otros backlogs a los que una historia pueda estar conectada;
• Que la historia se alinee (y esté “enganchada”) a un objetivo u objetivos del sprint, que sean claramente visibles y demostrables.

Esta definición es bastante útil cuando tenemos a un PO que está desarrollando sus skills y su “olfato” para gestionar el trabajo para un equipo ágil. Ahora estoy trabajando con unos 29 equipos y un equipo de 14 POs; y acabamos de introducir esta práctica para lograr que las historias lleguen lo mejor trabajadas a los equipos; y estoy viendo varios beneficios de su aplicación (que espero que se sigan expandiendo):

• Sprint plannings más rápidos;
• Involucramiento y conocimiento temprano del equipo sobre los desafíos del siguiente;
• Gestión colaborativa del backlog;
• Feedback temprano;
• Levantamiento temprano de riesgos y necesidades (si se necesita del apoyo de un arquitecto, el SM ya lo puede buscar y planificar para el siguiente sprint);
• Mayor conciencia del equipo sobre los objetivos de negocio y el alcance;
• Ayuda al PO a comprender la visión sobre aspectos técnicos que le indica el equipo, y a sensar con qué tamaño de historias se sienten cómodos;
• Historias mejor trabajadas en las cuales el equipo se siente parte y por ende mejora el compromiso.

Pensamientos finales

Pienso que el uso definiciones DoD y DoR claras y difundidas son herramientas muy útiles para la colaboración , claridad y “fluidez” de los equipos. Haga que el mismo equipo sea quienes revisen y definan estas definiciones, pero si están trabajando con varios equipos colaborando para construir juntos un “big working software” estas definiciones deben ser coherentes a través de todos lo grupos. Se puede crear comités y reuniones de trabajo para afinarlas. Igualmente, están sujetas a revisión y modificación tras cada iteración.

Coloque una columna “In Analysis” o “En Revisión” (o cualquier nombre, sea creativo) donde colocará aquellas historias sobre las que debe trabajar y refinar. Cuando estén listas y se cumpla con la DoR, agréguelas a la columna “Ready” o “Backlog” que son aquellas que se explicarán en el siguiente sprint planning.

Trabajar bajo estas definiciones brindará claridad y fluidez al trabajo de los equipos y aportarán a su crecimiento y madurez. Una vez lo que hagan, por favor compártanme sus experiencias.

Gracias, y que la agilidad esté con Ustedes.

Johnny