Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Equipo. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Equipo. Mostrar todas las entradas

lunes, mayo 08, 2023

La Retrospectiva de las Olimpiadas Scrum

 

La publicación de mi nueva lista de chequeo de Scrum fue todo un éxito. Más de mil personas han descargado la lista en menos de una semana. Las dimensiones y capacidades de la lista y los radares se convirtieron desde ya en un instrumento de primer orden para los líderes ágiles. Muchas gracias a todos por el constante apoyo y por la recepción de mis ideas. Si aún no has descargado la lista, puedes ir a:

http://www.gazafatonarioit.com/2023/05/eleva-tu-juego-de-scrum.html

De otro lado, las retrospectivas no tienen que ser aburridas para tener resultados asombrosos que permitan a los equipos y organizaciones diseñar un plan de mejora continua que permita que las personas y los equipos crezcan, se energicen continuamente y se diviertan mientras lo hacen.

Juntando las 2 cosas, la lista y las retrospectivas, les traigo esta vez una de las primeras retrospectivas que diseñé para que el uso de la lista fuera también diferente, atractivo, divertido, eficaz e innovador, a la vez que se fomente la comunicación, colaboración y el aprendizaje en los equipos.

Título:

La Retrospectiva de las Olimpiadas Scrum

Objetivo:

Involucrar al equipo en una retrospectiva animada con el tema de los Juegos Olímpicos utilizando la nueva lista de verificación de Scrum mientras se promueve la colaboración, el aprendizaje y la mejora en un entorno competitivo y divertido.

Duración:

60 - 90 minutos

Materiales:

  • Lista de verificación de Scrum
  • Pizarra grande o pizarra virtual
  • Notas adhesivas (físicas o virtuales)
  • Marcadores o herramientas de dibujo virtuales
  • Temporizador
  • Medallas o premios virtuales (opcional)

Configuración:

  1. Dibuja un estadio olímpico en la pizarra o tablero virtual.
  2. Crea seis áreas dentro del estadio, cada una representando una de las dimensiones de la lista de verificación de Scrum.
  3. Etiqueta cada área con el nombre de la dimensión correspondiente:

·       Personas,

·       Eventos,

·       Artefactos y Compromisos,

·       Producto,

·       Prácticas Ágiles y

·       Soporte y alineación organizacional.

  1. En cada área, crea secciones para las capacidades dentro de esa dimensión.

Pasos retrospectivos:

  1. Ceremonia de Apertura (5 minutos)
    • Explica el objetivo de la retrospectiva y el tema de las Olimpiadas.
    • [opcional] Si creas un eslogan para la retrospectiva, por ejemplo, "Ve por la de Oro Ágil: ¡Conquista las Olimpiadas Scrum y transforma tu equipo!", este es el momento de expresarlo para motivar al equipo.
    • Enfatiza la importancia de la colaboración, la competencia amistosa y la seguridad psicológica durante la retrospectiva.
  2. Formación del equipo (5 minutos)
    • Divide el equipo en grupos más pequeños de 2-3 personas.
    • Asigna a cada grupo una dimensión de la lista de verificación de Scrum. O haz que se autoorganicen y que cada equipo seleccione su dimensión y las capacidades respectivas.

No tienes que abordar todas las dimensiones ni capacidades en una única retrospectiva. Esto es útil cuando se trata de equipos grandes o de equipo de equipos.

    • Anima a los grupos a pensar en un nombre de equipo creativo y, opcionalmente, una ovación o porra de equipo. ¡Da puntos extras por la mejor porra!
  1. Los juegos Scrum (20 minutos)
    • Indica a cada grupo que revise las preguntas esenciales dentro de su dimensión asignada y califique su desempeño para cada pregunta (Nunca, Rara vez, Ocasionalmente, Casi siempre, Siempre).
    • Para cada pregunta, los grupos ganarán puntos según sus calificaciones: Nunca (0 puntos), Rara vez (2 punto), Ocasionalmente (4 puntos), Casi siempre (7 puntos), Siempre (10 puntos).
    • Anima a los grupos a reflexionar sobre sus calificaciones e identificar áreas de mejora.
  2. El podio (10 minutos)
    • Haz que cada grupo presente sus hallazgos, compartiendo el número de puntos, calificaciones y puntos de vista con el resto del equipo.
    • Anima a otros miembros del equipo a hacer preguntas, proporcionar retroalimentación o compartir sus propias experiencias relacionadas con cada pregunta.
  3. Relevo de mejora (15 minutos)
    • Pídele al equipo que haga una lluvia de ideas sobre mejoras basadas en los hallazgos compartidos.
    • Pide a los miembros del equipo que escriban sus ideas en notas adhesivas y colócalas en el área correspondiente dentro del estadio olímpico.
  4. Maratón de votaciones (10 minutos)
    • Como equipo, invítalos a que discutan las ideas de mejora y voten por las 1-3 ideas principales para enfocarse en el próximo sprint.
  5. Relevo del Plan de Acción (10 minutos)
    • Para cada idea de mejora priorizada, definan acciones específicas, con responsabilidades y establezcan plazos posibles y plausibles.
    • Asegúrate de que cada acción sea clara, procesable y alcanzable en el próximo sprint o, al menos de que haya un avance significativo.
  6. Ceremonia de Clausura (5 minutos)
    • Opcionalmente, otorga medallas o premios virtuales a los equipos en función de sus puntos.
    • Agradece a todos por su participación y aportes.
    • Anima a los miembros del equipo a continuar reflexionando sobre su práctica de Scrum y aplicando las lecciones aprendidas de esta retrospectiva.
    • Enfatiza la importancia de la mejora continua y el mantenimiento de una mentalidad colaborativa y orientada al crecimiento.

Esta retrospectiva innovadora, atractiva y divertida animará a tu equipo a reflexionar sobre sus prácticas de Scrum, colaborar de manera eficaz e identificar oportunidades de mejora utilizando la nueva lista de verificación de Scrum como guía en un entorno olímpico competitivo.

Adendum: de eslóganes y de porras

Algunos de los mejores eslóganes que han surgido durante la ejecución de esta retrospectiva incluyen:

Corre hacia el éxito: ¡Libera al atleta ágil que llevas dentro en las Olimpiadas Scrum!

Los campeones de Scrum se unen: ¡Descubre tu ventaja ganadora en las Olimpiadas Scrum!

Y estas son algunas de las porras más divertidas con las que me encontrado, incluso con coreografías entretenidas:

"¡Fuerza Scrum, juntos triunfaremos! ¡Ágiles y fuertes, sprint tras sprint! ¡Campeones del Checklist, a volar sin límites!"

"¡Uno, dos, tres! ¡Espíritu ágil, libéranos! ¡Checklist Olímpicos, lideraremos con éxito!"

"¡Scrum Masters, Desarrolladores, POs - unidos! ¡Héroes ágiles, corriendo hacia nuevas metas! ¡Los Checklist Olímpicos, nuestra alegría compartida!"

Déjanos conocer tu experiencia usando esta Retrospectiva Scrumtacular y, por supuesto, cuéntanos de los eslóganes y porras con las que has jugado.

 

martes, mayo 02, 2023

Eleva tu juego de Scrum

 

Haz clic en la imagen para ampliarla

O de cómo desbloquear el éxito con esta nueva lista de verificación ágil integral

Presentación

¡Scrum está cumpliendo 30 años! Fue creado por Jeff Sutherland en 1993.

El primer paper de Scrum lo escribió Ken Schwaber en 1995. SCRUM Development Process. Y la primera guía la coescribieron y publicaron Sutherland y Schwaber en 2010.

El mundo ha cambiado desde entonces. Y en el último lustro, sobrevivimos a una pandemia y la Inteligencia Artificial se tomó como por asalto y en un santiamén el estrado de la mente humana. Pronto escribiré o hablaré sobre todo esto.

Por ahora, para celebrar estas tres décadas en que hemos asistido a un cambio substancial en la forma cómo hacemos las cosas, no solo en el trabajo, sino en nuestra vida personal, traigo a la fiesta de cumpleaños de Scrum esta Nueva Lista de Verificación Nueva de Scrum. ¡Es un juego de palabras! Algunos dirán, incluso con desgano: “¡¿Todavía una nueva lista de chequeo de Scrum más?!”

Las listas actuales son antiquísimas a estas alturas del tiempo. Desde la primera guía publicada en 2010 hasta la más reciente, divulgada en noviembre de 2020, Scrum ha pasado por algunos cambios, algunos más profundos que otros, pero cambios, al fin y al cabo. La esencia de Scrum se ha mantenido, incluso en todos estos 30 años, pero algunas reglas y pautas se han modificado para que el uso de Scrum sea más inclusivo y menos prescriptivo.

Esta nueva lista recoge esos cambios e intenta estar al día con la última versión de la guía. Además, incluye algunas dimensiones y capacidades que no se encuentran comúnmente en las listas de chequeo actuales, como la Alineación Organizacional, el Pensamiento Ágil, las Prácticas relacionadas o asociadas a Scrum y, principalmente, las Personas que usan Scrum o que se encuentran en el entorno de los equipos Scrum.

Entra la Nueva Lista de Chequeo de Scrum

Haz clic en la imagen para ampliarla

Así que, si estás buscando evaluar o revisar y mejorar la adopción de Scrum y las prácticas ágiles por parte de tu equipo Scrum, he creado esta lista de verificación de Scrum integral diseñada para fomentar las conversaciones de equipo y proporcionar información de expertos sobre el estado de adopción de Scrum dentro de tu equipo y organización.

Esta lista NO está destinada a evaluar el desempeño personal o a asignar culpas cuando las cosas van mal. No es una herramienta para la "Policía Scrum" o la Central de Inteligencia Ágil (CIA). En cambio, esta Scrum Checklist es un instrumento colaborativo para ayudar a los equipos a revisar su adopción actual de Scrum y la interiorización de los principios ágiles, y trazar un camino a seguir.

Usa la lista de verificación de Scrum

La Nueva Lista de Chequeo de Scrum se divide en seis dimensiones, cada una con múltiples capacidades, que cubren varios aspectos de las prácticas de Scrum y Ágil. Estas dimensiones incluyen Personas, Eventos y Artefactos + Compromisos, Producto, Prácticas Ágiles, Pensamiento Ágil y Lean, y Apoyo y Alineación Organizacional. Cada capacidad va acompañada de un conjunto de preguntas diseñadas para fomentar la reflexión del equipo y la observación experta.

Para aprovechar al máximo esta Scrum Checklist, recomiendo usarla de las siguientes maneras:

  1. Conversaciones de equipo: programa una sesión dedicada en la que todo el Scrum Team pueda discutir las preguntas de la lista de verificación. Fomenta el diálogo abierto y honesto en un entorno psicológicamente seguro, donde los miembros del equipo se sientan cómodos compartiendo sus pensamientos y experiencias.
  2. Observación de expertos: invita a una persona experta, Scrum Máster, Líder Ágil, Agile Coach o Trusted Advisor, para observar en el gemba el trabajo diario y las interacciones de tu equipo. Este experto puede proporcionar información valiosa, identificar áreas de mejora y sugerir elementos de acción basados en las dimensiones y capacidades de la lista de verificación de Scrum.
  3. Mejora continua: revisa la lista de verificación de Scrum regularmente para realizar un seguimiento del progreso y ajustar según sea necesario. Recuerda que el objetivo es mejorar continuamente tus prácticas de Scrum y tu mentalidad ágil y las de tu equipo y entorno organizacional, no lograr una puntuación perfecta en la lista de verificación.

Casi siempre es aquí donde digo y sanciono que es imposible enmarcar tu adopción o implementación de Scrum o de la cultura ágil en un número. Simplemente no lo puedes hacer.

Fomenta un enfoque colaborativo

Es fundamental recalcar que esta Scrum Checklist pretende ser un instrumento colaborativo para todo el equipo. Al fomentar una cultura de comunicación abierta y apoyo mutuo, tu equipo puede usar la lista de verificación como base para el crecimiento y la mejora continuos.

Mientras tu equipo trabaja en la lista de verificación, recuerda centrarte en los aspectos positivos de tus prácticas actuales, así como en las áreas que necesitan mejorar. Celebra los éxitos de tu equipo y utiliza los reveses como oportunidades de aprendizaje, en lugar de fuentes de culpa o crítica.

Llamado a la acción

Esta lista de verificación de Scrum es una herramienta poderosa para los equipos de Scrum que buscan evaluar y mejorar su adopción de Scrum, interiorizar y practicar los principios ágiles y refinar continuamente sus prácticas. Abordar la lista de verificación con una mentalidad colaborativa y aprovecha los conocimientos de los expertos. Así, tu equipo puede lograr un progreso significativo en su viaje Ágil.

En los próximos días publicaré algunas de las formas como he venido experimentando la lista con equipos, por ejemplo, en retrospectivas o simplemente en juegos conversacionales, reuniones semiformales y hasta casuales sobre cómo mejorar con Scrum. Pero no quiero sesgarte.

¡Comienza a usar la Scrum Checklist hoy y transforma la manera en que tu equipo aborda las prácticas de Scrum y Ágiles! Y no dejes de contarnos en el foro (sección de comentarios) sobre tus experiencias al usarla.

Puedes descargar la lista aquí 👇


miércoles, marzo 29, 2023

Las 5 disfunciones de un equipo Scrum durante la Sprint Planning

En su libro The Five Dysfunctions of a Team: A Leadership Fable, Patrick Lencioni enfatiza que es difícil “responsabilizar a algunas personas porque son muy útiles. A otras porque se ponen a la defensiva. A otras porque son intimidantes”. Y remata diciendo que no cree que sea fácil responsabilizar a nadie, ni siquiera a nuestros propios hijos.

La planificación es acerca de responsabilizarse. Cuando lo hacemos a la usanza ágil, esa responsabilidad es compartida. Y nuestro modo de pensar insiste en que cuando la responsabilidad es compartida, en efecto, todo el equipo es responsable. Dado el carácter cíclico que tiene la planificación en Scrum, es común que los equipos empiecen a manifestar ciertos trastornos, sobre todo cuando están en etapas tempranas de su desarrollo como equipos.

En la práctica son muchas más de cinco, pero he seleccionado estas cuyas secuelas pueden echar al traste cualquier esfuerzo de desarrollo de productos. Estas son las 5 disfunciones de los equipos Scrum durante la Sprint Planning y cómo superarlas.

1.   No hay un objetivo de sprint claro o no lo hay del todo

Un objetivo de sprint claro es esencial para un sprint exitoso. Proporciona dirección y enfoque para el equipo y les ayuda a ordenar el trabajo. Sin un objetivo de sprint claro, el equipo puede trabajar en tareas que no están alineadas con los objetivos generales de la iniciativa. Para superar esta disfunción, el Product Owner debe trabajar con el equipo para definir un objetivo de sprint claro antes del inicio de cada sprint.

Como Scrum Máster, asegúrate de que todos los miembros del equipo conozcan el objetivo del sprint propuesto antes del inicio de la Sprint Planning. Esto les ayudará a comprender en qué deben concentrarse durante la sesión de planificación.

2.   No están todos los que son ni son todos los que están

La Sprint Planning es un evento colaborativo que requiere la participación de todo el equipo. Si faltan algunos miembros del equipo, puede ser difícil planificar con precisión el sprint y asegurarse de que todos estén en la misma página. Si hay personas que no son del equipo se puede perder el foco con facilidad debido a la falta de conocimiento de estas personas sobre lo que el equipo viene haciendo y hacía dónde va. Para superar esta disfunción, es importante programar la Sprint Planning en un momento en el que todos puedan asistir y asegurarse de que todos entiendan la importancia de asistir. No debe haber interrupciones redundantes durante la sesión.

3.   Muy poco tiempo para el evento o el tiempo es excesivo

La Sprint Planning debe tener suficiente tiempo para permitir una discusión exhaustiva y una planificación apropiada. Sin embargo, también es importante no dedicar demasiado tiempo al evento, ya que esto puede llevar al síndrome de la parálisis por análisis y retrasar el inicio del sprint innecesariamente. Para superar esta disfunción, es importante encontrar un equilibrio entre una planificación conveniente y un uso eficiente del tiempo.

4.   No hay historias de usuario refinadas

Las historias de usuario son la columna vertebral de cualquier sprint. Proporcionan al equipo una comprensión clara de lo que debe lograrse durante el sprint. Sin historias de usuario refinadas, el equipo puede tener dificultades para comprender lo que debe hacer y puede perder tiempo en tareas que no son necesarias. Para superar esta disfunción, el Product Owner debe colaborar con el equipo para refinar las historias de usuario antes del inicio de cada sprint.

5.   No se elabora un sprint backlog apropiado

El sprint backlog es una lista de tareas que deben completarse durante el sprint. Es esencial para hacer conocer el progreso del trabajo y garantizar que todo se haga. Sin un sprint backlog adecuado, puede ser difícil para el equipo saber qué deben hacer y cuándo deben hacerlo. Para superar esta disfunción, es importante que el equipo trabaje en conjunto durante la sesión para crear una Sprint Backlog para los primeros días del sprint y una hoja de ruta que permita al equipo el logro del objetivo del sprint.

Clic en la imagen para ampliar

Ahora bien, ¿cómo puedo mejorar la Sprint Planning de mi equipo?

En el libro Scrum: epítome de experiencias detallamos varias formas de mejorar la Sprint Planning de tu equipo. Aquí hay algunas otras:

  • Asegúrate de que todos estén preparados, de que todos tengan la información y los materiales necesarios antes del inicio del evento. Esto incluye un objetivo de sprint claro, historias de usuario refinadas y cualquier otra información relevante.
  • Fomenta la participación: la Sprint Planning es un evento colaborativo y todos deben participar activamente. Anima a todos a compartir sus ideas y opiniones y asegúrate de que se escuche la voz de todos.
  • Mantén el foco en el objetivo del sprint, este debe ser la fuerza guía detrás de la Sprint Planning. Asegúrate de que todas las discusiones y decisiones estén alineadas con el objetivo del sprint.
  • Usa el tiempo de manera efectiva durante la reunión. Evita que el equipo se atasque en largas discusiones y motiva la toma de decisiones de manera rápida y eficiente.
  • Revisa y mejora: después de cada Sprint Planning, tómate un tiempo para revisar qué funcionó bien y qué podría mejorarse. Utiliza el feedback para realizar cambios y mejoras para futuras sesiones de planificación.

Y una recomendación adicional, parte de mi mantra: da un paso a la vez. Recuerda que “el trabajo en equipo comienza generando confianza. Y la única forma de hacerlo es superando nuestra necesidad de invulnerabilidad”.

domingo, enero 29, 2023

Historias de usuario basadas en hipótesis

Foto de Kaleidico en Unsplash

En general, las historias de usuario son hipótesis hasta tanto el producto resultante de aquellas se encuentre en manos de los usuarios quienes finalmente “emitirán” un veredicto al respecto. Es por ello por lo que hacemos entregas iterativas e incrementales, para poder adaptarnos a medida que esas sentencias emergen. Es posible que unas veces acertemos, pero es posible que otras veces no.

Ahora bien, el desarrollo basado en hipótesis (HDD por sus siglas de inglés de Hypothesis-Driven Development) es un método de prototipo que permite a los diseñadores de productos desarrollar, probar y elaborar un producto hasta que sea aceptable para los usuarios. Es una medida iterativa que explora los supuestos definidos durante la iniciativa e intenta validarlos con la retroalimentación de los usuarios. Y este es el principal beneficio de HDD.

También posibilita que se reduzca el tiempo y los recursos asociados con los procesos de desarrollo tradicionales. Además, la naturaleza iterativa del proceso permite una mejor comprensión de las necesidades y preferencias del usuario, lo que puede ayudar a garantizar que el producto satisfaga las necesidades del cliente.

El proceso de desarrollo basado en hipótesis incluye cinco pasos principales:

1.    Definir el problema: identificar el problema que necesita ser resuelto antes de comenzar el proceso de desarrollo.

2.    Formular la hipótesis: enunciar suposiciones e hipótesis que puedan ayudar a resolver el problema.

3.    Desarrollar un prototipo: elaborar un prototipo basado en las hipótesis formuladas.

4.    Probar el prototipo: validar el prototipo con usuarios reales y recopilar su retroalimentación.

5.    Iterar: iterar el prototipo en función de la retroalimentación y volver a probar hasta que satisfaga las necesidades del usuario.

No voy a entrar en detalles de cada uno de estos pasos del método. Lo que sí haré es ilustrarlos con un par de ejemplos antes de ir directamente al tema principal que nos convoca: las historias de usuario basadas en hipótesis.

Ejemplo 1 de HDD:

Problema: un motor de búsqueda no proporciona los resultados más precisos.

Hipótesis: Al mejorar los algoritmos utilizados para buscar, se proporcionarán resultados más precisos.

Prototipo: desarrollar un nuevo algoritmo que pueda buscar mejor a través del texto.

Prueba: hacer pruebas del nuevo algoritmo con usuarios que hayan buscado en el pasado y recopilar la retroalimentación de estos sobre la precisión de los resultados.

Iterar: tener en cuenta la retroalimentación dada para refinar el algoritmo y volver a probar hasta que los resultados sean lo suficientemente precisos para las necesidades de los usuarios.

Ejemplo 2 de HDD:

Problema: una tienda de ropa no tiene artículos para clientes de tallas grandes.

Hipótesis: al ofrecer ropa elegante y de moda para clientes de tallas grandes, la tienda atraerá a una base más grande de clientes.

Prototipo: desarrollar una línea de ropa elegante y de moda para clientes de tallas grandes.

Prueba: probar la línea de ropa con clientes de tallas grandes para obtener retroalimentación sobre el ajuste, el estilo, la calidad y el precio.

Iterar: usar la retroalimentación dada para refinar la línea de ropa y volver a probar hasta que los productos satisfagan las necesidades de los clientes.

Entran las historias de usuarios con el enfoque HDD

Historia # 1

Veamos un par de historias de usuario en la forma clásica:

Como cliente de tallas grandes,

Quiero poder encontrar ropa elegante y a la moda que me quede bien,

Para sentirme tan seguro y elegante como cualquier otra persona.

Hipótesis: al ofrecer ropa elegante y de moda para clientes de tallas grandes, la tienda de ropa atraerá a una base más grande de clientes.

Historia # 2

Como estudiante,

Quiero poder encontrar fácilmente fuentes confiables de información para fines de investigación,

De modo que pueda encontrar rápidamente respuestas precisas a mis preguntas.

Hipótesis: al mejorar los algoritmos utilizados para la búsqueda, se suministrarán resultados más confiables y precisos.

Vamos a darle un giro a estas historias de usuario con el enfoque HDD, es decir, representar la historia como una hipótesis. Para ello, usaré la forma:

Creemos que <esta capacidad>

Dará como resultado <este resultado>

Tendremos confianza para proceder cuando <veamos esta señal medible>

Historia # 1

Creemos que ofrecer ropa elegante y de moda para clientes de tallas grandes dará como resultado una base más grande de clientes para la tienda de ropa. Tendremos confianza para proceder cuando observemos un aumento de clientes en un 15 % y de ventas en un 25 %.

Criterios de aceptación:

·       La tienda debe ofrecer una gama de ropa elegante y de moda para clientes de talla grande.

·       La ropa debe quedarles bien a las clientes de talla grande.

·       La ropa debe ser de calidad superior.

·       El precio de la ropa debe ser razonable.

Historia # 2

Creemos que mejorar los algoritmos utilizados para buscar

Dará como resultado resultados más confiables y precisos.

Tendremos confianza para proceder cuando observemos una mejora en los resultados de búsqueda.

Ahora, escribe algunos Criterios de Aceptación de estas historias de usuario

Criterios de aceptación:

·       El motor de búsqueda debe ser capaz de buscar con precisión a través del texto.

·       Los resultados deben ser lo más precisos posible.

·       La búsqueda debe ser rápida y eficaz.

·       La búsqueda debe proporcionar una gama de resultados que sean relevantes para la consulta.

Ahora, veamos algunas historias de usuario con este enfoque HDD de una aplicación tipo “Netflix”:

Creemos que ofrecer recomendaciones de contenido personalizado

Dará como resultado usuarios más comprometidos.

Tendremos confianza para proceder cuando veamos un aumento del 17 % en la participación de los usuarios.

Criterios de aceptación:

·       La aplicación debe proporcionar recomendaciones de contenido personalizadas basadas en los hábitos de visualización del usuario.

·       Las recomendaciones deben ser pertinentes y precisas.

·       El usuario debe poder ver fácilmente el contenido recomendado.

 

Creemos que brindar una experiencia de visualización optimizada

Resultará en una mejor experiencia para el usuario.

Tendremos confianza para proceder cuando observemos un aumento en la satisfacción del usuario.

Criterios de aceptación:

·       La aplicación debe proporcionar una experiencia de visualización optimizada.

·       El usuario debe poder encontrar y ver contenido fácilmente.

·       El tiempo de carga debe ser rápido.

·       La interfaz de usuario debe ser intuitiva y fácil de usar.

Una breve explicación de este enfoque

HDD es una forma específica de describir historias de usuario que incluye tres elementos clave:

1.    Creemos en <esta capacidad>: este elemento describe la capacidad o función en la que se centra la historia de usuario. Define lo que la historia de usuario está tratando de lograr desde un punto de vista funcional o técnico.

2.    Dará como resultado <este resultado>: este elemento describe el resultado esperado o el beneficio de la capacidad o característica descrita en el primer elemento. Define qué problema está tratando de resolver la historia de usuario y qué valor aportará al usuario.

3.    Tendremos confianza para proceder cuando <veamos esta señal medible>: este elemento define una señal medible que indicará que se ha logrado el resultado esperado. Este es un aspecto clave de la forma HDD de representar historias de usuario, ya que garantiza que el éxito de esta se pueda medir y rastrear.

El formato HDD es una forma efectiva de escribir historias de usuario porque garantiza que cada historia de usuario está claramente definida y tiene un propósito específico. Este modelo ayuda a garantizar que todos los interesados comprendan claramente el problema que la historia de usuario intenta resolver, el resultado esperado de la solución y la señal medible que indicará el éxito. Esto puede ayudar a garantizar que el producto se entregue a tiempo, dentro del presupuesto y a satisfacción de todos los interesados y consumidores.

Algunos beneficios que he comprobado al usar este modelo incluyen:

1.    Claridad: este modelo ayuda a definir claramente el problema que la historia de usuario está tratando de resolver y el resultado esperado de la solución. Esto puede facilitar que todos los interesados y comprometidos entiendan el propósito de la historia de usuario y cómo encaja en el producto general.

2.    Alineación: al establecer claramente el problema y el resultado esperado, esta forma puede ayudar a garantizar que todos estén alineados con el objetivo de la historia de usuario. Esto puede ayudar a reducir la confusión y garantizar que todos trabajen hacia el mismo objetivo final.

3.    Medición: el modelo permite definir una señal medible que indique el éxito de la historia de usuario. Esto puede ayudar a determinar si la solución final es exitosa, es decir, la hipótesis era cierta y si se ha logrado el resultado esperado.

4.    Priorización: el modelo facilita la priorización de historias de usuarios al tener una comprensión precisa del problema y del resultado que todos quieren. Esto puede ayudar a garantizar que las historias de usuarios más importantes e impactantes se aborden primero.

5.    Comunicación: esta forma de historia de usuario proporciona una forma clara y concisa de comunicar la historia del usuario a todos los interesados, los miembros del equipo y otras personas involucradas en el desarrollo del producto. Después de todo, lo más importante siguen siendo las conversaciones que se tengan alrededor de la historia de usuario. Esta es una manera más de iniciar y mantener esas conversaciones.

Algunos ejemplos adicionales

En la forma clásica:

Como cliente,

Quiero poder pagar mis compras con mi tarjeta de crédito

Para poder tener más flexibilidad en mis pagos.

En forma de hipótesis:

Creemos que proporcionar a los clientes la capacidad de pagar sus compras con su tarjeta de crédito

Dará como resultado que los clientes tengan más flexibilidad en sus pagos.

Tendremos confianza para proceder cuando al menos el 70 % de los clientes opten por pagar con su tarjeta de crédito.

 

En la forma clásica:

Como empleado de una empresa de logística,

Quiero poder rastrear la ubicación de nuestra flota en tiempo real

Para poder tomar decisiones más informadas.

En forma de hipótesis:

Creemos que proporcionar a los empleados de la empresa de logística la capacidad de rastrear la ubicación de la flota en tiempo real

Dará como resultado que los empleados puedan tomar decisiones más informadas.

Tendremos confianza para proceder cuando al menos el 75 % de la ubicación de la flota se actualiza en tiempo real.

 

En la forma clásica:

Como empleado de recursos humanos,

Quiero gestionar las solicitudes de vacaciones de los empleados de forma automatizada

Para poder ahorrar tiempo y reducir los errores.

En forma de hipótesis:

Creemos que proporcionar la capacidad para que los empleados de RR. HH. gestionen las solicitudes de vacaciones de los empleados de manera automatizada

Dará como resultado que los empleados de RR. HH. brinden un mejor servicio a los empleados de la compañía.

Tendremos confianza para proceder cuando las solicitudes de vacaciones se gestionen en menos de 24 horas.

 

Como puedes ver, el formato clásico proporciona una descripción general de la historia del usuario. Sin embargo, en forma de hipótesis, se proporciona una vista más detallada y estructurada de la historia, con un claro énfasis en el problema, la solución y la medida de éxito.