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

martes, agosto 07, 2018

Dos ideas sobre Agile

martes, julio 31, 2018

Datos, Hechos y Beneficios de Agile+DevOps en una Empresa Pública de Colombia

Hola a todos

Aunque cada vez es menos frecuente la incredulidad hacia Agile, siempre es bueno contar con casos de éxito y en especial con una colección de métricas capturadas en un entorno empresarial, para compartirlas con personas y empresas que se están acercando al concepto.

A continuación les comparto este Tweet de Claudia Toscano quien trabaja en área de TI de Empresas Públicas de Medellín (empresa con sede en Medellín - Colombia), con una hermosa colección de métricas como resultado de aplicar Agile y DevOps en su entorno.

Aunque parece obvio, importante resaltar que corresponden a datos de una Empresa Pública.










Nota Importante: Si como empleado público (o empleado privado) insistes en contratar proyectos de desarrollo de software en cascada (waterfall, o tradicional, es decir: una fase larga de levantamiento de requisitos, luego otra de desarrollo, luego una tortuosa de pruebas y por fin una entrega tardía y un contrato con alcance, tiempo y costo fijo) es muy probable que estés incurriendo en algo que en Colombia le llamamos Detrimento Patrimonial - es decir, estas haciendo mal uso de los recursos del Estado - o de tu organización - y estas probablemente derrochando probablemente un valor cercano al 50% del valor del contrato-, pues existen numerosos estudios que demuestran que hacer proyectos en cascada genera desperdicios en funcionalidades que no serán usadas cercanos al 50%. Anexo resultados de un estudio muy conocido "el Manifiesto del Caos  del 2013(ver Página 6)":

Te comparto algunos links que aun funcionan:

Saludos ágiles
Jorge Abad



miércoles, julio 25, 2018

[Preguntas y Respuestas] ¿En mi producto no hay un MVP de quien es la responsabilidad de que este exista?

Hola a todos

Hace poco publiqué en LinkedIn una pregunta (ver links al final):

"¿Soy #ScrumMaster y no hay un MVP (producto mínimo viable) definido para el producto de quien es la responsabilidad de que este exista? 

Del SM, muchas veces el PO es la primera vez que ejerce el rol, y de pronto ni ha sido capacitado, mi deber como sm es ser el Coach del PO y enseñarle a como ser un gran PO, priorizar el product Backlog por valor, encontar el MVP, escribir historias de usuario etc. "
en su clarificación se compartieron varios aprendizajes que han servido

  • El Scrum Master es el experto en el marco
  • El Scrum Master esel Agile Coach del Product Owner y del Equipo
  • El Scrum Master como experto y coach si observa que su Product Owner no entiende ciertos conceptos, lo formará y apoyará hasta que este se haga responsable de los mismos
  • La guía oficial -scrumguides.org - presenta al Scrum Master a estar al servicio de Product Owner de la siguiente forma:
    • Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el equipo Scrum de la mejor manera posible;
    • Encontrar técnicas para gestionar la Lista de Producto de manera efectiva;
    • Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos;
    • Entender la planificación del producto en un entorno empírico;
    • Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto para maximizar el valor;
    • Entender y practicar la agilidad; y,
    • Facilitar los eventos de Scrum según se requiera o necesite
  • Se invitaba a que los Scrum Masters fueran proactivos en vez de esperar que sus Product Owners vengan preparados y listos con todas las técnicas de facilitación y gestión de producto, los acompañaran y formaran hasta que estos fueran Product Owners Grandiosos (recomiendo este post Guía Supernumeraria para un Dueño de Producto Virtuoso - de Lucho Salazar- clic aquí-)
  • Este post tambien aplica para la pregunta: ¿En mi producto no hay un Plan de Relaeases de quien es la responsabilidad de que este exista?
  • Es probable que un producto con salidas frecuentes a producción, cada fin de sprint o varias veces durante el sprint, no requiera un plan de releases,



Bienvenido el Feedback

Saludos Ágiles
Jorge Abad




Link de la conversación en Linked in: https://www.linkedin.com/feed/update/urn:li:activity:6412122454839357440

Link de la conversación en Facebook: https://www.facebook.com/jorge.abad/posts/10160545277655788

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

Dedicación del Scrum Master y el Product Owner en el tiempo

Hola a  todos

Hace algún tiempo compartí este artículo "El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo", con su link hacia la referencia original en inglés "The goal of a Scrum Master is NOT to make herself unneeded", el punto es que noto que sigue siento cierto, la experiencia me lo sigue confirmando, pero como dato adicional quiero compartir hoy una gráfica atribuida a Mike Cohn sobre la dedicación del PO y el SM en el tiempo.



¿De qué factores corresponderá esa inflexión en la curva?
  • Del Scrum Master
  • Del Product Owner
  • De la madurez del Equipo
  • De la estabilidad del equipo
  • Del tiempo (8meses, un año, dos años)
No hay respuestas definitivas o contundentes, como siempre nos tocó recurrir a "Inspección y Adaptación"


Saludos Ágiles
Jorge Abad

martes, julio 24, 2018

Unos tweets sobre agile y management









"No se puede gestionar lo que no se ve" - Jim Benson

domingo, julio 22, 2018

Evolución (niveles, o tipos) de Product Owner

Hola a todos

Buscando una información relevante respecto al Product Owner, quisiera compartir estos niveles, tipos, evolución del PO y el beneficio que generan, que me encontré en este excelente artículo -http://roneringa.com/evolution-product-owner/ -



Saludos ágiles

Jorge Abad

martes, julio 10, 2018

Desperdicio Generado por la Pérdida de Contexto o "Switcheo" entre Proyectos

Hola a todos

Hay cosas sobre las cuales no se puede dejar de insistir, y esta es una de ellas.



La dejo por acá para que la usen de referencia.


Saludos ágiles

Jorge Abad

viernes, mayo 04, 2018

Tweet: La combinación Agile DevOps ya no es opcional

jueves, abril 19, 2018

[Scrum] Una queja común en algunos Scrum Masters: Mi Product Owner no es bueno

Hola a todos

En sesiones de mejora con Scrum Masters (SM) con frecuencia me encuentro con las siguientes quejas acerca del Product Owner (PO):

  • no tiene tiempo para el equipo
  • no escribe bien las historias de usuario 
  • no está priorizando el product backlog
  • no hay un plan de releases
  • no se tiene un Producto Mínimo Viable (MVP).
  • no se tiene una herramienta de seguimiento de releases como un Burn Up Release (por ejemplo)
  • entre otras preocupaciones
Es allí donde les solicito que me compartan que saben del rol del Scrum Master y me responden palabras más palabras menos, lo que que está a continuación (-que se interpreta en la guía oficial de Scrum- ):



Luego de esto, comienzo una ronda de preguntas y respuestas de más o menos este estilo:
  • ¿Quién es responsable de que se tengan buenas historias de usuario, el P.O., el Team o el SM? 
  • ¿Quién es el responsable de que no se tenga un buen Product Backlog, Plan de Releases, Producto Mínimo Viable (MVP), un Burn Up Release?
    • Rpta/. Pareciera que inicialmente es el PO, pero similar al punto anterior, el SM como coach del PO debe enseñarle y ayudarle a mantener los artefactos de scrum, hasta que estos sean los adecuados para construir un producto exitoso.
  • ¿y que podríamos hacer con respecto a la falta de tiempo del PO?
    • Rpta./. El SM debe buscar como lograr más tiempo de la organización para el PO - al menos medio tiempo-, o encontar la forma de que esto se resuelva con otro PO, o un PO Proxy, pero recordemos que el SM es un agente de cambio para la organización y es responsable de que la organización comprenda como funciona Scrum y los requisitos para que sea exitoso.
Es importante comprender que el Scrum Master es el responsable de Framework de Scrum, debe trabajar por su funcionamiento exitoso, que debe convertirse en Responsable en vez de Víctima,  haciendo que las cosas pasen, si su PO, equipo o algo no funciona pues debe moverse para que las cosas sucedan.

Hasta acá este corto compartir


Saludos ágiles

Jorge Abad




martes, abril 17, 2018

Tweet: Agile no gestionar por alcance sino por valor

martes, abril 03, 2018

¿Cómo desbloquear el miedo de tu cliente hacia la Agilidad? o ¿Cómo vender la Agilidad?




Hola a todos

A continuación les comparto una conversación que puede ayudar a desbloquear los miedos hacia la agilidad en tu interlocutor, ya sea PMO, Gerente, Director o Vicepresidente de IT, o alguien similar:

- [Promotor de la Agilidad]¿Cuánto del software que crees que actualmente y/o produces es usado?
- [Cliente] (Por lo general responde) entre el 50 % al 60%
- [Promotor de la Agilidad] El número generalmente es del 50% o menos (muestras como el Principio de Pareto también se cumple en Software(1)), pero que implica eso:
  • que el 50% del tiempo del ultimo año lo pudiste no haber trabajado y el resultado sería el mismo,es decir, se pudo haber trabajado 6 meses o solo medio tiempo y el resultado obtenido es el mismo.
  • al menos el 50% de tu dinero fue desperdiciado
  • que te esta pasando lo contrario a lo que querías controlar con tus contratos y fue construir lo que no era.
  • que el control predictivo no ha servido y ha generado un 50% de desperdicio (una de las razones es la inestabilidad actual de los requisitos (2))
  • que tuviste al menos 50% de reuniones innecesarias de requisitos, 50%  de software en el servidor (si no es más) que no funciona,  50% de pruebas innecesarias, 50% de reuniones de aceptación y pruebas UAT que no era necesarias.
  • que ese 50% de desperdicio es costo y tiempo de oportunidad que estas dejando de ofrecer a tus clientes externos e internos por hacer cosas que no servían.
-[Promotor de la Agilidad] por lo tanto en ágil tienes
  • Software de valor cada dos semanas 
  • Transparencia
  • Si el proveedor no da la talla, a lo sumo se perdió dos semanas o máximo un mes
  • puedes parar cuando quieras, o cuando una linea adicional de código no genere el ROI que compense su creación.
  • Llegas más rápido a la solución, no porque la gente codifique más rápido, sino porque construyen menos desperdicio, implicando llegar más pronto a la solución buscada
  • Liberas capacidad operativa que puede ser usada en innovación o en mejora operativa.
-[Promotor de la Agilidad] Si lo deseas comenzamos con un piloto pero debemos generar las condiciones que funcione la agilidad:
  • Acompañamiento en el proceso, pues no puedes gestionar ágil bajo la misma mentalidad de cascada o tradicional
  • Un Product Owner al menos un 50% del tiempo con el equipo
  • Un contrato ágil para el proveedor, o al menos tiempo y materiales.
  • Unas métricas de seguimiento ágil distintas a las de cascada
  • Un piloto con condiciones para ser exitoso (3)
  • Ambientes de desarrollo, pruebas lo más parecidos a producción y listos desde el inicio del primer sprint
  • Un equipo de desarrollo competente
  • Liberarse de los ANS o SLA, pues en Ágil no tienen mucho sentido (4)
-[Cliente] ¿Pero es que me han dicho que ágil es más costoso que cascada?
-[Promotor de la Agilidad] Pues sino te ha parecido muy costoso construir el 50% o más de software desperdicio durante los últimos años, no te va a doler hacer agilidad, además a cascada ya le has dado muchas oportunidades y en ocasiones no has ni entregado el proyecto, ¿por qué no te das el lujo de hacer bien ágil y ver que resultados obtienes?

-[Promotor de la Agilidad] ¿Cuando comenzamos?

Cerrando

La verdad no fue tanto un diálogo, fue más un monólogo, pero espero encuentres en este post elementos para ayudarte avanzar hacia la agilidad con tu interlocutor.

Bienvenido el feedback y éxitos en tu intención.

Saludos ágiles
Jorge Abad

Referencias

  1. Pareto se cumple en software, clic aquí 
  2. Los requisitos son más inestables hoy que en el pasado. clic aquí
  3. Condiciones para selección del proyecto piloto, clic aquí.
  4. Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones, clic aquí.

miércoles, marzo 28, 2018

¿Cuándo usar Ágil? o ¿Cuándo se Comienza a Generar Valor un Proyecto Ágil (4)?

Hola a todos

Hace un tiempo vi el excelente video de Agustín Villena - LKES17: Agustin Villena - Alineamiento, flujo y exploración (clic aquí) - recomiendo verlo con papel y lápiz, - por allá en el minuto 16:00-  clic aquí-, comparte la siguente gráfica de Alistair Cockburn.

Develop for business value once risks are down (1)



Donde el mensaje clave es: "Antes de comenzar a generar valor debes bajarle el riesgo a tu proyecto"

Es obvio sino tu proyecto, producto o iniciativa estará torpedeado por impedimentos, retrasos, problemas, desconocimientos, complicaciones técnicas, etc., cayendo en una zona de mucha fricción y poca velocidad en el desarrollo y en consecuencia es difícil generación de valor. Es por eso que también que dentro de las sugerencias para realizar un piloto en ágil se sugiere que la tecnología sea conocida y dominada por el equipo (2).

Ahora también,  lo presenta el articulo de Alistair (1) en el apartado "Don’t confuse knowledge acquisition with BDUF -Big Desing Up Front(3)", es probable que debas asumir una velocidad baja de tu equipo mientras logran:

  • entender mejor la arquitectura
  • resolver dependencias
  • realizar pruebas de concepto
  • comprender mejor los frameworks
Y luego de esta zona, si ganar velocidad en la zona de generación de valor.


Hasta acá este cortísimo compartir

Saludos ágiles
Jorge Abad

Referencias, Notas, Aclaraciones y Comentarios

  1. Design as Knowledge Acquisition by Alistair Cockbur - clic aquí- .
  2. Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos. - clic aquí -.
  3. Big Desing Up Front: the old habit of sitting at the desk and drawing up a big, fancy, full-scale design (BDUF = “big design up front”) (1)
  4. Cada vez más me alejo del concepto de Proyecto Ágil, podria cambiar este título por ¿Cuándo se Comienza a Generar Valor en la Construcción de un Producto de Forma Ágil?


lunes, marzo 26, 2018

Un tweet de un grande - R.I.P. Mike Beedle

viernes, marzo 02, 2018

Sobre RFP, ANS o SLA para desarrollos ágiles y otras perversiones


Hola a todos

En el medio, cuando hablamos con otros agilistas sobre la forma que las organizaciones están abordando la contratación de proyectos ágiles nos encontramos con RFP (Request For Proposal - Solicitudes de Propuesta) donde existen cláusulas, penalidades y ANS (acuerdos de niveles de servicio) como:
  • El equipo deberá mejorar un 1% cada sprint su velocidad 
  • Ganará el RFP el proveedor que proponga el menor tamaño de sprint 
  • Ganará el RFP  el proveedor que proponga menos sprints
  • Ganará el RFP el que haga historias de usuario en menos tiempo
Lo cierto es que venimos acostumbrados a penalizaciones y a la desconfianza de cascada, (-obvio nadie salía ganando, el producto no era el esperado, al igual que la fecha y el costo no se cumplían, es un caos por donde se mire -), en donde se generaban clausulas como:
  • deberá reducir el porcentaje de defectos proporcionalmente en sus requerimientos
  • por día de demora en la fecha de entrega deberá pagar $/día (y he visto proyectos donde la suma de la penalidad es tal que el proyecto termina valiendo cero pesos)
  • Por cada error en producción se descontará $xx.xxx.xxx
  • entre muchas otras cosas igual o peor de dolorosas donde el proveedor se acomodaba (cobrando más costoso - en el mejor de los casos-, o más barato) pues le interesaba conservar el cliente.(ver este post ¿Compras / vendes /licitas proyectos problemáticos de software? – Un pequeño deja vu - clic aquí)

Por lo tanto, es probable que quien este al frente de contrataciones de proyectos ágiles
  • Esté mal asesorado
  • No tiene conocimiento o entendimiento de ágil -no tiene que tenerlo, en algún momento yo no lo tuve- y en su buena voluntad cree que poniendo restricciones similares a la de cascada podrá "controlar" el proyecto (cosa que tampoco ocurría en cascada - pero que será artículo de otro post- ).

Lo que se observa en este caso es que se esta tratando de resolver un problema nuevo bajo un paradigma mental anterior y que no aplica para este nuevo contexto, y es allí donde se requiere de buen acompañamiento.

Dado lo anterior, cuales serían mis observaciones al clausulado del principio del artículo.

Clausula o ANS propuestoObservaciones

  • el equipo deberá mejorar un 1% cada sprint su velocidad 
  • Implica que la mejora un año deberá mejorar 48% (y eso que no apliqué la formula del interés compuesto) más de alcance al final del año si consideramos sprints de dos semanas(y en dos años del 96%). esto es insostenible,
  • Lo que va a lograr es que las historias de usuario cada vez le pongan más tamaño. (obtienes lo que mides)
  • O si se le hace auditoría las estimaciones de las historias de usuario (que es lo que menos valor genera, auditar estimaciones) terminará agotando al proveedor y dejará de ser negocio para el proveedor continuar con ese cliente pues no es rentable, ni demostrable ese ritmo sostenido de mejora.

  • Ganará el RFP el proveedor que proponga el menor tamaño de Sprint
  • El tamaño del sprint no implica absolutamente nada, se recomienda 2 semanas, equipos con mucha experiencia tienen sprints de 1 semana, y otros trabajan con kanban, pero es el contexto el que da el tamaño del sprint.
  • Es mu probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas partes que ágil no sirve.

  • Ganará el RFP  el proveedor que proponga menos sprints
  • Es una orientación puramente hacia cascada y creer que se puede definir el alcance a priori en agile (aun en cascada) es falso. 
  • Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve

  • Ganará el RFP el que haga historias de usuario en menos tiempo
  • Las historias de usuario son irregulares, aunque se puede hacer partición de ellas no es posible garantizar un tamaño, y aunque se desarrolle más rápido algunas no es garantía de que todas van a ser así.
  • Similar al anterior, es muy probable que el empleador termine trabajando con un proveedor que no entienda de ágil, no se generen valor mutuamente y crean ambas que ágil no sirve


¿Cómo resolver esto?

  • Opción 1: Prueba de Concepto

Una posible forma de saber con que proveedor quedarse es darle la oportunidad de ejecutarun proyecto en ágil , que ejecute varios sprints (2, 3, o 4 sprints)y si:

  • tiene buen manejo de la metodología
  • si equipo esta preparado y experimentado
  • tiene gestión de la deuda técnica
  • tiene prácticas técnicas
  • su scrum master es preparado y con experiencia
  • entregan software funcionando cada dos semanas
Continuar con el, sino detenerse y entregarle el proyecto otro proveedor.

¿Pero perdiste como cliente? No, ganaste conocimiento y al menos quedaste con software funcionando (cosa que no quedaba en cascada).

  • Opción 2: Referencias

Otra opción es visitar referencias de clientes de ese proveedor y validar con un experto en ágil las experiencias y aplique las mismas condiciones de la opción 1, sino funciona terminar el contrato.


Lecturas Recomendadas

Recomiendo para la mejor comprensión y ayuda estos dos post

Bienvenido el feedback


Saludos ágiles
Jorge Abad

miércoles, febrero 28, 2018

jueves, febrero 01, 2018

Unas notas sobre las preguntas

Por sus preguntas los conocereis
....
Las preguntas correctas nos llevan a la experimentación y al conocimiento
...
El cambio comienza con una pregunta
...
Sino te deja dormir, ten la seguridad que es la pregunta correcta

domingo, enero 28, 2018

Las métricas en contra del sistema

Algunos pensamientos sobre métricas, procesos y documentación

Hola a todos

Dejo por acá estos pensamientos que me dan vueltas

Sobre las métricas

  • Deben trabajar para mi y no al revés
  • deben buscar abundancia y no escasez, es decir, me ayudan a mejorar y dar salud a mi entorno, no son para generar presión y desgaste de los involucrados
  • Pocas métricas es mejor que muchas métricas

Sobre los métodos, procesos y mejora continua
  • Deben trabajar para mi y no yo para ellos
  • Los métodos, frameworks y procesos serán útiles hasta que se encuentre una mejor forma de hacer las cosas
  • la mejora continua debe llevarme tan lejos como yo lo visione
  • la vigilancia tecnológica es necesario para alimentar la mejora continua y saber referentes
  • los experimentos son claves para avanzar en la mejora continua
Sobre la documentación
  • La documentación trabaja para mí
  • Se documenta lo que genera valor

miércoles, enero 17, 2018

Una excelente definición de Valor

domingo, enero 14, 2018

Encontrando el MVP con un Roadmap y el Mapa de Afinidad

Hola a todos

Realizando talleres Producto Mínimo Viable - MVP (Minimun Viable Product), he encontrado que para cierto tipo de equipos les da dificultad emplear la técnica del User Story Map de Jeff Patton, para estos equipos he ideado esta técnica basada en el Roadmap y el Mapa de Afinidad, espero les guste y también les sirva con sus equipos.

Saludos Ágiles

Bienvenido el Feedback
Jorge H. Abad L.

sábado, enero 13, 2018

Unos tips y preguntas poderosas para encontrar el MVP


A continuación a compartir algunos tips y preguntas que hemos encontrado con varios Agile Coaches (Lucho Salazar @LuchoSalazarC, Pablo Mejía  @pmejia73) que te pueden ayudar a en
  • Siempre busque paretos, cual es el 20% del sistema que generaría un 80% de valor o impacto en el negocio.
  • Identifique cuál o cuáles son los criterios claves para la selección del MVP (4)
  • ¿Si me voy del proyecto qué es lo mínimo que quiero dejarle?
  • si es una migración o reconstrucción de un sistema
    •  ¿cuales son las funcionalidades que registran más uso del sistema? 
    • ¿agrega valor volver a construir lo que se dejó de usar o lo que nunca se ha usado?
  • Imagine el dinero es suyo, o que le darán un premio por invertir la menor cantidad de dinero
  • ¿Cual es la mínima funcionalidad que comienza a resolver el problema de negocio?
  • ¿Y si le recortaran el dinero al proyecto a la mitad?¿y la mitad de esa mitad?
    • ¿que sería lo mínimo que usted podría dejarle al proyecto si quiere dejar una gran impresión pero tiene esta restricción de dinero?
  • ¿Y si le recortaran el tiempo al proyecto a la mitad?¿y la mitad de esa mitad?
    • ¿que sería lo mínimo que usted podría dejarle al proyecto si quiere dejar una gran impresión pero tiene esta restricción de tiempo?


Hasta acá este pequeño compartir
Bienvenido el feedback


Saludos Ágiles
Jorge Abad


Notas, Referencias, Comentarios, Aclaraciones


  1. Minimísimo Producto Viable - PRAGMA - Pablo Mejía - Mínimo producto viable - ágil - https://es.slideshare.net/PabloMejaArbelez/minimisimo-producto-viable-pragma-pablo-meja
  2. How to Split a User Story - http://agileforall.com/resources/how-to-split-a-user-story/
  3. Sí, Mínimo Producto Viable ¿Pero en qué contexto? - http://www.lecciones-aprendidas.info/2016/10/si-minimo-producto-viable-pero-en-que.html
  4. Criterios de Selección del Mínimo Producto Viable - http://www.lecciones-aprendidas.info/2018/01/criterios-de-seleccion-del-minimo-producto-viable.html

Criterios o Patrones de Selección del Mínimo Producto Viable



Muchas veces elegir o encontrar el Mínimo Producto Viable (MVP - Minimun Viable Product) no es un ejercicio fácil para el Dueño del Producto y sus interesados (o stakeholders), en ocasiones se deben revisar criterios de negocio, criterios técnicos, o tal vez se requiera de un análisis multi-objetivo que ayude a determinar cual es el valor que se quiere entregar en la primera versión del producto. A continuación les comparto algunos criterios:

  1. Validar una hipótesis de negocio con el mercado. Es la común para las startups, buscando obtener el máximo aprendizaje.
  2. Validar un pedazo riesgoso de una solución
  3. Primero lo más barato
  4. Lo que menos cuesta
  5. Lo que implique el mayor ahorro en el proceso
  6. Primero una una tecnología específica y luego el resto, ejemplo primero construir la solución para Android y luego para iPhone
  7. Automatizar una parte del proceso y luego el resto
  8. Lo que me comience a resolver el problema de negocio más rápidamente
  9. Primero ciertos roles claves y luego otros
  10. Las reglas de negocio de mayor impacto primero y luego las otras
  11. Primero el camino feliz y luego las excepciones
  12. Construir para una segmentación de datos y luego para los otros, ejemplos: compradores frecuentes y luego compradores de ciertos productos.
  13. La operación del sistema que me permita obtener mayor valor
  14. (Si el criterio es performance) Primero construir la solución con desempeño normal y luego llevarla al alto desempeño
  15. Eliminando el riesgo regulatorio o minimizando su impacto
  16. Minimizar multas o sanciones
  17. Lo que más ingresos me produzca
  18. Lo que mínimo que me permita igualar uno o varios servicios de mi competencia.
  19. En una migración: lo más usado y luego lo menos



Hasta acá este pequeño compartir, si encuentran más criterios no dudes en hacer su aporte en la zona de comentarios, los citaré respectivamente.

Bienvenido el feedback

Saludos Ágiles
Jorge Abad




Notas, Referencias, Comentarios, Aclaraciones


  1. Minimísimo Producto Viable - PRAGMA - Pablo Mejía - Mínimo producto viable - ágil - https://es.slideshare.net/PabloMejaArbelez/minimisimo-producto-viable-pragma-pablo-meja
  2. How to Split a User Story - http://agileforall.com/resources/how-to-split-a-user-story/
  3. Sí, Mínimo Producto Viable ¿Pero en qué contexto? - http://www.lecciones-aprendidas.info/2016/10/si-minimo-producto-viable-pero-en-que.html