Mostrando las entradas con la etiqueta product backlog. Mostrar todas las entradas
Mostrando las entradas con la etiqueta product backlog. Mostrar todas las entradas

lunes, septiembre 23, 2024

Priorizar vs. Ordenar el Backlog: Más Allá de la Semántica

Imagen generada por DALL-E


Hola a todos,

Durante mucho tiempo, en mis entrenamientos de Scrum, solía decir que el Product Backlog se "prioriza". Sin embargo, al analizar con más detenimiento la Guía Scrum 2020, noté que el término correcto es "ordenar". Aunque podría parecer una diferencia semántica, en realidad, tiene profundas implicaciones en la manera en que gestionamos el trabajo del equipo. Ordenar no es simplemente priorizar; es entender el contexto, los diferentes tipos de trabajo y las necesidades estratégicas del negocio para decidir el orden en el que se abordarán los ítems.

¿Qué Significa Ordenar un Backlog?

Ordenar implica más que asignar niveles de importancia o urgencia. Es un proceso que requiere una comprensión holística de todos los elementos que componen el backlog y sus interrelaciones. Veamos en qué se diferencia ordenar de priorizar:

  1. Ordenar: Organizar ítems en función de múltiples criterios como riesgo, valor, complejidad, dependencias y necesidad estratégica. Requiere un entendimiento profundo del entorno y de cómo cada ítem contribuye al objetivo general del producto.
  2. Priorizar: Asignar un nivel de importancia o urgencia a cada tarea. Este enfoque puede ser útil, pero se queda corto cuando hay múltiples dimensiones a considerar.

Un Ejemplo Cotidiano

Supongamos que tienes las siguientes tareas en un día ocupado:

  1. Preparar un informe para una reunión importante.
  2. Responder correos electrónicos pendientes.
  3. Llevar a cabo una tarea de investigación para un proyecto a largo plazo.
  4. Hacer una llamada de seguimiento a un cliente insatisfecho.
  5. Organizar tu escritorio y archivar documentos.

Si decides priorizar, podrías hacer lo siguiente:

  1. Preparar un informe para una reunión importante.
  2. Hacer una llamada de seguimiento a un cliente insatisfecho.
  3. Responder correos electrónicos pendientes.
  4. Llevar a cabo una tarea de investigación para un proyecto a largo plazo.
  5. Organizar tu escritorio y archivar documentos.

Aquí, has ordenado las tareas basándote únicamente en la importancia y urgencia. Pero, ¿qué pasa si hay dependencias o restricciones de tiempo? ¿Y si la llamada con el cliente solo puede hacerse a cierta hora? La prioridad cambia.

Si decides ordenar, podrías hacerlo así:

  1. Preparar un informe para una reunión importante.
  2. Hacer una llamada de seguimiento a un cliente insatisfecho a la hora acordada.
  3. Organizar tu escritorio mientras esperas la hora de la llamada.
  4. Responder correos electrónicos mientras esperas respuesta del informe.
  5. Llevar a cabo la investigación cuando tengas tiempo concentrado disponible.

Aquí, has tenido en cuenta no solo la importancia, sino también la disponibilidad de tiempo, las dependencias y el contexto.

Ordenar el Backlog: Un Ejercicio Complejo

Llevemos esto al mundo de Scrum. Imaginemos un backlog con los siguientes ítems:

  1. Corregir un bug crítico que afecta a muchos usuarios.
  2. Implementar una nueva funcionalidad solicitada por un cliente clave.
  3. Actualizar la documentación técnica del proyecto.
  4. Realizar pruebas de carga en el sistema.
  5. Mejorar la interfaz de usuario en la pantalla de inicio.

Priorizar el Backlog:

  1. Corregir un bug crítico (Alta prioridad por impacto).
  2. Implementar nueva funcionalidad (Importante para la satisfacción del cliente).
  3. Realizar pruebas de carga (Esencial para la estabilidad).
  4. Mejorar interfaz (Mejora la experiencia, no urgente).
  5. Actualizar documentación (Baja prioridad).

En este caso, hemos asignado prioridades basadas en urgencia e impacto. Pero, ¿qué pasa si el equipo necesita mejorar la documentación antes de implementar la nueva funcionalidad para evitar errores? La prioridad cambia.

Ordenar el Backlog:

  1. Corregir un bug crítico.
  2. Actualizar la documentación técnica (necesario para implementar correctamente la nueva funcionalidad).
  3. Implementar nueva funcionalidad.
  4. Realizar pruebas de carga después de la nueva funcionalidad.
  5. Mejorar la interfaz de usuario.

En este ejemplo, hemos considerado no solo la importancia, sino también las dependencias y el contexto. Esto es lo que realmente significa ordenar un backlog.

¿Por Qué es Importante Comprender la Diferencia?

Cuando el Product Owner ordena el backlog, no se limita a clasificar ítems por prioridad, sino que considera factores como:

  • Dependencias Técnicas y Funcionales: Un ítem podría ser más prioritario, pero si no se cumplen ciertas condiciones previas, no puede abordarse.
  • Riesgos: Un ítem con menor prioridad podría tener un riesgo elevado que lo convierta en un foco de atención temprano.
  • Impacto Estratégico: Hay ítems que, aunque no parezcan urgentes, son esenciales para el crecimiento del negocio a largo plazo.

Por lo tanto, existen varios criterios que puedes utilizar para ordenar los ítems del backlog. La elección de los criterios dependerá de los objetivos, contexto y momentos específicos. Aquí algunos de los más comunes:

  • Urgencia: Priorizar según plazos o fechas límite.
  • Importancia: Relevancia de la tarea para los objetivos a largo plazo.
  • Impacto: Qué tan significativa es la tarea en los resultados finales.
  • Complejidad: Ordenar tareas más simples antes para liberar recursos.
  • Riesgo: Considerar tareas que podrían tener consecuencias negativas significativas si no se completan a tiempo.
  • Dependencia: Priorizar tareas que desbloquearán o permitirán el progreso en otras.
  • Retorno de Inversión (ROI): Evaluar qué tareas ofrecen mayor retorno de inversión en tiempo, esfuerzo o recursos.
  • Valor percibido: Dar prioridad a las tareas que se consideran más valiosas desde una perspectiva personal o de equipo
  • Recursos disponibles: Considerar los recursos, como tiempo y presupuesto, disponibles para cada tarea. Priorizar tareas que se pueden completar con los recursos disponibles.
  • Capacidad personal: Considerar tu propia capacidad y disponibilidad para realizar las tareas. Priorizar tareas según tu habilidad y disponibilidad en un momento dado.

La combinación y ordenamiento de estos criterios o la elección de uno sobre otro dependerá de la naturaleza específica de las tareas y metas; y por lo tanto, se pueden ajustar y personalizar estos criterios según tus necesidades y circunstancias particulares.

Pasos para un Ordenamiento Efectivo del Backlog

Para realizar correctamente el ordenamiento del Product Backlog en Scrum, es fundamental seguir una secuencia estructurada que tenga en cuenta varios factores y criterios. Aquí te presento una secuencia de pasos recomendada:

1. Definir el Contexto y Objetivos del Producto

  • Antes de ordenar, asegúrate de tener claros los objetivos del producto, la visión y la estrategia general. Esto te ayudará a tomar decisiones alineadas con el valor esperado del producto.

2. Identificar los Criterios de Ordenamiento

  • Define los criterios que usarás para ordenar el backlog. Estos pueden incluir:
    • Valor de negocio: ¿Qué tanto contribuye el ítem al valor del producto?
    • Riesgo y complejidad: ¿Cuáles son los riesgos asociados al ítem? ¿Es un ítem técnicamente complejo?
    • Dependencias: ¿Existen dependencias con otros ítems o equipos?
    • Urgencia o necesidad regulatoria: ¿Existen fechas límite o requerimientos regulatorios?

3. Evaluar y Categorizar los Ítems del Backlog

  • Revisa cada ítem del backlog y asígnale una categoría basada en los criterios definidos. Por ejemplo, puedes clasificar los ítems como:
    • Bugs: Problemas críticos que afectan la experiencia del usuario.
    • Deuda técnica: Elementos que necesitan ser resueltos para mejorar la calidad del código.
    • Funcionalidades nuevas: Mejoras o nuevas capacidades del producto.
    • Requerimientos regulatorios: Obligaciones legales o normativas.

4. Considerar las Dependencias

  • Asegúrate de que los ítems con dependencias necesarias se ordenen de manera que no bloqueen el trabajo posterior. Esto es crucial para mantener el flujo de trabajo.

5. Asignar una Puntuación de Valor

  • Usa técnicas como el valor ponderado (Weighted Shortest Job First - WSJF o la relacion Valor/Duración) para asignar un puntaje a cada ítem basado en su valor relativo, el esfuerzo requerido y el impacto en la entrega del producto.

6. Organizar el Backlog en Función del Contexto

  • Con los criterios y puntajes, organiza el backlog considerando el contexto actual del proyecto. Esto puede implicar mover hacia arriba ciertos ítems que, aunque no tienen el mayor valor, desbloquean otros ítems críticos.

7. Revisar y Ajustar Regularmente

  • El Product Backlog no es estático. Revisa y ajusta el orden regularmente en las reuniones de refinamiento del backlog, o cada vez que cambien las condiciones del proyecto o del mercado.

8. Comunicar el Ordenamiento al Equipo

  • Es fundamental que el equipo de desarrollo y los stakeholders entiendan el orden del backlog y las razones detrás de él. Esto mejora la transparencia y alinea a todos en cuanto a las prioridades del producto.

9. Validar con el Equipo

  • Antes de finalizar, valida el orden del backlog con el equipo de desarrollo. Pueden surgir consideraciones técnicas o de implementación que afecten la viabilidad del orden propuesto.

10. Monitorear el Impacto y Adaptar

  • Observa cómo el ordenamiento del backlog afecta el desempeño del equipo y la entrega de valor. Ajusta el orden si es necesario para asegurar que se maximiza el valor entregado al cliente.

Este enfoque permite que el Product Owner tome decisiones informadas y estratégicas al ordenar el backlog, asegurando que el equipo trabaje en lo que realmente aporta valor y minimizando el desperdicio de tiempo y recursos.

Conclusiones

  1. No Todo Puede Ser Priorizado Igual: Un solo criterio de priorización no es suficiente, existen muchos criterios. Es necesario un enfoque integral para gestionar el backlog de manera efectiva.
  2. El Product Owner Debe Comprender el Contexto: Ordenar el backlog implica entender el entorno, las necesidades del negocio, las dependencias y riesgos de cada ítem.
  3. Evangelización sobre Ordenamiento: Tanto el equipo Scrum como la organización deben entender esta diferencia. El Scrum Master juega un papel crucial en facilitar esta comprensión hacia todos los que están impactados con el ordenamiento del Product Backlog.
  4. Aplicabilidad a Portafolios Empresariales: A nivel de portafolio, no todos los proyectos se gestionan con los mismos criterios. Algunos son estratégicos, otros operativos; ordenar significa encontrar un equilibrio que maximice el valor global (esto será material para otro artículo).

Cerrando, ordenar un backlog no es una tarea sencilla, pero es crucial para que el equipo pueda entregar el máximo valor posible. No se trata solo de qué hacer primero, sino de entender por qué y cómo hacerlo en el contexto adecuado.

Saludos ágiles,

Jorge Abad.

domingo, diciembre 04, 2022

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

---

domingo, noviembre 14, 2021

De Colección: De la Idea hasta las Historias de Usuario del Sprint Backlog - Un Ejemplo Completo

Hola a todos

Les comparto un ejemplo que desarrollé desde la Idea hasta el Sprint backlog de los primeros tres sprints. Los artefactos elaborados son;

  • Elevator Pitch (Visión)
  • Product Vision Board
  • Ideación de posibles funcionalidades
  • Asignación del valor usando la serie de Fibonacci modificada. 
  • Asignación del esfuerzo usando la serie de Fibonacci modificada
  • Uso del Modelo Kano de priorización para identificación de funcionalidades clave
  • Elaboración del User Story Map
    • Visión End-2-End
    • Cálculo de la relacion Valor / Duración de cada funcionalidad
  • Priorización de funcionalidades usando MoSCoW
  • Identificacion del Producto Minimo Viable (MVP)
    • Plan de Releases
    • Roadmap del producto
    • Explicacion del cálculo del tiempo y costo
  • Product Backlog vertical, donde cada realese esta priorizado por la relación Valor/Duración
  • División de historias de usuario de las primeras tres funcionalidades o épicas
  • Identificación de los primeros tres sprints donde la velocidad promedio del equipo es aproximadamente 20 puntos de historia por sprint.





La imagen la pueden descargar en alta resolución de:




Actualización 2022-11-10


Enlace a Mural - Clic aquí -



jueves, abril 01, 2021

Seguimiento de OKRs empleando Scrum como marco de gestión




Hola a todos

En un artículo anterior: "OKR - Pasando de la Intención a la Acción" (clic aquí),  presenté de una manera muy somera cómo se podría identificar un Product Backlog teniendo como partida unos OKR (si no lo has revisado, te invito a hacerlo), hoy con este artículo quisiera dar más claridad en los pasos a seguir de forma que Scrum nos sirva como marco de gestión y ejecución de los OKRs, adicionando que he visto funcionar exitosamente este matrimonio por más de dos años, vamos entonces:


Prerequisitos y supuestos
  • Ya tienes tus OKRs 
  • Vamos a suponer que tienes definición trimestral de los mismos
  • Ya se identificaron las metas mensuales para cada KR (key result)
  • Este ejemplo aplica cuando las personas tienen los OKR como una herramienta de transformar la ejecución de su día a día, por lo que deberán tomar una porción de su tiempo de operaciones diarias para ejecutar scrum y conformar un Scrum Team.



Paso 1: Se identifican las tareas a realizar cada mes para lograr cada meta mensual. Tienes un resultado similar al siguiente:


Paso 2: Cada KR lo asignas a un Scrum Team, con las siguientes recomendaciones:
    • Roles
      • El Product Owner, el cual es el dueño del KR
      • Los Developers encargados de ayudar a cumplir el KR y
      • El Scrum Master es encargado de facilitar los eventos de Scrum y de la mejora continua del equipo
    • Eventos
      • Sprint de dos semanas
      • Planning, Review, daily y Retrospectiva según la guía de scrum (Scrumguides.org)
    • Artefactos
      • Product Backlog: las tareas identificadas previamente, con Objetivo del Producto lograr el KR del trimestre
      • Sprint Backlog: un subconjunto de tareas seleccionadas del mes en curso. Este sprint backlog tendrá como Objetivo de Sprint un objetivo intermedio valioso o la meta propuesta para el mes en curso.
      • Increment: como resultado de las tareas finalizadas


Paso 3: Cada tarea del sprint backlog se puede descomponer en subtareas que permitan ver un progreso del equipo hacia el objetivo del sprint.

Proceso de Definición del Product Backlog y Sprint Backlog en la combinacion de Scrum y OKR

Vista general del proceso

En general el proceso se vería de la siguiente forma:

Proceso de Gestión para lograr los objetivos planteados en el Sprint

Proceso de Definición y Gestión de los OKR empleando Scrum como marco de gestión

Conclusiones, recomendaciones y comentarios finales

  • A los equipos encargados de cumplir OKRs les ha sido de gran valor emplear Scrum como marco de gestión y de ejecución. Lo he vivido en equipos de transformación y lo he visto funcionar en varias organizaciones y equipos de forma exitosa.
  • Scrum le permite a las áreas operativas adaptarse al menos cada dos semanas con miras a lograr el objetivo mensual, y cinco veces con miras al objetivo trimestral. 
  • Recomiendo que al menos mensualmente se realice una reunión de progreso, donde todos los equipos encargados de los KR reporten mutuamente su progreso y lo compartan con un nivel superior.
  • El uso de Burndown y Burnup Charts y Gráficos de control es clave para que el equipo tenga herramientas para decidir si va en la dirección correcta o no, y poder inspeccionar y adaptarse en busqueda del objetivo y sus KRs asociados.



Hasta acá este compartir. 

Saludos ágiles, Jorge Abad. 

jueves, febrero 25, 2021

Tres Ejemplos de Productos concebidos de Forma Ágil - Agile Inception

Hola a todos

A mi criterio, una de las mejores formas de aprender ciertas técnicas, a parte de experimentarlas, es viendo ejemplos, es por esto que a continuación les comparto tres casos de Agile Inception de productos digitales, el resultado final es un plan de releases del cual se pueden luego detallar las historias de usuario.

Estos ejemplos fueron desarrollados por los Estudiantes de la Cohorte 2020-Sem02 de la ESPECIALIZACIÓN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DE SOFTWARE de la Unab, a quienes tuve la oportunidad de enseñarles la Materia de Metodologías y Marcos Ágiles.

Se desarrollo un caso al cual se le identificó:

  • El Problema: qué es lo que intenta ser resuelto con el sistema
  • La Visión: Elevator pitch
  • El Vecindario: áreas y sistemas con los cuales se relacionará el sistema
  • Product Vision Board: usuarios, necesidades, productos y metricas
  • User Story Map con identificación del Producto Mínimo Viable - MVP: Épicas priorizadas con estimación de esfuerzo y asignación de valor
  • Estimación de Tiempo y Costo
  • The Go Product Roadmap: Este artefacto también puede ser conocido como el plan de releases.
  • Historias de Usuario con Criterios de Aceptación: se seleccionaron algunas épicas de forma aleatoria y se les escribieron las historias de usuario, simulando un refinamiento.

Espero estos ejemplos les sean de utilidad,

Saludos ágiles

Jorge Abad.












martes, agosto 25, 2020

Sobre el Product Backlog, Sprint Backlog y los ítems de Backlog

 

Hola a todos

La guía de Oficial de Scrum (la actual, la publicada en 2017 en https://scrumguides.org/  ), tiene una serie de definiciones sobre el Product Backlog, el Sprint Backlog y los Ítems de Backlog que comparto literalmente a continuación:


El Product Backlog es:

  • una lista ordenada de todo lo que se conoce que es necesario en el producto
  • esta compuesto por ítems de backlog
  • un artefacto vivo
  • enumera todas 
    • las características
    • funcionalidades
    • requisitos
    • mejoras
    • y correciones que constituyen cambios a realizarse sobre el producto para entregas futuras
  • varios equipos (varios Equipos Scrum trabajan juntos en el mismo producto)
    • se utiliza una única Lista de Producto para describir el trabajo a realizar


Un Ítem de Backlog:

  • Tiene como atributos
    • descripción
    • orden
    • estimación
    • y el valor
  • muchas veces incluyen descripciones de las pruebas  que demostrarán la completitud de tales elementos cuando estén “Terminados
  • varios equipos (varios Equipos Scrum trabajan juntos en el mismo producto)
      • podría emplearse un atributo de la Lista de Producto para agrupar los elemento

    Sprint Backlog contiene:

    • objetivo del sprint: es una meta establecida para el Sprint
    • el conjunto de elementos de la Lista de Producto seleccionados para el Sprint
    • incluye al menos una mejora de procesos de alta prioridad identificada en la Retrospectiva inmediatamente anterior para asegurar el mejoramiento continuo



    Hasta acá este corto compartir

    Saludos Ágiles
    Jorge Abad



    jueves, julio 02, 2020

    Un ejemplo sobre: Épicas, MVP, Historias de Usuario, Agregar Valor Incrementalmente y Agregar Valor


    Hola a todos

    Debido a recurrentes conversaciones y aclaraciones sobre:
    • Épicas
    • Historias de Usuario
    • MVP (Minimun Viable Product o Producto Mínimo Viable)
    • Agregar Valor
    • Agregar Valor Incrementalmente
    • y Scrum
    Voy a desarrollar un ejemplo hasta llegar a la planeación de los primeros tres sprints de un producto de solicitud de crédito, esto con el fin de ilustrar varios conceptos.

    Comencemos.

    Paso 1. Durante el Inception (9) se creó el siguiente User Story Map




    Paso 2. Durante el Inception (9) se realiza la estimación de cada release

    Se realiza una estimación de alto nivel y se identifica que aproximadamente (7) cada release tomará:

     Release 1 - MVP  7 sprints
     Release 2   6 sprints
     Release 3   6 sprints






    Paso 3. Inception - Durante el Inception se identifican las historias de usuario de los siguientes tres sprints (11)

    El equipo técnico luego de tener conversaciones con el PO y los Stakeholders estima que las dos primeras historias épicas son suficiente para los primeros tres sprints, quedando identificadas de la siguiente manera:


     Release  Épica  Historia de Usuario
     Release 1 - MVP Formato de solicitud básico
    • HU1 - Datos personales
    • HU2 - Datos familiares
    • HU3 - Datos laborales
    • HU4 - Referencias laborales
    • HU15-Información del cónyuge
    • HU5 - Ingresos
    • HU6 - Egresos
    • HU7 - Bienes
    • HU8 - Deudas
    • HU9 - Tipo de crédito solicitado
    • HU16 - Declaración de salud
    • HU10 - Validación rápida contra base de datos interna
    • HU11 - Validación de preaprobados
    Validar referencia personales
    • HU12 - Validar veracidad de referencias contra base de datos interna
    • HU13 - Registro de llamadas a referencias dudosas
    • HU14 - Escalar problemas a superior 
    Validación centrales de riesgo 1 y 2  Pendientes por definir (10)
    Calificación  Pendientes por definir (10)
    Creación del crédito  Pendientes por definir (10)
    Desembolso a cuenta propia  Pendientes por definir (10)


     Release Sprint  Historia de Usuario
     Release 1 - MVP Sprint 1
    • HU1 - Datos personales
    • HU2 - Datos familiares
    • HU3 - Datos laborales
    • HU4 - Referencias laborales
    • HU15-Información del cónyuge
    Sprint 2
    • HU5 - Ingresos
    • HU6 - Egresos
    • HU7 - Bienes
    • HU8 - Deudas
    • HU9 - Tipo de crédito solicitado
    • HU16 - Declaración de salud
    Sprint 3
    • HU10 - Validación rápida contra base de datos interna
    • HU11 - Validación de preaprobados
    • HU12 - Validar veracidad de referencias contra base de datos interna
    • HU13 - Registro de llamadas a referencias dudosas
    • HU14 - Escalar problemas a superior 
    Sprint 4  Pendientes por definir (10)
    Sprint 5  Pendientes por definir (10)
    Sprint 6  Pendientes por definir (10)
    Sprint 7  Pendientes por definir (10)


    Ya que llegaste hasta acá, déjame compartirte cuál es mi punto

    Realmente no es un punto, son varios, veamos:
    1. Observa que no existe relación entre la cantidad de épicas y la cantidad de sprints.
    2. El sprint backlog identificado se mantuvo entre 5 historias aproximadamente, la experiencia de varios autores sugiere que un buen Sprint Backlog debería tener entre 6 - 10 historias de usuario de similar tamaño (en la medida de lo posible), menos no es recomendable.
    3. El formulario o Épica de Solicitud de Crédito, NO ES UNA HISTORIA DE USUARIO, es una épica y el principal criterio es que un equipo se demorará más de un sprint en terminarlo (rompiendo los criterios de INVEST y CCC), por lo tanto, para ver progreso de VALOR INCREMENTAL, lo partimos en historias de usuario que nos permiten ver progreso en la construcción del formulario.
    4. Obvio, cuando se termine el sprint 1 tal vez tengamos las historias: HU1 - Datos personales, HU2 - Datos familiares, HU3 - Datos laborales, HU4 - Referencias laborales, HU5 - Ingresos; pero no tendremos nada que liberar a producción, lo que si es cierto, es que habrá sofware funcionando potencialmente liberable (o en producción apagado) esperando el resto del MVP para ser liberado cuando el PO dé la orden.
    5. El formulario o Épica de Solicitud de Crédito se terminará de construir aproxidamente en la mitad del sprint 3, como PO, ¿no prefieres ir observando progreso cada sprint? o ¿deseas luego de mes y medio (suponiendo que cada sprint fuera de 2 semanas) de estar comiendote las uñas, pensando que el equipo no te muestra avance? la verdad, creo que es mejor ver valor incremental; los PO con los que he trabajado luego de conocer el mundo del VALOR INCREMENTAL, de las pequeñas entregas, no desean volverse al anterior. Te invito a leer estos dos post respecto a la necesidad de tener historias de usuario pequeñas para poder observar progreso:
    6. Cuando se termine el formulario o Épica de Solicitud de Crédito, se le agregará VALOR al producto, pero este valor no se hará tangible hasta después que se ponga en producción. Recuerda: "el Software solo adquiere valor cuando es usado".
    7. Se dice aproximadamente, pues realmente no se sabe a ciencia cierta cuanto tiempo va a demorar en construirse cada release, lo que si sabemos es que vamos a estar priorizando por valor y tan pronto tengamos algo que genere impacto lo liberaremos.
    8. Realmente se Agregará o Generará VALOR cuando salga a producción el MVP, antes solo se genera satisfacción al PO y a los stakeholders, pues estos ven progreso. Recuerda: "el Software solo adquiere valor cuando es usado".
    9. El Inception consta de más actividades (ver un ejemplo acá -http://www.lecciones-aprendidas.info/2017/08/ejemplos-de-artefactos-agiles-inception.html )
    10. Estas historias de usuario no se escriben o refinan en el Inception, se detallarán más adelante. Se realiza en la vista del Discovery del Product Owner (ver http://www.lecciones-aprendidas.info/2020/03/product-owners-views-explicacion.html), además como estamos en un mundo tan volátil, es probable que tengan cambios en el futuro y sean fácilmente obsoletas. Recuerda, en ágil nos enfocamos mucho en no hacer activdades de desperdicio, o como dice el principio 10 del Manifiesto Ágil (clic aquí): "La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial." 
    11. Es altamente recomendado que como resultado de un Inception, se tengan las historias de usuario de los primeros tres sprints refinadas o preparadas para ser desarrolladas. Estas historias podrán tener formato o modo de representación que desees (ver http://www.lecciones-aprendidas.info/2019/05/modos-de-representacion-de-las-historias-de-usuario.html )
    12. En caso que para el PO y los stakeholders sea de valor liberar la Épica-Solicitud de Crédito (tal vez, porque les ahorra muchos procesos manuales), aunque esta no sea el MVP, pueden hacerlo, (¿quién se los impide?), y para acabar de ajustar no es necesario esperar al review del tercer sprint para ponerla activa en producción, perfectamente pueden liberarla en la mitad, no es necesario que esperen (no te lo imaginabas, ¿cierto 🤯? ). La referencia a esta práctica de liberación continua en la guía de Scrum (ver acá), es la siguiente:  "(Scrum se ha usado para) Liberar productos y mejoras tantas veces como sea posible durante el día".
    Espero te sirva este post para el desarrollo tu producto y puedas aprovechar los beneficios del desarrollo incremental.

    Hasta acá este compartir, bienvenido el feedback.

    Saludos ágiles

    Jorge Abad

    lunes, abril 06, 2020

    La Guía de Scrum 2017 - En Mapa Mental

    Hola a todos

    La Guía de Scrum, la oficial, la publicada en https://scrumguides.org/, y en su versión en español para suramérica en 2017 https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf  traducida por mi estimado amigo Lucho Salazar, es un trabajo de sus creadores Jeff Sutherland y Ken Schawber de más de 20 años sobre ella.

    Es bastante rica en conceptos, prácticas y sugerencias, fuera de ser muy, pero muy resumida.

    Muchas veces al hacer una lectura de la misma, no somos conscientes de la cantidad de información allí depositada, y como nos pasa a muchos, cada vez que vamos a buscar un concepto, nos encontramos con perlas ocultas a nuestros antiguos ojos desprevenidos (los ojos del pasado) o tal vez sin el conocimiento para entender lo allí descrito, (me decía mi amiga Paola Becerra,  el ojo ve lo que es capaz de interpretar).

    Bueno, con el fin de decodificar un poco la guía, me he animado a ponerla en formato de mapa mental.


    Mapa Mental - Capítulos
    Mapa Mental - Capítulos y Subcapítulos
    El ejercicio no fue muy estricto desde las recomendaciones para crear mapas mentales, pero si con miras a ubicar fácilmente conocimiento clave.


    Mapa Mental Completo - (lo sé, no se ve nada, pero es para que te hagas una idea de lo extenso del mapa)

    De igual forma, he marcado en color verde y con (*) el texto relevante o las perlas ocultas a mis ojos del pasado.


    Descárgalo y Úsalo

    A continuación, pongo a su disposición varios formatos de descarga y visualización

    Espero que esta decodificación les sea tan útil como lo fue para mí, en este entendimiento y reestudio de la guía.

    Disfruten las perlas (las que estan con asterisco (*) y en verde)

    Saludos ágiles

    Jorge Abad

    domingo, febrero 02, 2020

    Antipatrón: Decirle historia de usuario a lo que no lo es

    Que las historias de usuario sean de formato libre, no implica que todo requerimiento sea una historia de usuario.

    Es en serio, “las historias de usuario tienen que ser pequeñas”. (ver más - aquí - )

    Un buen tip: Que tome máximo 3 días de desarrollo, pruebas y despliegue.




    martes, septiembre 03, 2019

    Una Reflexión sobre el Costo del Retraso, DevOps y la Curva de Maersk

    Hola a todos

    Desde hace un tiempo vengo trabajando, e incluyendo en mis entrenamientos el concepto de Costo del Retraso (Cost of Delay), el cual desarrolló magistralmente Donald Reinertsen  en su libro The Principles of Product Development Flow, y una de sus frases más famosas es:





    "Si solo puede cuantificar una cosa, cuantifique el Costo del Retraso" -Donald Reinertsen

    Algunas definiciones de este concepto son:

    Costo del retraso:
    • El costo del retraso es "una forma de comunicar el impacto del tiempo en los resultados que esperamos lograr". (1)
    • "¿Cuánto nos costaría si esto se retrasara 1 mes?"(1)
      • "¿Qué valdría para nosotros si pudiéramos obtener esto 1 mes antes?"(1)
      •  ¿Cuánto dejamos de ganar si nos atrasamos un mes?
      • ¿Cuánto le cuesta a la compañía por unidad de tiempo no tener una funcionalidad liberada oportunamente?



      Y justo con esta aproximación me encontré en el reporte de DevOps elaborado por DORA en https://devops-research.com/, en este informe, se observa la gráfica elaborada en Maersk por el equipo de desarrollo de un proyecto en donde se representa el costo del retraso/semana vs la cantidad de requisitos liberados en esa unidad de tiempo (del cual se infiere el Lead Time promedio del requisito). 

      En esta gráfica se visualiza el costo del retraso generado por liberar tres requisitos por semana, sumando aproximadamente 7 millones de dólares, a liberar más de 23 requisitos en ese mismo periodo de tiempo y reduciendo este costo casi a cero.


      Esta curva es asombrosa, pues genera consciencia de varios aspectos:

      • la importancia de estar generando valor de forma continua
      • el impacto en los ingresos de la organización de una estrategia de liberación pausada o continua
      • cualquier esfuerzo de mejora en el ciclo de desarrollo de software y en su proceso de liberación, conlleva a un impacto económico que puede llegar a ser exponencial.
      • la importancia de liberar continuamente para validar hipótesis y adaptarse rápidamente al mercado.
      • la capacidad de validar hipótesis en un escenario de alto rendimiento es exponencial


      Bajo este panorama surgen varias preguntas

      • ¿Su organización mide el costo del retraso de sus proyectos?¿de uno solo? ¿de todo su portafolio?¿la PMO lo hace?
      • ¿Como sería la curva costo del retraso por semana para los requisitos de tu organización o de tu proyecto?
      • La discusión sobre si Ágil-DevOps es barato desaparece, la pregunta que aparece es 


      ¿qué tan costoso te esta saliendo no ser Ágil-DevOps (Agile-DevOps)?


      • ¿cómo será la curva en los de alto performance, es decir, Google, Facebook, Amazon, Netflix, etc?


      Hasta acá este compartir

      Saludos Ágiles


      Jorge Abad

      Referencias, Comentarios, Notas y Aclaraciones


      1. https://en.wikipedia.org/wiki/Cost_of_delay


      sábado, mayo 04, 2019

      Modos de Representación de las Historias de Usuario - Un Capítulo del Libro Historias de Usuario una Visión Pragmática



      Hola a todos

      En el pasado ScrumDay en Perú 2019, mi estimado compañero y amigo Lucho Salazar tuvo la oportunidad de presentar un poco sobre nuestra experiencia y visión sobre las historias de usuario en la charla: "Historias de usuario: todo lo que querías saber y no te atreviste a preguntar", la cual resumía algunos de los aspectos plasmados en el Libro "Historias de Usuario: Una Visión Pragmática" que publicamos en el pasado Ágiles 2018 en México. En esta presentación se toco uno de los temas que hemos observado que más genera polémica y es los diferentes modos de representación, todos creemos que el

      "yo como usuario 
      deseo esta funcionalidad 
      para este beneficio"

      es el estándar y no, no lo es, es solo una propuesta de formato hecha por Mike Cohn, en últimas lo que recomiendan muchos expertos, autores, al igual que nosotros es:

      "cualquier modo de escribir o representar las Historias de Usuario sirve, siempre y cuando el Product Owner y el Equipo de Trabajo tengan la misma imagen mental de lo que se está requiriendo construir."(1)


      Dentro de estos modos de representación Lucho y yo hemos identificado cinco modos de hacerlo, los cuales pueden ser usados de acuerdo al a madurez del Equipo y del Product Owner y del contexto en que se encuentren. A continuación presentamos un ejemplo desarrollado en el libro, y que sirve como base para esta explicación:










      Aprovecho esta oportunidad para invitarlos a compartir su conocimiento y experiencias, de esa manera todos creceremos más.


      Como siempre, bienvenida la retroalimentación.

      Saludos Ágiles

      Jorge Abad y Lucho Salazar



      Notas, Aclaraciones, Comentarios y Referencias

      1. La representación de Historias de Usuario no exime de cumplir las 3 Cs, el criterio Invest y muchas prácticas recomendadas en el libro y los post de Lucho y míos sobre este tópico:



      lunes, noviembre 12, 2018

      Algunos Tweets Importantes sobre Historias de Usuario






























      De Colección: Algunas frases que sirven para el desarrollo de productos





      domingo, agosto 12, 2018

      Un Método Adicional de División de Historias de Usuario: Criterio de Equipo o Hasta Acá Llegamos





      Hola a todos

      Existe un método adicional de división (splitting) de historias de usuario al presentado en Leído y Recomendado: División de historias de usuario -clic aquí- y es el usado por el Criterio del Equipo o al que yo llamo "Hasta acá llegamos" y la situaciones en las que he observado que se presenta son las siguientes:

      Situación 1: El equipo observa una historia de usuario muy grande

      • El Product Owner (PO) explica una historia de usuario
      • El Equipo la estima y la ve muy grande (ver post) o muy riesgosa,
      • Entre PO y Equipo se estima hasta donde llegan en esa historia (dependiendo si la dividen por valor para el Sprint o Riesgo) y si el resto será en otra historia de usuario que posiblemente se construya en este sprint o se decida realizar el siguiente.

      Situación 2: El product backlog esta casi listo y se quiere añadir una historia de usuario
      • Se tiene el sprint backlog casi listo, queda un poco de capacidad libre para una nueva historia de usuario.
      • El PO explica una historia de usuario
      • El Equipo observa que no hay capacidad para asumir esta historia de ese tamaño y las subsiguientes historias también parecen ser de tamaños similares o superiores.
      • El Equipo con el PO dividen la historia de forma que se logre incluir lo que más genera valor en el planning actual y se deja para otro sprint el resto (pero en una nueva historia).

      Espero haya sido útil este corto compartir.

      Saludos ágiles

      Jorge Abad


      Leído y Recomendado: Patrones de División de Historias de Usuario o Cómo Dividir una Historia de Usuario

      Hola a todos

      Como alguno de ustedes saben, muchas veces uso mi blog como referencia cuando comparto entrenamientos y charlas, es mi repositorio oficial en el que recopilo y comparto información, conocimiento y experiencias.

      Quiero en este post dejar referencia del interesante artículo que comparto constantemente en los entrenamientos sobre división de historias de usuario publicado en Agileforall.com.

      Espero les sea de gran utilidad como lo ha sido para mi.

      Link del post -1: How to Split a User Story - Clic aquí
      Link del post -2: New Story Splitting Resource - Clic aquí
      Link del poster en pdf en inglés: clic aquí.
      Link del poster en pdf en español:clic aquí.

      Link de backup por si los anteriores no funcionan - inglés: clic aquí.
      Link de backup por si los anteriores no funcionan - español: clic aquí.


      Saludos ágiles
      Jorge Abad

      miércoles, julio 25, 2018

      Aclarando Sobre Historias de Usuario

      Hola a todos

      Existe una página de Facebook que pone excelentes temas de cuestionamiento sobre testing llamada "Señor Tester" - clic aquí para verla -, lo cierto es que esta semana publicaron algo que comenté pues hace parte de los malentendidos relacionados con las historias de usuario.

      A continuación les comparto el post y mi respuesta



      Saludos Ágiles 
      Jorge Abad

      ------------------------

      mi respuesta fue:

      Esta es la transcripción

      genial...es lo mejor que puede suceder.. y observo varias cosas:
      • las historias de usuario no se envían, se explican en el planning
      • entre más ambiguas mejor...pues implicará que el #ProductOwner, se haga entender por todo el equipo
      • Al tester no lo estan invitando al planning mal #Agile, mal #Scrum o #FrAgile -- tiene que estar allí con todo el equipo, hace parte del equipo
      • te recomiendo este post   - Algunas Ideas Claves sobre Historias de Usuario - clic aquí..-
      • las historias de usuario NO SON ESPECIFICACIONES.. su creador argumenta que si hubiera querido que fueran especificaciones, se llamarían ESPECIFICACIONES DE USUARIO, pero se llaman historias por que deben ser contadas y explicadas
      • Al Señor Tester  le esta tocando un equipo que hace mal #Agile, mal #Scrum o #FrAgile
      un abrazo Señor Tester  y espero algún días hagas parte de un verdadero equipo ágil

      viernes, julio 21, 2017

      Algunas Ideas Claves sobre Historias de Usuario




      Hola a todos:
      Les quisiera compartir un listado de ideas centrales sobre historias de usuario que por lo regular comparto en los entrenamientos en Scrum:

      1. Las historias de usuario no son especificaciones
      2. Una historia de usuario debe ser tan pequeña que obligue a una conversación cara a cara donde todos entiendan mejor el problema (Leonardo Agudelo)
      3. Es preferible una historia de usuario ambigua que una bien escrita (la razón: la ambigua invita a la conversación) (Jeff Patton)
      4. Paremos de especificar las historias de usuario comencemos a explicarlas (Jeff Patton)
      5. Es en serio, las historias de usuario tienen que ser pequeñas (ver post aquí)
        • Una buena historia de usuario debe tomar entre 3 y 5 dias persona de esfuerzo para lograr el DONE
        • Una buena historia de usuario tiene entre 4 a 8 criterios de aceptación
      6. Lo más importante de una Historia se usuario es que sea menos importante que la conversación (Juan Pablo Bernal)
      7. Un buen sprint backlog tiene entre 6 a 10 historias de usuario (ver más acá)
      8. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante (Lucho Salazar).
      9. Es un error decir: "la historia de usuario está mal especificada", pues la historia de usuario no es una especificación, es mejor que este "mal escrita" por que invita a una conversación y una aclaración sobre la misma.
      10. Se llaman historias de usuario no "especificaciones de usuario", por lo tanto el énfasis se debe hacer en la historia que cuenta el usuario y no en lo que esta escrito o tratado de especificar.
      11. Las historias de usuario deben ser porciones funcionales end-to-end, que cuando funcionen se implementen agreguen valor, o sea, pasen exitósamente el siguiente test:
        • ¿puedo ponerla en producción?
        • ¿un usuario final puede usarla sin necesidad de algun truco o script extraño?¿es decir, se puede acceder desde la interfaz de usuario y funciona completamente?
      12. Una historia de usuario debe ser construible en su totalidad durante un sprint (incluyendo pruebas, documentación, despliegue y todo lo que este en la "Definition of Done")
      13. "Las historias de usuario son DICHAS,  no escritas." / "Key point: User Stories are TOLD, not written".(Ron Jeffries)


      Espero les sean útiles estas cortas ideas.

      Saludos Ágiles
      Jorge Abad