¿Cómo lidiar con un interesado dominante?

Una de las responsabilidades de un Propietario del Producto es la gestión de los interesados; es quien está en primera línea ante los conflictos de prioridades y necesidades de éstos. Aunque la Agilidad nos provee de una priorización que maximiza las decisiones de un Propietario del Producto desde el punto de económico, este rol requiere habilidades sociales para balancear las necesidades de los diferentes interesados y moverse exitosamente en el panorama político de la compañía.

Imaginemos un interesado dominante que no está conforme con la priorización de sus deseos en nuestra pila de producto, por ejemplo un manager que siempre ha hecho que las cosas ocurran e insiste en que demos prioridad a lo suyo, ¿cómo podemos lidiar con él?

Modelo de comportamiento DISC

En 1928 William Moulton Marston, psicólogo fisiológico de Harvard, introdujo el modelo de comportamiento DISC que permite categorizar a todos las personas (mentalmente sanas) en cuatro perfiles básicos de personalidad. Resulta que, aunque todos seamos diferentes y únicos, nuestras tendencias de comportamiento, las reacciones y las emociones, son comunes y predecibles. Por tanto, si como Propietario del Producto somos capaces de situar a los interesados en DISC, esta herramienta puede ayudarnos a entender mejor sus reacciones y comportamiento y por ende a mejorar la relación y comunicación con estos. A la luz de DISC podemos conocerlos mejor y saber lo que les gusta, lo que les motiva, cuales son sus prioridades, sus fortalezas, sus áreas de crecimiento, sus miedos y dolores, lo que les irrita y estresa, en qué ámbitos sienten seguridad...

• Dominancia: persona que pone énfasis en lograr resultados, en el resultado final y en la confianza. Sus tendencias de comportamiento incluyen: ver el panorama general, ser muy franco, aceptar desafíos y ir directo al grano.
• Influencia: persona que pone énfasis en influir o persuadir a los demás, en la apertura y en las relaciones. Sus tendencias de comportamiento incluyen: mostrar entusiasmo, ser optimista, le gusta colaborar y no le gusta ser ignorado.
• Serenidad: persona que pone énfasis en la cooperación, la sinceridad y la confiabilidad. Sus tendencias de comportamiento incluyen: no le gusta que lo apresuren, ser calmado, sus enfoques son calmados y sus acciones son de apoyo.
• Cumplimiento: persona que pone énfasis en la calidad y la precisión, la experiencia y la competencia. Sus tendencias de comportamiento incluyen: disfrutar de su independencia, razonar de forma objetiva, necesitar de detalles y temer a equivocarse.

Para identificar el estilo de personalidad de un interesado podemos aplicar la técnica que sigue y que he extraído del artículo "La Teoría del DISC" de DISC for All que recomiendo fervientemente leer:

1. ¿Es de ritmo rápido o lento?
¿Cómo se mueve? ¿Tiene prisa o por el contrario espera pacientemente su turno?

2. ¿Está orientados a personas o a tareas?
¿Parece interesado en socializar con el resto, te cuenta que ha hecho el fin de semana o por el contrario prefiere simplemente realizar sus tareas y cuenta poco de su vida? .

¿Es este individuo de ritmo rápido orientado a tareas? Puede ser un perfil D
¿Es de ritmo rápido y orientado a las personas? Puede ser un perfil I
¿Ritmo lento y orientado a las personas? Puede ser un perfil S
¿Ritmo lento y orientado a tareas? Puede ser un perfil C

Una vez identificado el perfil entendamos su personalidad e imaginémonos ante el interesado y dejemos que nuestra inteligencia emocional nos muestre sus posibles reacciones.

Volvamos pues a nuestro manager dominante: sin duda es un perfil D, decidido y ejecutivo, al que contentaremos ofreciendo soluciones y proveyendo opciones. Si por el contrario le proveyéramos de muchos detalles, como necesita el perfil C, o le realizáramos muchas preguntas, como necesita el perfil I, se pondría nervioso e intentaría coger las riendas.

Para cerrar quiero compartir el siguiente cuadrante de DMIT Training 360° que nos ayudará a qué acciones podemos intentar y qué reacciones cabe esperar de los distintos perfiles.

Perfil D - Dominancia

Intentar:

• Hacer ser breve e ir al grano
• Respetar su necesidad de autonomía
• Ser claro acerca de reglas y expectativas
• Dejarles iniciar
• Mostrar tu competencia
• Ceñirse al tema
• Mostrar independencia
• Eliminar pérdidas de tiempo

Estar preparado para:

• Enfoques directos y exigentes
• Carencia de empatía
• Carencia de sensibilidad
• Poca interacción social

Perfil I - Influencia

Intentar:

• Acercamiento de manera informal
• Estar relajado y ser sociable
• Dejarles verbalizar pensamientos y sentimientos
• Mantener las conversaciones ligeras
• Proveerles de detalles escritos
• Darles reconocimiento público por logros individuales
• Usar el humor

Estar preparado para:

• Intentos de persuadir/influenciar en otros
• Necesidad de ser el centro de atención
• Sobreestima de si mismo y otros
• Respuestas emocionales

Perfil S - Serenidad

Intentar:

• Ser lógico y sistemático
• Valorar altos estándares
• Ser preciso y focalizado
• Proveer de hechos e información de fondo
• Ser discreto y reservado emocionalmente
• Mostrar confiabilidad
• Dar tiempo de preparación

Estar preparado para:

• Preguntas
• Resistencia a preguntas vagas y generales
• Deseo de volver a comprobar
• Poca necesidad de afiliarse con otras personas

Perfil C - Cumplimiento

Intentar:

• Ser cálido y solidario
• Dar expectativas y plazos claros
• Permitir que el precedente sea una guía
• Proveer de un entorno consistente y seguro
• Dejarles saber como se harán las cosas
• Usar la apreciación sincera
• Mostrar su importancia para el bien organizacional

Estar preparado para:

• Un enfoque amistoso y cálido
• Ser lento en el cambio
• Dificultades para priorizar
• Dificultades con plazos de entrega

Thanks to Disc for All and DMIT Training 360° for the shared information on the intenet :-)

¿Cuál debería de ser la experiencia que debiera tener alguien para ser coach ágil?

La lista de Jem "Jelly"

Jem "Jelly", que lleva desde 2005 trabajando con más de 100 equipos ágiles, ha creado una lista con "10 things to *PRACTISE* before calling yourself an Agile Coach" que quiero presentar en este post y con la estoy totalmente en sintonía.

Es cierto que ha habido gran proliferación de coaches ágiles, especialmente al estilo tradicional como cargo o título en vez de como un rol que lleva implícito un agente de cambio empoderado, cuyo objetivo es fomentar el cambio e ir a contracorriente de la inercia de la compañía.

Por ello es tan importante entender bien el rol y así poder desempeñar las responsabilidades que conlleva. Podemos adquirir el conocimiento asistiendo a cursos especializados, pero el entendimiento solo lo lograremos con la experiencia y aprendiendo de nuestros errores.

La lista resume de forma excelente 10 cosas que cualquier coach ágil debería de entender profundamente.

1. Scrum Master, facilitador Kanban o equivalente de un equipo al menos durante 2-3 años.
2. Haber ayudado a los equipos a visualizar su trabajo, ayudándoles a obtener sus propios acuerdos de trabajo, definición de hecho (DoD), etc.
3. Haber creado un flujo de valor, ayudando al equipo y equipos a colaborar en el panorama general, capaces de detectar desperdicios y haber explorado varias maneras para que los equipos colaboren en términos de la mecánica de gestionar y/o eliminar dependencias.
4. Entender y haber ayudado a los equipos a establecer un equilibrio entre: (1.) construir la cosa de forma correcta (2.) construir la cosa correcta (3.) construir la cosa con velocidad.
5. Haber aplicado técnicas de desglose de trabajo para validar aprendizajes más rápidamente y mitigar riesgos (MPVs, Impact Mapping, división de historias de usuario, User Story Mapping, etc.).
6. Haber ayudado a los equipos usando enfoques "Termina de empezar y en lugar de ello empieza a terminar trabajo" (pensamiento en enjambre, límites WIP, conceptos "empuje" versus "arrastre").
7. Saber articular COMO poner en práctica los valores y principios ágiles en un equipo.
8. Haber aplicado/introducido pensamiento empírico en ambos procesos de equipo y negocio (al menos haberlo intentado con "negocio", por ejemplo habiendo ayudado al Propietario del Producto a usar el cono de la incertidumbre y a crear una pila de producto).
9. Saber demostrar de forma confiada cuando y porqué no utilizar un marco ágil.
10. Haber influenciado a equipo y managers para catalizar el cambio a través de datos empírico subjetivos y objetivos.

Thanks Jem "Jelly" to encourage to share your list :-)

¿Scrum ha muerto?

Me ha llamado la atención el artículo "Scrum Is Dead. All Hail Kanban, the New King" de Emanuel Marques, eso me ha llevado a observar paralelismos en la realidad que yo vivo y a reflexionar sobre todo ello.

El artículo resume que Scrum no es suficientemente ágil ya que las personas ponemos demasiado énfasis en el proceso. Resalta que la métrica más utilizada para evaluar el éxito suele ser el compromiso frente al hecho, cuando comparamos las historias de usuario comprometidas en la planificación del sprint con las historias que el equipo entrega en la revisión del sprint. Pero...

• ¿Entregar una historia de usuario el primer día de sprint siguiente realmente está mal?
• ¿Cuando haya sido necesario hacer un trabajo inesperado (cambios por información fresca, bugs, problemas de producción, etc.) significa incumplir el compromiso de la planificación de sprint?

Scrum no es un marco de trabajo,
es talento en equipos autogestionados
cortesía de Scrum Manager en Pinterest

Uno de los aprendizajes más difíciles para las empresas es permitir que sus equipos maduren (a performing) y encuentren el ritmo adecuado para empezar y acabar historias de usuario en cada uno de sus sprints. Es difícil porque implica balancear la producción con la capacidad real de los equipos y la cultura tradicional suele estar impregnada de sobrecarga constante de trabajo hacia esos equipos.

Por ello Scrum es un excelente punto de partida para encontrar ese ritmo y adentrar a la compañía en Agilidad; sin olvidar que el nivel de Agilidad va a depender en primera instancia de los Scrum Masters y coaches ágiles que lideren la transformación, y en segunda de la cultura y resistencia de la empresa.

Como nos quiere mostrar Emanuel Marques, muchas veces nos olvidamos que el objetivo de una implantación de Scrum no es Scrum en sí, sino encontrar a través de la mejora continua nuestra manera singular de trabajar alineados con los valores ágiles y así maximizar la entrega de valor a través de personas motivadas.

Y eso significa que deberíamos de romper las reglas de Scrum en algún momento, ya que la mejora continua nos llevará a métodos y prácticas mejores.

Llevemos ese pensamiento al extremo...

25 años después de la presentación de Scrum en la OPSLA'95 la realidad del software ha cambiado mucho. Las empresas que saben hacer software de calidad se basan en ciclos de construcción y feedback cortisimos, Amazon por ejemplo completa el ciclo del radar DevOps, desde hipótesis de funcionalidad a aprendizaje sobre su uso, en 24 horas, además de realizar una media de 168 despliegues en producción al día. El su libro de "Project to Product" Mik Kersten concluye que "aquellos que dominen la entrega de software a gran escala definirán el panorama económico del siglo XXI".

Miremos pues en esa dirección, a empresas como Facebook, Apple, Amazon, Netflix y Google, y preguntémonos desde su perspectiva si Scrum ha muerto.

¿No sería más contemporáneo a nuestra realidad partir de donde nos encontremos con Kanban? ¿Fomentar el flujo continuo de entrega de valor invirtiendo fuertemente en cultura, prácticas y herramientas DevOps? ¿Desarrollar equipos con continuidad basados en el talento de personas motivadas?

Pienso que Scrum no ha muerto, hay muchas empresas que todavía pueden transicionar de pensamiento de proyecto al de producto, y muchas que pueden aprender a terminar cosas antes de empezar nuevas. También pienso que Scrum como proceso está ya en plena fase de commodity; tiene valor de utilidad pero un nivel de diferenciación muy escaso.

¿Qué hay detrás de desescalar para escalar?

Cuando en Agilidad hablamos de escalar de lo que estamos hablando es de escalar Scrum de un solo equipo a un Scrum escalado a equipos de equipos en grandes empresas.

Si nos situamos en Scrum y recordamos las características de los equipos de Scrum, veremos que se trata de equipos multifuncionales y autoorganizados, idealmente de equipos con independencia en habilidades y toma de decisiones para poder construir cosas de principio a fin. Podemos entender de que se trata de una estructura plana en la que la relación entre los roles es de iguales, y que todos ellos tienen responsabilidades complementarias que no se pisan unas a otras.

LeSS Escala Scrum Desescalando
Thanks to Gene Gendel

Por tanto cuando hablamos de escalar Scrum estamos hablando de escalar estructuras planas. Las estructuras de grandes empresas suelen ser estructuras muy jerárquicas que sobrecargan los flujos de valor con desperdicio (retrasos, burocracia, actividades que no agregan valor) y que por tanto suelen representar cuellos de botella que afectan seriamente al time-to-market. Una transformación ágil debe de tratar, entre otras, de desescalar y aplanar estas estructuras jerárquicas para eliminar esos cuellos de botella y acelerar el flujo de valor.

La aproximación de LeSS(Large-Scale Scrum)

El primer propósito de LeSS es desescalar a través del cambio organizacional. Desescalar el número de roles, estructuras organizativas, dependencias, complejidad arquitectónica, mandos intermedios, localizaciones y número de personas. LeSS no trata de escalar un equipo a varios equipos, LeSS trata de escalar Scrum para lograr el desescalado organizacional.

El objetivo principal de LeSS en esa desescalada es exponer crudamente el dolor de ser grande, derrochador y lento. Para ello propone el modelado sistémico averiguando las variables que existen en el sistema, cuales son relevantes para la empresa y como estas están interrelacionadas para maximizar las deseables y quitar las que son desperdicio a través de círculos virtuosos y viciosos.

La aproximación de SAFe (Scaled Agile Framework)

SAFe aborda la desescalada de manera diferente introduciendo un segundo sistema operativo organizacional, que aplicado a la estructura jerárquica existente crea una red empresarial centrada en el cliente con equipos y trenes (ARTs) autorganizados, que por ende son estructuras desescaladas paralelas a la jerarquía.

SAFe desescala a través del segundo sistema operativo organizacional a flujos de valor (Value Streams) y trenes (ARTs)
Imagen del tema Business Agility cortesía de © Scaled Agile, Inc.

La jerarquía tiene su razón de ser, necesitamos una jerarquía de liderazgo y de flujo de comunicación cuando hablamos de empresas de miles de empleados, por tanto en grandes empresas probablemente no podamos prescindir de estas. Utilizando el marco de SAFe como segundo sistema operativo organizacional introducimos el noveno principio de SAFe, la descentralización de la toma de decisiones, que desescala llevando las decisiones allí donde está la información dentro de las estructura de red empresarial.

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

¿Existe una simulación para experimentar el WIP en una simulación Kanban?

Meetup "Featureban" organizado por Agile Women

Justo antes de la crisis del COVID-19 el grupo de meetup Agile Woman organizó un meetup sobre Featureban, un juego de simulación para Kanban creado en 2014 por Mike Burrows que es muy poderoso, simple, divertido y que propicia la reflexión.

El juego muestra de forma sencilla como implementar la gestión visual en nuestros primeros tableros Kanban, para luego introducir límites WIP y gestionar y acelerar el flujo de trabajo.

Cuando sobrevino el COVID-19 tuvimos que aprender a realizar todas nuestras actividades, incluidas las formaciones, de forma remota. Para nuestros cursos de Kanban en Estratecno fue necesario encontrar una simulación de Kanban que mostrara el funcionamiento de los límites WIP... y allí estaba la versión on-line e interactiva de Featureban de uso gratuito que Kaiten ha creado y puesto a disposición de la comunidad.

El tablero en formato físico original y en formato on-line

El tablero de la simulación es relativamente simple, tiene cuatro estados: "Ready/Queue", "Doing", "Validating" y "Complete/Done". La simulación trata de mover una serie de fichas de "Ready/Queue" a "Done", y una moneda (cara/cruz) o dos naipes (rojo/negro) introducen la variabilidad del día a día para indicar si fue un buen o un mal día. Simplificando la reglas en un buen día el jugador avanza una ficha o desbloquea una ficha propia o la de otro, y en un mal día bloquea una de sus fichas.

Se juega con al menos 3 jugadores y cuenta con 3 ciclos o iteraciones. El primer ciclo se ejecuta sin limitar el WIP y en los dos siguientes se limita "Doing" y "Validating" con un WIP = 3. La diferencia de los ciclos 2 y 3 está en que en el segundo ciclo se parte de la situación final del primer ciclo, y en el tercer ciclo de una situación de cero.

Al terminar cada ciclo los jugadores hacen una retrospectiva sobre qué han aprendido y qué decisiones y acciones de mejora pueden incorporar para los siguientes ciclos y así acelerar el flujo.

Dos situaciones del juego en on-line, una con una carta roja (buen día), y otra con una carta negra (mal día)

El primer ciclo se inicia sin limites WIP y las monedas o cartas con sus movimientos y bloqueos se encargan de llenar el tablero con largas colas de fichas en "Doing" y "Validating", provocando una pobre entrega en "Complete/Done".

Plantillas para registrar tiempos de ciclo

Al introducir límites WIP en el segundo ciclo obligamos a los jugadores a colaborar y a tomar decisiones a favor del flujo para ir deshaciendo poco a poco el caos del primer ciclo. Los jugadores descubrirán al final del ciclo que la entrega de fichas es sensiblemente superior a la del primer ciclo.

El tercer ciclo, en el que se parte de una situación desde cero y donde la entrega de fichas es todaví mayor, muestra de nuevo la potencia de los limites WIPs y de como éstos fomentan la colaboración.

La simulación incluye plantillas para tomar métricas y dibujar un diagrama de flujo acumulado (CFD). En el caso de la simulación on-line las métricas y el resumen se generan forma automática.

Podemos observar buenos resultados en la imagen que sigue más abajo:

• Los ciclos o iteraciones 1 y 2 han resultado en la entrega de 11 fichas, mientras que el ciclo 3 ha resultado de por si solo en la entrega de 13 fichas. ¡Más fichas en la mitad de tiempo!
• El CFD muestra una pendiente para "Doing" y "Validating" con cierta homogeneidad, lo que muestra un buen flujo y por ende una buena colaboración entre los jugadores.

Resumen que da de forma automática la simulación on-line

Para aquellos que quieran facilitar la simulación on-line de Kaiten pueden descargar The Facilitator Guide que Evgeniy Stepchenko ha puesto disposición de la comunidad.

---

Actualización marzo 2021

Recientemente Featureban ha añadido a la simulación 3 nuevas características muy interesantes:

• Ya es multidioma y podemos jugar en castellano (spanish)
• Podemos seleccionar entre un juego de fichas de TI (informática) y uno de Marketing
• Y podemos cargar nuestro propio juego de fichas :-)

Nuevas características de Featureban: Fichas de Marketing e idioma ES

¿Criterios de aceptación o condiciones de satisfacción?

La satisfacción del usuario es clave para calidad y compromiso
cortesía de Pixabay

Hemos tenido mucho debate sobre si los criterios de aceptación son una práctica ágil.

Recordemos que la parte importante de las historias de usuario es la conversación. Cuando las visualizamos como descripción corta en un post-it lo que estamos haciendo es comprometernos a conversar sobre estas más adelante.

Algunas compañías buscan en los criterios de aceptación un lugar donde escribir una especificación detallada y precisa para mantenerse lo más cerca posible de especificaciones detalladas tradicionales. Lo hacen agregando detalle como criterios de aceptación en lugar de hacerlo de forma ágil, que consiste en agregar detalle dividiendo la historia en historias más pequeñas.

Imaginemos la siguiente historia de usuario:

Como viajero

Quiero seleccionar las fechas de ida y de vuelta

Para poder comprar los billetes de tren e ir de vacaciones

con los siguientes criterios de aceptación:

Comprobar que las fechas no son un momento previo a la mayoría de edad del usuario

Comprobar que las fechas no sean un momento anterior al actual

Comprobar que la fecha de vuelta no es anterior a la de ida

Comprobar que el formato fecha se corresponde al formato aceptado por el sistema (DD/MM/AAAA)

El término "criterios de aceptación" puede llevar a un equipo de desarrollo a que no se sienta involucrado en la definición de la historia. Simplemente puede que se limite a tomar cada uno de los criterios e implementarlos uno a uno. Si finalmente el resultado no se comporta como hubiéramos deseado es porque el Propietario del Producto no ha incluido algún criterio de aceptación faltante.

Mike Cohn habla de condiciones de satisfacción, como condiciones específicas de una historia de usuario y que definen lo que debe ser cierto para que ese elemento de la pila se considere hecho.

Utilizando condiciones de validación en la historia del ejemplo anterior quedaría:

El usuario puede operar cuando a la fecha de ida sea mayor de edad

El usuario puede comprar un billete cuando las fechas seleccionadas sean posteriores al momento actual

El sistema no permitirá avanzar al usuario en la compra si las fechas no son coherentes

El formato de fecha con el que opera el sistema es DD/MM/AAAA

Con el término "condiciones de satisfacción" el equipo está enfocado en resolver el problema del usuario en lugar de implementar los criterios definidos anteriormente. Toda implementación de una historia de usuario debe de comenzar con una conversación que culmina en la planificación de sprint, conversación en la que el equipo debe de hacerse preguntas como:

• ¿Cómo podemos ofrecer el mayor valor con el menor esfuerzo?
• ¿Cuál es la funcionalidad mínima que tenemos para ofrecer?
• ¿Cómo podemos abordar las necesidades del usuario?

Bajo esta perspectiva podemos entender la definición de hecho (DoD) como un conjunto especial de condiciones de satisfacción que se agregan a toda historia de usuario.

Aprender a utilizar condiciones de satisfacción puede tomar un poco más de tiempo al principio, pero vale la pena invertir en este esfuerzo, ya que un equipo comprometido con el producto siempre puede encontrar mejores soluciones que un Propietario del Producto que escriba criterios de aceptación en solitario.

En mi opinión las condiciones de satisfacción ayudan a enfocar en lo que importa, aunque ninguna de las dos opciones es mejor que la otra, depende de como se usen.

¿Hay algún patrón adecuado para escribir epics?

A/B Testing, una forma de validar una hipótesis
cortesía de Icons Icons

Recordemos que un epic se puede considerar como una superhistoria de usuario que se distingue por su gran tamaño, como una etiqueta que aplicamos a una historia grande cuyo esfuerzo es demasiado grande para completarla de una sola vez o en un solo sprint. A diferencia de las historias de usuario, que tienen baja granularidad, los epics tienen una alta granularidad y un alto grado de incertidumbre asociados. Realmente cualquier epic, e incluso una historia de usuario, no es más que una hipótesis; hasta que nuestro usuario la vea o la utilice y nos de feedback no sabremos si es la solución adecuada.

Desde este punto un epic lo podemos entender como una serie de experimentos, futuras historias de usuario, que construyen funcionalidad de forma incremental hasta llegar al resultado esperado. Esta forma de desarrollar epics ocurre como ciclo Lean Startup que mediante el desarrollo guiado por hipótesis, o hypothesis driven development (HDD), trata de desarrollar nuevas ideas, productos y servicios. A través de ciclo de feedback vamos validando nuestra hipótesis de manera que el Propietario del Producto gane comprensión sobre la solución más adecuada.

Como ejemplo está la técnica A/B Testing, que se utiliza en el ámbito del Marketing Digital y la Analítica web, que trata de identificar la mejor solución para un epic construyendo dos soluciones y realizando experimentos aleatorios con las dos variantes, A y B, siendo una la de control y la otra la variante. ¿No os ha pasado que lo que veis en Amazon en vuestro dispositivo es diferente a lo que ve vuestro compañero?

Barry O'Reilly popone el siguiente patrón en su artículo "How to Implement Hypothesis-Driven Development":

Creemos que [esta capacidad]

Resultará en [este resultado]

Tendremos confianza para proceder cuando [veamos una señal medible]

Patrón HDD de Barry O'Reilly

Creemos que [esta capacidad]

Responde a la pregunta ¿Qué funcionalidad desarrollaremos para probar nuestra hipótesis? Al definir la capacidad de una "prueba" del producto o servicio que estamos intentando construir, identificamos la funcionalidad y la hipótesis que queremos probar.

Resultará en [este resultado]

¿Cuál es el resultado esperado de nuestro experimento? ¿Cuál es el resultado específico que esperamos lograr al desarrollar la capacidad de "prueba"?

Tendremos confianza para proceder cuando [veamos una señal medible]

¿Qué señales indicarán que la capacidad que hemos construido es efectiva? Qué métricas predictivas clave (Leading Indicators) cualitativas y/o cuantitativas mediremos para proporcionar evidencia de que nuestro experimento ha tenido éxito y darnos suficiente confianza para pasar a la siguiente etapa.

Ejemplo de un epic de negocio escrito con este patrón:

Creemos que aumentar el tamaño de las imágenes de los restaurantes en la página de reserva

Resultará en una mejor participación y conversión del cliente

Tendremos confianza para proceder cuando

veamos un aumento del 5% en los clientes que revisan las imágenes de los restaurantes

y luego proceden a reservar en los próximos 2 minutos

My thanks to Barry O'Reilly on who I have based and who inspired me for this post :-)