¿Se pueden usar historias de usuario para describir elementos de calidad para el producto?

Historia de usuario de búsqueda de libros

Recientemente tuvimos un interesantísimo debate sobre una pretendida historia de usuario, sobre si lo es o si no lo es:

Como lector de libros

Quiero que la búsqueda libros sea más rápida

Para poder evitar tener que esperar tanto

A priori tiene toda la pinta de una historia de usuario, ¿verdad? La primera pregunta que nos debemos de hacer es si esta historia es algo que realmente quiera un lector.

¿Un lector de verdad quiere que mejoremos los tiempos de respuesta de nuestra tienda on-line? o, ¿más bien quiere encontrar el libro que busca y poder comprarlo? No me imagino un lector pidiendo a Amazon que acelere su proceso de búsqueda. Si encuentra el libro en nuestra tienda on-line, aunque excesivamente lenta, pensará que somos unos chapuzas, pero como ha logrado el libro que quería volverá en el futuro... eso si mientras tanto no ha encontrado una tienda on-linea más rápida que tenga los libros de su interés. Si no ha encontrado el libro probablemente no vuelva a nuestra tienda on-linea nunca más.

Si consideramos la historia incial del post como una historia de usuario, lo que estamos haciendo es trasladar nuestra falta de calidad al lector... y eso desde luego no nos va a hacer competitivos ni a crear buenas experiencias de usuario.

Por tanto podemos concluir que nuestro ejemplo no es una historia de usuario. Si puede ser una historia técnica, algo que hemos de hacer para mejorar la experiencia del usuario. Somos nosotros, no los lectores, quienes debemos de descubrir nuestras debilidades. Podemos detectar el problema en tiempos de respuesta a través pruebas de rendimiento en entornos de test o de staging, lo importante es que sea antes de liberar la funcionalidad de búsqueda a producción.

Si la problemática ya está en producción podemos analizar el comportamiento del software y la experiencia del usuario mediante herramientas como google analytics; rendimiento del segmento de usuarios, grabar sesiones y monitorizar contenidos visitados. Podemos detectarlo también en una encuesta a final de cada compra; si me imagino a un lector dando feedback de un tiempo de espera excesivo en la encuesta post-compra que hace Amazon.

Lo que ha de quedar claro es que los que tenemos interés en tener un tiempo de respuesta adecuado somos nosotros, no el lector. Por tanto si hemos detectado esa carencia podemos corregirla mediante una historia técnica que luego se convierta en un requerimiento no funcional que probablemente aplique al resto de funcionalidades de nuestra tienda on-line.

La historia técnica necesaria para dotar al sistema de los tiempos de respuesta adecuados podría ser la siguiente:

Rediseñar la arquitectura del sistema que sustenta la web on-line

para que soporte tiempos de respuesta <200 milisegundos

en situaciones de alta concurrencia por encima de los 100 usuarios

Por tanto la forma correcta para la problemática descrita en el post sería de un requerimiento no funcional para una historia de usuario como la que sigue:

Como lector de libros
Quiero poder explorar libros

Para poder escoger el que voy comprar

con el siguiente requerimiento no funcional:

Paso 1

Nombre: usabilidad.rendimiento

Escala: milisegundos entre que el lector clica "buscar" y se le presenta la página con el resultado

Métrica: promedio de los tiempos de búsqueda de libros

Paso 2

Objetivo: <200 milisegundos (lo que Google considera como tiempo de respuesta máximo)

Restricción: >3000 milisegundos (cuando el lector empieza a sentir ansiedad)

Línea base: 1800 milisegundos

Quiero dar mis agradecimientos a Sara y a Miguel por el debate enriquecedor que tuvimos para que pueda escribir este post :-)

¿Cuáles son las ventajas de las historias de usuario?

Historia de usuario - cortesía de freepng.es

Resulta que las historias de usuario son la mejor forma para fomentar la comunicación entre las diferentes partes que intervienen en la construcción de un producto, desde quienes vayan a consumir las funcionalidades que describen hasta los que construyen esas funcionalidades: cliente, Propietario del Producto y equipo de desarrollo.

Hemos desarrollado dos formas de comunicación para recoger y transmitir requisitos, cada una con sus características:

Comunicaciones escritas

• Proporcionan un registro permanente
• Se pueden compartir más fácilmente con grupos y personal remoto
• Se pueden pensar y repensar bien y de forma completa
• Se pueden malinterpretar fácilmente

Comunicaciones verbales

• Podemos recibir feedback de inmediato
• Son dinámicas, adaptamos automáticamente la conversación para maximizar la transmisión del contenido
• Se adaptan fácilmente a nuevos desarrollos
• Provocan ideas nuevas
• Se alcanza fácilmente comprensión y claridad comunes

Las historias de usuario combinan las fortalezas de ambas formas de comunicar, la escrita y la verbal, lo que hace que presenten varias ventajas para utilizarlas como elementos de la pila de producto:

• Proporcionan algo de documentación, pero lo que es más importante es que fomentan la conversación y el debate
• Fomentan la interacción y colaboración entre todos interesados y el equipo ágil al completo
• Son en el lenguaje del usuario y por tanto mantienen una relación cercana con el cliente
• Involucran y captan al cliente para el proceso y para el producto
• Por su naturaleza son independientes
• Facilitan la planificación e implementación
• Son ideales para proyectos con requisitos volátiles o no muy claros
• Alientan el aplazamiento de los detalles hasta el último momento responsable
• Son pequeñas y por tanto fáciles trabajar
• Permiten dividir los proyectos en pequeñas entregas
• Permiten estimar fácilmente el esfuerzo de desarrollo de las mismas
• Funcionan para el desarrollo iterativo ya que al ser pequeñas estas representan requisitos del modelo de negocio que pueden implementarse rápidamente (días o semanas)
• Necesitan poco mantenimiento

¿Cómo afectan los requerimientos no funcionales a la pila de producto?

Los requerimientos funcionales como restricciones

Los requerimientos no funcionales, o NFRs (nonfunctional requirements), representan cualidades generales y restricciones que afectan aplicaciones y sistemas enteros; por tanto afectan a los epics e historias de usuario, que a diferencia de los NFRs definen junto a y sus criterios de aceptación comportamientos y funciones específicas. Una historia de usuario no se puede considerar hecha si no cumple con los requisitos no funcionales asociados.

Los requerimientos no funcionales aseguran que el sistema cumple con cualidades como la usabilidad, seguridad y otras como las que siguen:

Accesibilidad	Confiabilidad	Disponibilidad	Interoperabilidad	Operabilidad	Fiabilidad	Seguridad
Extensibilidad	Trazabilidad	Rendimiento	Recuperabilidad	Mantenibilidad	Certificación	Robustez
Compatibilidad	Conformidad	Escalabilidad	Implementabilidad	Configurabilidad	Eficiencia	Usabilidad

La implementación de nuevos NFRs suele requerir de nuevos elementos en la pila de producto en forma de historias técnicas, estas, una vez incluidas en un sprint, evolucionan el sistema a nuevas restricciones.

Para el cumplimiento de los NFRs se suelen reflejar las restricciones en los criterios de aceptación de las historias de usuario; si se trata de restricciones persistentes se suelen añadir como elementos nuevos en la en la definición de hecho (DoD).

Como todo requerimiento los NFRs se han de describir y cuantificar para arrojar claridad sobre los mismos. Un patrón para describir NFRs es el siguiente:

Paso 1

Nombre (Name): [en forma de cualidad.subcualidad]

Escala (Scale): [Qué medir (unidad)]

Métrica (Meter): [Cómo medir (método)]

Paso 2

Objetivo (Target): [Nivel de éxito a alcanzar]

Restricción (Constraint): [Nivel de fallo a evitar]

Línea base (Baseline): [Nivel actual]

Veamos un ejemplo partiendo de la siguiente historia de usuario relacionada con una librería on-line:

Como cliente

Quiero poder explorar libros

Para poder escoger el que voy comprar

para la que hemos determinado el tiempo de respuesta como requerimiento no funcional, ya que si la página tarda en cargar más de 3 segundos el comprador buscará otras opciones a poco más de un click de distancia:

Paso 1

Nombre: usabilidad.rendimiento

Escala: milisegundos entre que el comprador clica "buscar" y se le presenta la página con el resultado

Métrica: promedio de los tiempos de búsqueda de libros

Paso 2

Objetivo: <200 milisegundos (lo que Google considera como tiempo de respuesta máximo)

Restricción: >3000 milisegundos (cuando el comprador empieza a sentir ansiedad)

Línea base: 1800 milisegundos

¿Es necesario que una PI Planning dure dos días?

Si, ¡¡¡absolutamente!!! Estamos hablando de alrededor de 100 a 125 personas haciendo una planificación trimestral, pero no es por el volumen de personas, sino por la naturaleza del evento por lo que son necesarios 2 días. El patrón de la PI Planning podría verse como sigue:

Día1: Intención -> Borrador del plan -> Crisis ->Día 2: Plan inicial -> Alineamiento

• Intención: representada por los elementos de la pila de producto, en este caso de programa a nivel de tren (ART), esto no es más que el deseo de las capa estratégica y Product Management.
• Borrador del plan: hasta que las personas expertas que vayan a hacer el trabajo no hayan revisado la pila de producto y creado un plan factible, recordemos que los equipos de desarrollo saben mejor que nadie qué es posible y qué no, no podremos iniciar una ejecución con garantías de éxito.
• Crisis: el borrador del plan puede representar una auténtica jarra de agua fría de realidad para Product Management. Es el momento de la crisis, de cotejar deseo con factibilidad y tomar decisiones. Recordemos que crisis también significa oportunidad.
• Plan inicial: para converger la factibilidad un poco más hacia la intención podemos darle una segunda vuelta de tuerca a los planes, basándonos en ajustes identificados en la crisis.
• Alineamiento: los planes iniciales representan la factibilidad, y si negocio los acepta habrá pleno alineamiento entre negocio y ejecución, queda claro lo que es posible construir y los equipos se sienten convencidos del plan inicial. Esto lleva a su vez al compromiso y a tener todos los números para un plan inicial que admita cambios y que termine en una ejecución exitosa.

La razón del porqué de dos días está en la crisis, en el evento de revisión de managers (management review) que ocurre al final del primer día:

Agenda de una PI Planning con los puntos a tratar y quienes intervienen en cada paso - gracias Ángel por la foto

Para la revisión de managers los equipos de desarrollo habrán terminado su jornada y se habrán ido a casa, quedan los Business Owners, Product Managment, RTE, arquitectos y otros líderes y directivos que han recibido un plan impregnado de realidad que probablemente no cuadre al 100% con sus deseos expresados en la pila. Es el momento de aprendizaje sobre lo que es factible, y decidir que ajustes hacer para llevar el segundo día de la PI Planning para acercar así los planes un poco más al deseo. Preguntas que deben de hacerse los managers:

Preguntas en la revisión de managers - cortesía de Pixabay

• ¿Qué acabamos de aprender?
• ¿Necesitamos ajustar la visión? ¿Alcance?
• ¿Necesitamos ajustar la dotación de personal?
• ¿Hay cuellos de botella?
• ¿Esta solución será viable a largo plazo?
• ¿El plan equilibra los objetivos de negocio y de TI?
• ¿Qué decisiones debemos tomar entre hoy y mañana para resolver las brechas?

Los ajustes resultantes son cosas que comunicaran a los equipos al día siguiente para que éstos replanifiquen en la medida de los posible, son ajustes del tipo:

• Prioridades de negocio
• Ajustes de la visión
• Cambios de alcance
• Realineamiento de trabajo y equipos

Resaltar que los ajustes no pueden ser directamente sobre los planes de los equipos, eso les quitaría la propiedad sobre sus planes y por tanto anularía su compromiso. Vayamos pues al porqué de PI Plannings de dos días.

Estamos acostumbrados a la contabilidad de costes poniendo el foco en la eficiencia y en la productividad, y desde esta perspectiva parece que hacer la PI Planning en un día es más eficiente y menos costoso. La realidad es que esa perspectiva ignora el coste de la demora, el coste por no hacer la PI Planning en dos días, el coste por no obtener un plan verdaderamente factible y comprometido por todo el mundo.

Mentes cansadas que han de crear el plan inicial al final de una larga jornada no tendrán el estado mental óptimo para un plan de este calibre. Con una PI Planning de dos días, donde el plan inicial lo elaboran personas despiertas y lúcidas, evitará meses de posibles retrasos por un plan elaborado sin la dedicación adecuada.

¿Cómo ha de ser la relación entre el equipo y los usuarios?

Clarificación versus priorización - imágenes cortesía de
Pixabay: usuarios, Propietario del Producto y equip de desarrollo

Esta es una pregunta clásica de personas que vienen de entornos más tradicionales donde el equipo raramente interactúa con los usuarios y/o el cliente. Recordemos el cuarto principio del Manifiesto Ágil que establece que:

Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto

por tanto debe de existir una estrecha relación entre unos y otros. Las diferentes relaciones entre los responsables para construir el mejor producto posible las debe de fomentar el Scrum Master, me gusta decir que el Scrum Master tiende puentes para conectar los diferentes roles.

Las tres relaciones clave para construir un producto competitivo son como siguen:

• Usuarios y clientes con el Propietario del Producto: el mayor compromiso del Propietario del Producto está con dar la mejor solución a las necesidades de los usuarios y clientes, por tanto es el que toma las peticiones de los mismos, entiende sus necesidades y las prepara para incluir en la pila de producto.
• Propietario del Producto con el equipo de desarrollo: para construir el mejor producto posible el Propietario del Producto se ocupa de que el equipo construya en todo momento la funcionalidad de máximo valor, por tanto su mayor compromiso es priorizar las funcionalidades para el equipo para maximizar el valor entregado.
• Equipo de desarrollo con los usuarios y clientes: el que finalmente construye el producto es el equipo de desarrollo, por tanto podemos entender que la mejor forma para que sus miembros comprendan lo que han de construir éstos interactuen directamente con los que van a consumir el producto. Por tanto hemos de crear un espacio donde usuarios y equipo puedan clarificar desde ambas perspectivas la mejor solución posible, espacio que usualmente ocurre en las reuniones de refinamiento.

LeSS, el marco de escalado para las empresas más maduras en Agilidad, lo muestra claramente en la siguiente imagen:

Product Backlog Refinement en LeSS

¿Cómo tendría que evaluarse una formación Agile?

Actualmente la formación Agile, independiente de su formato taller, curso o workshop se evalúa con encuestas que preguntan al asistente su opinión por el aula, el material, la inscripción, ... ¿cierto?

Ejemplo de una encuesta tradicional

También nos preguntan sobre el profesor, su conocimiento, su capacidad de transmitir, ... ¿a que si?

Y bien avanzada la encuesta, tal vez ya con ganas de terminar porque tenemos que irnos, quizá nos esperan, en el cole, una reunión, el autobús, y nos se preguntan cosas como ¿ha sido útil? y ¿se puede aplicar en su trabajo? ... ¿te resulta familiar?

Estas encuestas son correctas, si bien hemos de preguntarnos ¿qué es lo importante?, y sobre todo ¿quién es el protagonista?

Si nos centramos en el contexto Agile, donde son claves la entrega de valor y la priorización, ¿no os parece que hay amplio espacio para la mejora?

Valores del Manifiesto Ágil

¿Os parece interesante? si es que si sigamos imaginando y soñando. Agile coloca al cliente en el medio, en una formación Agile el cliente es el alumno, por tanto en una evaluación Agile el protagonista debe de ser ¡el alumno!

¿Qué ocurriría si se produjera un MATCH entre ambos objetivos? Sería valor amplificado, si bien, esto sería cierto si los objetivos fueran esos, si bien es posible. Si buscamos el MATCH y consideramos que sea ese el objetivo, qué os parece esta forma de hacer la encuesta:

Uno de los pilares de Agile es la mejora continua y el evento por excelencia para practicarla es la retrospectiva, por tanto ¿no os parece que deberíamos darle forma de retrospectiva a la evaluación de una formación Agile?

En una actividad a final en cada día más una general al final de la formación, donde sería el alumno el que sacara a la luz lo que estuvo bien y lo que es mejorable para la sesión siguiente. Y con sus votos sobre lo que es mejorable el alumno volvería a ser el protagonista en la priorización de las mejoras a tratar. Esto supone que:

• El protagonista es el alumno.
• El interesado clave y cuasi-protagonista es el profesor, él recibe feedback de lo que realmente les importa a los alumnos.
• En segundo plano o desapercibido está el organizador que sin duda tiene interés en la mejora continua de las formaciones.

Ejemplo de retrospectiva a final de curso a modo de evaluación Agile

¿Cómo potenciar la polinización cruzada entre equipos?

Una de las preocupación de Recursos Humanos ágiles, para con sus trabajadores de conocimiento, debe de ser su capacitación continua para asegurar que tengan las habilidades y las informaciones correctas para poder desempeñar sus funciones así como la toma de decisiones descentralizada. En un ambiente sistémico de equipo de equipos, como las tribus o los trenes (ARTs), el conocimiento está en todos los individuos del sistema en forma de mente colectiva. Para mantener esa mente colectiva y difundir el conocimiento a todos, es esencial fomentar la colaboración autoorganizada en forma de polinización cruzada.

La polinización cruzada se basa en individuos que comparten conocimiento, no solo aprovechando conocimiento de otros, sino también motivándose al compartir su conocimiento de forma proactiva. La polinización cruzada creará vínculos entre individuos con intereses similares desde los que pueden surgir grandes ideas e iniciativas.

Una de las mejores propuestas que he experimentado son las que hacen Craig Larman y Bas Vodde con los "Travelers" y "Scouts":

Travelers y Scouts, de Large-Scale Scrum: More with LeSS de Craig Larman y Bas Vodde

Travelers: una forma temporal de viajero que adopta un miembro de equipo experto cuyo objetivo es difundir su conocimiento, probablemente escaso, con los demás equipos, y así explotar y romper cuellos de botella creando esas habilidades en otros. Estos pueden unirse en cada sprint a un equipo diferente para enseñar y mentorizar a los demás mediante pair programming y talleres y sesiones de entrenamiento. Es importante destacar que éstos no realizan el trabajo que requiere de su expertise, enseñan al equipo a hacerlo.

Aunque los travelers no se hayan ideado para formentar la coordinación y la colaboración, al unirse a diferentes equipos crean o fortalecen la tribu o al tren, que es exactamente lo que se necesita para los canales informales de coordinación y colaboración.

Scouts: una técnica simple para la colaboración entre equipos es enviar un Scout a aprender algo de otro equipo, para después traer el aprendizaje al propio equipo. Un evento ideal para iniciar una acción de Scout es atender a la reunión diaria del equipo visitado. Es importante destacar que no debe de ser el Scrum Master el que haga de Scout, quien debe de llevarse el conocimiento es alguien que luego los use en su día a día, por tanto ha de ser un miembro del equipo.

¿Porqué Scrum se basa en equipos funcionales?

Los equipos funcionales son equipos que están compuestos por miembros con las diferentes habilidades y especialidades necesarias para poder construir funcionalidades, componentes de sistemas o historias de usuario de principio a fin. Son equipos con continuidad a largo plazo de entre 3 a 9 miembros colocalizados que se mantienen unidos e integrados para un mayor rendimiento, y aunque los miembros puedan tener habilidades especializadas y áreas en las que estén más enfocados, la responsabilidad recae en el equipo como un todo.

A diferencia de estos, los equipos de componentes están formados por grupos, usualmente temporales, de personas cuya área principal de preocupación se centra en un componente específico o conjunto de componentes del sistema, con una responsabilidad individual sobre "su" parte según su especialización.

Actualmente estoy realizando un curso de LeSS en on-line con Gene Gendel, y la siguiente imagen me inspiró a ver la importancia de los equipos funcionales desde la perspectiva de donde se encuentre la complejidad.

Equipos de componentes versus equipos funcionales - Feature Teams

La complejidad en los equipos de componentes se encuentra entre la pila de poducto y los equipos, en como los equipos toman los elementos de la pila y que dada a su especialización tienen que coordinarse para pasarse el elemento de uno a otro. Usualmente habrá un Propietario del Proyecto focalizado en distribuir y coordinar estos elementos entre los equipos; intentará optimizar el flujo entre equipos, gestionar las dependencias y lidiar con bloqueos y cuellos de botella, en vez de focalizarse en el valor que aportan los elementos al usuario/cliente. Esto por ende convertirá al Propietario de Producto en un gestor de complejidad en forma de jefe de proyecto.

Dado que los equipos de componentes son especializados y se les medirá por las tareas de su especialidad, su interés por colaborar será mínimo y prácticas colaborativas como Sprint Planning 1, Big Room Planning o PI Planning, que podrían resolver la complejidad, no funcionarán.

En el caso de los equipos funcionales, que construyen los elementos de la pila de producto de principio a fin, el Propietario del Producto no ha de preocupare de qué equipo construye qué, y puede focalizarse en la pila, en interactuar con usuarios/clientes y maximizar el valor de negocio. La complejidad está entre los equipos y las funcionalidades o componentes a construir, cuando varios equipos trabajan al mismo tiempo en las mismas funcionalidades o componentes.

Pero esa complejidad tiene solución con técnicas y prácticas conocidas desde hace tiempo con eXtreme Programming y ahora con DevOps. La integración continua facilita la propiedad del código compartido, las pruebas automatizadas aseguran que los componentes sigan comportándose como es esperado después de cada cambio, los despliegues por lotes pequeños que permite DevOps rebajan el riesgo de despliegues fallidos, y su posible impacto, de forma dramática... y quizá debamos de recalcar que las automatizaciones, si están bien implantadas, no fallan nunca, en cambio, el ser humano en su naturaleza, cuyo valor es su creatividad y emocionalidad, es limitado en la amplitud de lo que pueda percibir y abarcar en un mismo momento, y comete errores en cuestiones repetitivas y no motivantes.

¿Cuál ha de ser el tamaño de una pila de producto?

Granularidad de pila de producto

Tener una pila de producto con un tamaño adecuado es esencial para una buena operativa. Una pila demasiado pequeña se "quema" demasiado rápido y existe el riesgo de que el equipo se quede sin historias de usuario y por tanto sin trabajo. Una pila demasiado grande implica que hay un montón de historias de usuario en ella que son irrelevantes y crean ruido.

Las últimas dos terceras partes de una pila demasiado grande seguramente vayan a cambiar en el futuro, y no vale la pena invertir esfuerzo en gestionar historias que sabemos que van a cambiar. Por otro lado una pila demasiado grande afecta seriamente a la capacidad para administrar las historias de usuario de valor, porque nos sumiremos en tratar con cientos de historias posiblemente irrelevantes o simplemente incorrectas o duplicadas. Lo más grave es que desviará nuestro foco del descubrimiento de nuevas historias de valor para nuestros clientes y no seremos capaces de actualizar las historias existentes a medida que obtengamos nueva información fresca.

No es inusual ver casos disfuncionales en los que la pila tiene más de 300 historias y el equipo que las construye tiene una velocidad media de 5 historias por sprints de dos semanas.

Una buen tamaño resulta en una parte superior de la pila de producto con 2 a 3 sprints de historias que cumplan con la definición de listo (DoR), y el resto de elementos que conformen la release en curso con elementos menos granulares en forma epics. La siguiente release debería de tener epics y temas, y las releases futuras solo grandes elementos como los son los temas.

Las pilas anidadas que forman la pila de producto en el marco de SAFe

Si nos hacemos la misma pregunta en un marco de escalado como SAFe® hemos de recordar primero que la pila de producto estará divida en varias pilas anidadas y mirar cada una de ellas:

Pila de equipo (Team Backlog): el tamaño de la pila queda limitado a las historias de usuario que el equipo haya incluido en la PI Planning para el siguiente PI, un periodo de tiempo de entre 2 y 3 meses. En mi experiencia estamos hablando de entre 20 y 40 historias de usuario.

Pila de programa (Program Backlog): un tren (ART) o tribu gestiona en su tablero Kanban aproximadamente tantas features como las que pudiera construir el tren en 3 PIs, un periodo correspondiente de entre 6 y 9 meses. En mi experiencia estamos hablando de entre 20 y 40 elementos, de los que entre 10 y 15 son pila del PI en curso.

Pila de solución (Solution Backlog): para los trenes de trenes, los Solution ART, los números en capabilities, muy grandes features, son similares.

Pila del portfolio (Portfolio Backlog): el tamaño dependerá de la pila con iniciativas estratégicas, o epics en SAFe, y dependerá de cuantas lineas de negocio cubra y cuantos trenes o personas estén asociadas a sus Value Streams. En un portfolio con un solo tren de unas 120 personas tiene sentido un tablero Kanban que gestione de 10 a 15 epics anuales y que tenga alrededor de 3 en curso; en un portfolio con trenes que sumen unas 2000 personas tiene sentido un tablero Kanban con alrededor de 150 epics anuales, con entre 30 y 40 en curso.

Estos números son números que he recolectado en diferentes clientes y experiencias, y que no pretenden ser nada más que para dar una idea aproximada.

---

Ningúna pila visible para el equipo debe de tener más de un trimestre corrido de trabajo proyectado. Más sería desperdicio.
Diana Larsen, del meetup "How do limits empower your Agility?"

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.