De Colección: Una buena definición de Historia de Usuario - continuación

Esta es la explicación del post: De Colección: Una buena definición de Historia de Usuario

Hola a todos

Uno de los retos más comunes en agilidad es definir claramente qué es una historia de usuario y, sobre todo, cuál es su tamaño adecuado. He encontrado útil compartir esta definición:

"Una Historia de usuario es una pequeña porción de valor cuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue, puede estar entre unas cuantas horas hasta máximo 36 aproximadamente."

Otra versión que enfatiza el impacto en el negocio es:

"Una Historia de usuario es una pequeña porción funcional de valor cuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue; puede estar entre unas cuantas horas hasta máximo 36 aproximadamente, que le permite al equipo de desarrollo de forma tangible y rápida mostrar progreso al negocio"

Justificación de esta definición

El propósito de estas definiciones es alinear expectativas sobre el tamaño y alcance de una historia de usuario. En la práctica, es común encontrar historias que son demasiado grandes o demasiado pequeñas, lo que afecta el flujo de trabajo y la entrega de valor real.

¿Qué significa una "pequeña porción de valor"?

Para que una historia de usuario tenga el tamaño adecuado, debe cumplir dos principios clave:

1. Ser lo suficientemente pequeña para completarse en poco tiempo (idealmente en menos de dos días de trabajo acumulado). Esto permite que el equipo entregue de forma frecuente y fluida.
2. Ser lo suficientemente grande para aportar valor tangible al usuario o negocio. Esto significa que debe entregar una funcionalidad completa y usable, no solo una parte técnica aislada.

Una historia demasiado pequeña puede caer en fragmentación innecesaria, por ejemplo:

• "Agregar un nuevo campo en un formulario" (sin que esto implique una funcionalidad completa para el usuario).
• "Implementar solo la lógica de frontend" sin que el usuario pueda interactuar con el sistema de manera funcional.

Por otro lado, una historia demasiado grande se convierte en un problema porque:

• No se logra entregar dentro del sprint, afectando la previsibilidad del equipo.
• Genera un esfuerzo desproporcionado que impide recibir retroalimentación temprana.
• Puede requerir múltiples iteraciones para completarse, lo que dificulta la entrega continua de valor.

¿Por qué definir un límite de hasta 36 horas?

Anteriormente, usaba la referencia en días, pero esto generaba confusión. Algunas personas asumían que se trataba del esfuerzo acumulado de varias personas en paralelo, cuando en realidad el enfoque está en el tiempo total requerido.

Este límite de tiempo permite que las historias de usuario sean manejables y estén listas para ser desplegadas dentro del sprint sin convertirse en un obstáculo para el equipo. Además, facilita:

• Un flujo de entrega continuo, evitando acumulaciones y bloqueos.
• Un progreso visible para el negocio, al recibir incrementos de valor en ciclos cortos.
• La detección temprana de problemas, reduciendo el riesgo de retrabajo.

¿Cómo lograr historias de usuario con el tamaño adecuado?

1. Asegurar que cada historia entregue valor real. Si un usuario no puede interactuar con la funcionalidad o si no se resuelve un problema concreto, entonces la historia está mal definida.
2. Evitar fragmentación innecesaria. Dividir en tareas técnicas (backend por un lado, frontend por otro) no es lo ideal, ni lo correcto. En su lugar, cada historia debe representar un incremento funcional, usable y comprobable del usuario.
3. Reducir la complejidad sin perder el impacto. Si una historia es demasiado grande, dividirla de manera que cada parte siga teniendo sentido de negocio y sea usable por el usuario.

Definir historias de usuario en estos términos ayuda a los equipos a mejorar su agilidad y a entregar valor de forma consistente.

¿Tu equipo tiene una definición clara de historia de usuario? ¿Cómo manejan su tamaño? Comparte tu experiencia en los comentarios.

No es solo renovar la tecnología, es necesario un cambio de mentalidad

Frase: Business Agility - Visión Sistémica

 

“La Business Agility es un resultado sistémico, es la suma de las interacciones de los equipos y áreas de la organización, en su misión de generar valor.” – Jorge Abad

_

De Colección: Una buena definición de Historia de Usuario

 Una buena definición de historia de usuario que me ha sido útil compartir es:

"Una Historia de usuario es una pequeña porción de valor cuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue, puede estar entre unas cuantas horas hasta máximo 36 aproximadamente."*

Otra definición que también puede funcionar es:

"Una Historia de usuario es una pequeña porción funcional de valor cuyo tiempo de análisis, desarrollo, pruebas, corrección y despliegue; puede estar entre unas cuantas horas hasta máximo 36 aproximadamente, que le permite al equipo de desarrollo de forma tangible y rápida mostrar progreso al negocio"

*Nota: antes usaba la expresión de días pero generaba confusión, y se terminaba creyendo que eran muchas personas trabando durante esos días, por eso preferí poner el tiempo total requerido.

La explicación de esta definición la encuentran en: De Colección: Una buena definición de Historia de Usuario - continuación

Frases sobre las métricas

 Hola a todos, les comparto algunas ideas sobre las métricas:

“Las métricas moldean la organización”.  

 - Jorge Abad 

__

“Las métricas moldean la organización y en consecuencia la cultura”.  

 - Jorge Abad 

__

“Las métricas reflejan la organización”.  

 - Jorge Abad 

__

 

“Las métricas reflejan al líder”.  

 - Jorge Abad 

__

“Las métricas reflejan lo que inquieta a los líderes”.  

 - Jorge Abad 

__

“Como me midas me comporto”.  

 - Jorge Abad 

__

Conclusión sobre el liderazgo

 

 

“Considerando el entorno cambiante en que vivimos, la nueva responsabilidad del liderazgo es potenciar y mostrar a la organización como surfear el cambio constante, sin perder de vista la generación de valor y el cuidado del talento”. -Jorge Abad

Frase sobre priorización

----

"Construir algo que no fue correctamente priorizado es destruir valor para la organización" 

- Jorge Abad

----

"Building something that was not correctly prioritized is destroying value for the organization" 

- Jorge Abad

---

Cita: Siempre que haya miedo, obtendrás los números equivocados - Deming

"Siempre que haya miedo, obtendrás los números equivocados" Deming

 

--

 cita de "Accelerate" 

"As Deming said, ’whenever there is fear, you get the wrong numbers’ "http://a.co/g8vh4FE

-----

De lo que también se puede inferir

"Donde hay miedo, no habrá transparencia"

----

Para la Reflexión 

• ¿Te temen?
• ¿Tu liderazgo es desde el temor?
• ¿Qué tipo de liderazgo ejercen las personas que te reportan y tienen equipos a cargo?
• ¿Tu jefe te produce temor? 
• ¿En el área u organización en la que te encuentras, las relaciones son relaciones basadas en el temor?

Saludos ágiles

Jorge Abad

En Qué Radica el Éxito de la Transformación Ágil: Un Pensamiento Sobre la Batalla de los Frameworks de Escalado de Ágil

Te recomiendo visitar la versión mejorada de este artículo: http://www.lecciones-aprendidas.info/2020/06/en-que-radica-el-exito-de-la-transformacion-agil.html

Tomado de (1)

Hola a todos

Con varios amigos del mundo ágil con cierta frecuencia caemos en el lugar común de la batalla de los frameworks ágiles y en especial los de escalado, algunos temas recurrentes son:

• organizaciones pagan millones de dolares a las consultoras top para que al final de tres meses que les digan que adopten el modelo Spotify (que en últimas no es un modelo) (2)
• discutimos sobre cuáles son los beneficios y falencias de cada uno, cuál es más prescriptivo y cuál es más adaptativo
• comparamos sus estrategias de gestión del cambio
• confrontamos cual framework es más exitoso, o que autor prominente lo creo, promulga o defiende, 

Pero luego de desgastarnos un rato en discusiones bizantinas, pues todos los frameworks de escalar ágil cuentan en sus haberes con casos de éxito que publican orgullosos en sus páginas, pero que luego "despublican" cuando se vuelven fracasos, concluimos que son muchos los factores que compiten o colaboran entre sí, para lograr el éxito o el fracaso.

Factor	Hacia el éxito	Hacia el fracaso
Compromiso del Top-Management	·       alto compromiso e involucramento	·         Delegación completa y desentendimiento
Gestion el cambio organizacional	·       Adaptativa, basada en comunicación de éxitos y ganar adeptos.	·       Fija y predictiva
procesos y contratos	·       Modificados y en continua mejora hacia la agilidad	·       Sin modificar y orientados a la culpa en vez de la colaboración
Respecto a los líderes y al mindset	·        Capacitados y empoderados para compartir el mindset	·        La difusión del mindset es de lagada en los consultores y algunos roles
Tolerancia al fracaso	·       Alta	·        Baja
Comunicación	·       Fuerte y constante comunicación de la estrategia de cambio ·        Comunicación de la estrategia de cambio	·        Poca o nula comunicación
Espacios de trabajo y herramientas de colaboración	·        Acondicionados para la colaboración (los espacios moldean el comportamiento)	·        Limitados y restringidos
Silos organizacionales	·         Colaborando en torno al valor	·        Enfocados en optimizar la agilidad en su área
Métricas de gestión	·       Modificadas a promover la agilidad de personas, equipos, y la organización (recuerda, "como me midas me comporto")(4)	·        No sufren cambios
Agilidad Técnica	·       Adoptada como una estrategia organizacional buscando DevOps, Excelencia Técnica.	·        Adoptada como la compra de herramientas
Cultura	·        incentivar los nuevos comportamientos. ·        Desincentivar estilos de gestión y comportamientos que degraden las personas y la cultura de la organización	·        No intervenidos
Respecto a los frameworks ágiles	·         Adoptados con acompañamiento y los lineamientos planteados por sus creadores	·        Adoptados con demasiadas adaptaciones, falencias y personalizaciones que terminan desfigurando y replicando el statu quo actual.
Mindset	·        Constante difusión y adopción del mindset lean - agile (5)	·        No intervenido
Respecto a los consultores (3)	·        Acompañamiento de consultores con experiencia que cultiven el proceso y transfieran el conocimiento	·        Consultores que comparten la estrategia y no hacen parte del proceso de cambio
Entre otros

Yo me quedo con mi conclusión

"Hay organizaciones que sin importar el framework ágil logran ser ágiles y otras que sin importar el framework nunca llegan a serlo"

Por lo tanto, el problema al parecer no radica tanto en los frameworks, el problema radica en las personas y su disposición a adoptar este cambio, que dada vez es menos opcional.

Saludos Ágiles

Jorge Abad.

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Photo credit: Fotodilletant on Visualhunt / CC BY-SA
2. Yo también puedo hacerlo por la mitad del precio y mejor resultado
3. Sugerencias de mi amigo Lucho Salazar
4. Como me midas me comporto - http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
5. http://www.lecciones-aprendidas.info/2020/05/mindset-lean-agile.html

Un mal líder puede estropear la cultura y el sistema

Quisiera aprovechar el blog para compartir algo que he visto y que todos sabemos

"Un mal líder puede estropear la cultura y el sistema"

Me explico, en este trasegar acompañando organizaciones en su transformación hacia la agilidad he visto de todo, tal como:

• organizaciones llenas de procesos con equipos muy dinámicos dando excelentes resultados
• organizaciones sin procesos detallados con resultados lentos
• organizaciones con procesos de adorno
• organizaciones con líderes inspiradores y líderes desmotivadores
• y toda clase de combinación pervesa, positiva y mediocre de las anteriores

Llevándonos a decir con Deming

Y en esa misma dirección recordé ésto que publiqué hace un tiempo en linkedin.

Cosa cierta, pero cada vez creo que esto de culpar al sistema, la cultura, los incentivos, los procesos, las métricas, los kpi, etc. es una excusa frecuente, cuando muchas veces una de las causas raíces a muchos problemas sistémicos son:

• el liderazgo
• y la forma como interactuamos

Es por tanto clave intervenir tanto el liderazgo como la forma como interactuamos, pero primeramente el liderazgo, sino será muy poco lo que podamos mejorar en el sistema y la cultura.

Hasta acá este compartir

Saludos ágiles

Jorge Abad

Una idea sobre cultura, propósito, principios, valores y procesos

Una conclusión a partir de tantas lecturas y observaciones:

"Los procesos no alcanzan a legislar sobre todo lo que ocurre en una organización y en ausencia de procesos: los valores, principios y cultura de la organización guiarán a lo colaboradores ante cualquier situación, incluso sobre cualquier proceso definido previamente.

Una buena cultura, principios y valores te guiarán al éxito, similar en caso contrario."

Una versión de Casca-Agile(TM) o Casca-Scrum: tener "Sprint de desarrollo y luego Sprint de pruebas"

Hola a todos

Hace unos años en Ciudad de México dictando un entrenamiento de Scrum y Principios Ágiles, en el momento de hablar de malas prácticas, uno de los asistentes (y amigo mío Ulises Soriano), bautizaba como:

Casca-Agile (TM)

cuando se tomaban cosas del mundo ágil y del de cascada, pero con el pésimo resultado de que no se obtenía ni la "predictibilidad" añorada de cascada, ni la adaptabilidad de Scrum.

Esté termino lo he seguido usando desde ese entonces, y luego de tener la oportunidad de compartir con tantas organizaciones a nivel Latinoamérica he observado que hay una versión de Casca-Agile común a muchas empresas que no quieren adoptar la agilidad por completo: y es que contratan a un proveedor para que haga Scrum en el desarrollo del software y otro proveedor para que haga Scrum en las pruebas, olvidando lo que tanto se enuncia el marco Scrum en dos apartes:

"El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de entregar un Incremento de producto “Terminado” que potencialmente se pueda poner en producción al final de cada Sprint. Un Incremento “Terminado” es obligatorio en la Revisión del Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento."(1)

"Los Equipos de Desarrollo son multifuncionales, esto es, como equipo cuentan con todas las habilidades necesarias para crear un Incremento de producto;"(1)

Esa versión de Casca-Agile o Casca-Scrum, termina viéndose así:

Añadiendo al menos 3 sprints (pueden ser más) entre el desarrollo de la historia de usuario y el lograr la "certificación"por parte de pruebas

Las desventajas que esto genera

• Largos tiempo de entrega del incremento (al menos tres sprints más)
• La imposibilidad de revisar el incremento completo cuando se termina cada sprint de desarrollo por parte del PO.
• Bajo involucramiento del PO
• La Definición de Terminado o "Definition of Done" toma mucho tiempo para que sea completamente alcanzada por ambos equipos
• la responsabilidad sobre el producto construido no existe.
• Gestion de ANS (acuerdos de niveles de servicio) que no agregan valor y desfiguran el marco de Scrum.
• El equipo de testing no esta sintiendo la construcción incremental del producto y por lo tanto no se sienten responsables del la buena construcción del mismo
• Esto no es Scrum y se aleja de la agilidad pues no cumple ni con la definción de Scrum, ni con los valores y principios del manifiesto ágil (2)
• A esto muchos se atreven a llamarlo Scrum, sabiendo que no lo es, o lo llaman "Scrum pero" (o ScrumBut (3)), y si no les funciona le echan la culpa a Scrum.

Las ventajas

• Le pienso y le pienso y no lo encuentro, puede que saboreen un poco las mieles del desarrollo iterativo e incremental, pero deja mucho que desear.

Solución a este antipatrón

La "falsa sensación de seguridad" de tener dos contratos, uno para el proveedor de desarrollo y otro para el proveedor de pruebas, se resuelve sentándolos juntos en una sola mesa y siendo ambos responsables de la calidad del producto entregado, cada sprint.

Cerrando

Bien parafrasean muchos a Jeff Sutherland,

"el peor enemigo de Scrum, es un mal Scrum" 

o mejor como él lo dice:

Referemcia(4)

Hasta acá este compartir, bienvenidos los comentarios y experiencias.

Saludos ágiles
Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. La Guía Oficial de Scrum - https://scrumguides.org/
2. Manifiesto por el Desarrollo Ágil de Software -https://agilemanifesto.org/iso/es/manifesto.html
3. Una excelente definición de ScrumBut - https://www.scrum.org/resources/what-scrumbut
4. https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/
5. Si deseas ver más disfunciones de Scrum y de Ágil, haz clic aquí. http://www.lecciones-aprendidas.info/2019/04/malos-olores-en-transformaciones-agiles.html

Tweet: Agile no gestionar por alcance sino por valor

Entre los grandes cambios que introduce #Agile en una organización es pasar de

La Gestión del Alcance a la Gestión del Valor

Este "simple" cambio de enfoque:
-reorganiza equipos
-cambia métricas
-elimina desperdicios
-conecta más a las personas
-aumenta la felicidad

— Jorge Hernán Abad L. (@jorge_abad) April 17, 2018

Una conclusión de muchas...

Les comparto algo que concluí


La clave es ser fiel a sí mismos. El problema es que nos demoramos mucho reconociendo que nos somos infieles.

--
Saludos ágiles y reflexivos

Jorge Abad