Métricas para Product Owners

Hola a todos

Uno de roles que más cuesta entender dentro del mundo de Scrum y de los marcos ágiles es el de Product Owner (PO), pues su área de dominio se encuentra dentro del mundo del negocio y de la gestión del producto y no específicamente el mundo del desarrollo de software.

Traducido de (1)

Hoy quisiera compartir algunas métricas útiles durante:

• la construcción del producto y 
• el uso del producto, 

que ayudarán a la correcta gestión del producto por parte del PO, algunas de interés exclusivo por parte del mismo, otras serán compartidas con el equipo de desarrollo y otras áreas.

Durante la Construcción

Las métricas a continuación son tanto de interés del Product Owner como del Equipo que está construyendo el producto

• Desarrollo del producto
• Burndown Chart del Sprint
• BurnUp Release* (también puede ser útil el Bundown del Release pero sugiero el BurnUp, ustedes sacarán sus conclusiones)
• Velocidad del Equipo
• Control del LeadTime
• Flujo Acumulativo
• Deuda de Valor o Valor no Liberado (5)*
• Tiempo promedio entre liberaciones o releases
• Calidad del Producto
• Defectos encontrados en desarrollo
• Defectos encontrados después de cada liberación
• Defectos postergados para una versión futura
• Tickets de soporte por día o semana
• Deuda Técnica
• Cobertura de pruebas unitarias
• Cobertura de pruebas funcionales automatizadas

(*)Métricas de gestión exclusiva del PO

Durante el Uso

Estas métricas son de interés del PO, muy posiblemente otros equipos de trabajo en la organización le ayuden a obtener estas métricas, pero siempre será más útil no depender de otras áreas y que esta información haga parte del tablero de control del producto.

• Uso del Producto
• Tráfico
• Tasa de Retención
• Duración de la sesión
• Número de acciones del usuario por sesión
• Proporción de usuarios activos diarios / usuarios activos mensuales 
• Tráfico (fuentes de tráfico)
• Porcentaje de rebote (porcentaje de usuarios que encontraron el producto y se fueron)
• Tasa de Rotación (Clientes perdidos / Clientes totales)
• Número de sesiones por usuario
• Usuarios por función o por volúmenes de transacción (semanal, mensual)
• Desempeño del Producto en el Negocio
• Satisfacción del cliente (el NPS es una buena opción)
• Hipótesis validadas/Hipótesis planteadas
• Valor liberado (interna y externamente)
• Ingreso mensual
• ROI mensual
• Ingreso promedio del usuario (Average revenue per user -ARPU)
• Customer Lifetime Value (CLTV or LTV)
• Costo de adquisición del cliente (CAC)

Cerrando

No todas las métricas son necesarias, pero se puede ir creciendo orgánicamente sobre ellas en la medida que el producto y el entorno nos van proporcionando más información.


Hasta acá este compartir

Saludos ágiles
Jorge Abad

Notas, Comentarios, Aclaraciones y Referencias

1. Creating Success – A Guide to Product Manager KPIs.  https://www.toptal.com/product-managers/product-management/creating-success-a-guide-to-product-manager-kpis
2. Qué es el Product Owner en el marco de Scrum y cuáles son sus áreas de atención? - http://www.caminoagil.com/2019/08/13/product-onwer-cuatro-areas-atencion/
3. Five agile metrics you won't hate - https://www.atlassian.com/agile/project-management/metrics
4. 15 Key Product Management Metrics and KPIs - https://www.altexsoft.com/blog/business/15-key-product-management-metrics-and-kpis/
5. Scrum: Una herramienta para el PO, ¿cuanto costo he convertido en valor? - DEUDA DE VALOR - http://www.lecciones-aprendidas.info/2013/10/scrum-una-herramienta-para-el-po-cuanto.html

Un tip para escribir mejores OKR

Hola a todos

Hace unos días luego de un post de Nadia Zapata (1), Jose Luis Lee exponia un problema común al momento de escribir OKR (2) y que el compartía en su post (3), y es confundir un Key Result (kr) con una tarea, justo en esa misma dirección quisiera poner otro granito de arena, de algo que he compartido en otros escenarios y aporta (desde mi punto de vista) a evitar en e problema

un OKR mal planteado podría ser

Obj2. Investigar y mejorar la satisfacción del cliente (4) kr1. Superar el puntaje neto del promotor (NPS) en más de 8.0 kr2. Obtenga 1000 respuestas a la encuesta de satisfacción anual kr3. Realizar 50 entrevistas telefónicas con los mejores clientes kr4. Realizar 15 entrevistas telefónicas con clientes recientemente abandonados kr5. Presentar un plan de acción de 10 mejoras para el próximo trimestre.

Podríamos decir, que este problema se podría observar en el kr2, kr3 y kr4, pues se observan que son acciones pero tal como están redactadas no se conectan bien con el objetivo.

Una forma de evitar esto es

ver los kr como criterios de aceptación similar a como lo hacemos con las historias de usuario

De esta manera nos enfocamos en satisfacer el enunciado del objetivo (ver 5 y 6) y no caer en el error de identificar las tareas.

Basado en esta sugerencia el OKR quedaría

Obj2. Investigar y mejorar la satisfacción del cliente (4) kr1. Superar el puntaje neto del promotor (NPS) en más de 8.0 kr2. Obtenga 1000 respuestas a la encuesta de satisfacción anual y analizar y obtener cual es el pareto de las causas de insatisfacción kr3. Realizar 50 entrevistas telefónicas con los mejores clientes y obtener cual es el pareto de las causas de insatisfacción kr4. Realizar 15 entrevistas telefónicas con clientes recientemente abandonadosy obtener cual es el pareto de las causas de insatisfacción kr5. Presentar un plan de acción de 10 mejoras para el próximo trimestre.

Nota:

hasta acá este  compartir.


Saludos ágiles
Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. Diapositivas de Nadia Zapata sobre OKR compartidas en el Ágiles 2019
2. Para más información de OKR ver http://www.lecciones-aprendidas.info/2019/10/un-ejemplo-de-okr.html
3. Me equivoqué con mis ejemplos de OKRs - de Jose Luis Lee
4. tomado de https://okrexamples.co/support-customer_service-okr-examples
5. http://www.lecciones-aprendidas.info/2013/06/la-magia-de-las-historias-de-usuario.html
6. Reconozco que este ejemplo es fácil entender por las personas de tecnología que están habituadas a trabajar con las historias de usuario, pero ayuda que al momento de facilitar o explicar el concepto, identificando claramente cuando un kr tiene sabor de tarea y cuando a sí tiene sabor a resultado.
7. Porque deberíamos intentar implementar OKRs en una Transformación Agile
8. http://www.lecciones-aprendidas.info/2013/11/como-es-una-historia-de-usuario-un.html

Un ejemplo de OKR

Hola a todos

Existe muy buena literatura y post sobre los OKR (Objectives and Key Results, por sus siglas en inglés).

Si aun no te has aproximado al concepto, es una técnica de alineación organizacional y de equipos desarrollada por Intel y consiste en establecer un objetivo trimestral cualitativo, para determinar si ese objetivo trimestral se cumple o se esta cumpliendo se establecen entre tres y cinco resultados clave que muestren que ese objetivo se esta logrando.

Por ejemplo un OKR, para un Área de Servicio al Cliente, para un trimestre determinado podría ser:

Obj2: Que nuestros usuarios se sientan atendidos como en primera clase

• kr1- Obtener una mejora del NPS del área en un 40%

• kr2- Que no quede un correo pendiente por atenderse más de 2 horas hábiles

• kr3- Reducir las quejas sobre el área en un 90%

Para más detalle sobre los okr sugiero leer:

• Este excelente resumen de Cristina Cortés @cristinacortes - Un vistazo general y algo más sobre el Modelo de OKRs (clic aquí)
• Applying OKR por Dan North - https://dannorth.net/2017/05/01/applying-okrs/
• o el libro fuente -Mide lo que importa de John Doerr (link hacia amazon)

Saludos ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. Otros post recomendados
• Me equivoqué con mis ejemplos de OKRs - de Jose Luis Lee
• Porque deberíamos intentar implementar OKRs en una Transformación Agile
• Las diapositivas de Nadia Zapata sobre OKR compartidas en el Ágiles 2019

El Manifiesto Ágil está pensado para todo el Ecosistema Software

Tomada de (1)

Hola a todos

Hace poco luego del Evento del Ágiles 2019  - http://agiles2019.agiles.org/ en Rosario Argentina, espectacular por cierto (felicitaciones a los organizadores, nos hizo falta más evento, más Rosario y más Argentina), reflexionaba sobre que aspectos contemplaba el "Manifiesto por el Desarrollo Ágil de Software", el cual es la base del movimiento ágil y los marcos ágiles que han transformado al mundo.

Luego de este evento surgieron críticas  sobre la cantidad de charlas que fueron técnicas y la cantidad de charlas que no lo fueron (cosa buena la crítica  nos cuestiona y nos hace evaluar otros puntos de vista), yo estuve allí y en efecto vi que se dieron charlas de un sabor y del otro, adicional que ninguna charla se prohíbe y existe total apertura que se hable sobre lo que es importante.

Se habló de todo lo que los asistentes quisieron hablar, adicionando que no todo hace parte de la agenda, hubo muchas conversaciones en las mesas, cenas, almuerzos, grupos de a pie, en fin.

Desde mi punto de vista se cumplió el lema “MUCHAS TRIBUS, UNA MISMA AGILIDAD”

Volvamos al Manifiesto

Pero veamos que dice el manifiesto y que pistas nos da para la comunidad ágil:

Tomado de: https://agilemanifesto.org/iso/es/manifesto.html

Tomado de: agilemanifesto.org/iso/es/principles.html

Tomado de: agilemanifesto.org/iso/es/principles.html

Algunas palabras claves agrupadas del manifiesto, son las siguientes

• Conceptos claves
• Desarrollo de software
• Conversación cara a cara
• Cambio
• Ventaja Competitiva
• Trabajamos juntos
• Entorno
• Ritmo constante
• Excelencia técnica
• Buen diseño
• Simplicidad

• Artefactos
• Procesos
• Procesos ágiles
• Herramientas
• Software funcionando
• Documentación (extensiva)
• Plan
• Software de valor
• Negociación contractual
• Requisitos
• Proyecto
• Arquitecturas
• Diseños

• Roles
• Terceros
• Cliente
• Responsables de negocio
• Desarrolladores
• Equipo de desarrollo
• Promotores
• Equipos auto-organizados

De forma similar, según las referencias de como se firmó el manifiesto ágil publicadas por Alistar Cockburn .https://twitter.com/TotherAlistair, (ver imágenes a continuación), se observa que:

• Los principios 1 al 4, están inclinados a los clientes
• Los principios 5 al 8, están inclinados a los gerentes
• Los principios 9 al 12, están inclinados al equipo

Tomado de (2)

Tomado de (3)

Por lo tanto, el manifiesto se encuentra pensado en todo el ecosistema en el cual esta inmerso el desarrollo de software, no excluye a uno o a otros, invita a que trabajemos juntos de forma continua y sostenible y generemos software de valor.

No existe una preferencia, por unos y otros, se requiere de la mejor voluntad de todos los involucrados para generar resultados grandiosos.

Clientes-Gerentes-Desarrolladores nos necesitamos entre sí, y aunque existan aproximaciones Clientes-Desarrollaores, la gran cantidad de productos y proyectos del mundo requieren de gerentes, promotores para garantizar que unos y otros interactuen de forma coordinada.

Cerrando

Bienvenidos los eventos de agilidad, bienvenidas todas las personas y roles del ecosistema software, bienvenida la excelencia técnica, bienvenidos los desarrolladores, promotores, lideres, scrum masters, agile coaches, y hablemos sobre todo lo que nos interesa, duele y queremos mover y promover en el ecosistema


Nos vemos en Uruguay Agiles2020

Saludos Ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias

1. Más fotos e información de referencia en https://siamchamnankit.co.th/history-some-pictures-and-pdfs-of-the-agile-manifesto-meeting-on-2001-a33c40bcc2b
2. https://www.facebook.com/photo.php?fbid=10156214339079035&set=a.496846469034&type=3&theater
3. https://www.facebook.com/photo.php?fbid=10156214339084035&set=a.496846469034&type=3&theater

Esquema Épica - Historia de Usuario

Hola a todos

Les comparto este esquema donde se simboliza la Historia Épica  (o Feature en el Marco SAFe) vs las Historias de Usuario.

Saludos Ágiles

La frase que compartí en el pasado #Agiles2019

#LesComparto la frase que para mí sintetiza la agilidad y mi filosofía de vida, y que escribí en el muro del pasado #agiles2019

"Vamos Juntos,
cada vez mejor,
cada vez mejor"

saludos pic.twitter.com/0pqfBRU0mc

— Jorge Hernán Abad L. (@jorge_abad) October 2, 2019

Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales

Tomado de (1)

Hola a todos


En este acompañar equipos y organizaciones hacia el mindset ágil, con frecuencia he observado a Scrum Masters, e incluso Agile Coaches, ser ingenuos respecto al entorno en el que se encuentran y creer que su iniciativa, proyecto o producto ágil va a salir adelante solo con el burndown, burnup, kanban, uno que otro tablero y compartir sus pedidos de forma verbal con el o los interesados encargados de ayudar a la gestión del entorno empresarial, en efecto, esto debería ser suficiente pero la noticia cruel es que la mayoría de nuestros proyectos ágiles se desarrollan al inicio en entornos tradicionales, no amigables con el mindset ágil, por lo que  es necesario emplear herramientas de la gestión tradicional a modo de interfaz, como lo llamaría Michael Sahota (2).

Adaptado de (2)

Adaptado de (2)

Una de las herramientas que comúnmente sugiero, y bastante poderosa en entornos tradicionales es un informe semanal o quincenal con el estado de

• la gestión de riesgos
• la gestión de problemas o impedimentos

Claro, claro esto se puede gestionar con dos tableros,

o incluso con uno solo, que tenga dos carriles, unos impedimentos sean problemas a resolver lo antes posible y los riesgos sean problemas a resolver en el mediano plazo

y post-it que indiquen:

• descripción del problema o impedimento
• fecha de identificación
• persona a la que fue asignado
• días que lleva sin resolverse (pueden ser solo líneas en el post-it)

Pero un informe de carácter frecuente, con esta información con seguridad pondrá en evidencia la necesidad de gestión por parte del entorno tradicional.

Igual que un tablero, un informe frecuente también es transparencia.

Informe de Problemas o Impedimentos (3)

Informe de Riesgos(3)

como lo comparto muchas veces

"hasta que el entorno y las personas no muestren indicios de mindset ágil, deberemos interactuar con ellos con las herramientas a las que están acostumbrados y ayudarles a transitar a nuestro mindset"

Adaptado de (2)

Nota importante:
Esta misma ingenuidad la he visto en proyectos de gestión tradicional.


Bienvenidos sus comentarios

Saludos Ágiles
Jorge Abad

Notas, Comentarios, Aclaraciones y Observaciones

1. Photo on Visualhunt.com
2. Una guía de supervivencia a la adopción y transformación ágil: trabajando con cultura organizacional. Michael Sahota-  http://www.lecciones-aprendidas.info/2017/08/una-guia-de-supervivencia-la-adopcion-y.html
3. No dudo que estos reportes podrán tener más o menos información, deberán ser adaptados de acuerdo al contexto, pero recomiendo fuertemente:
• tener a alguien asignado para su resolución
• tener el tiempo de "no resolución"
• la importancia para el "proyecto"
4. Por lo general pongo "proyecto" (entre comillas) debido a que en el mundo ágil no se gestionan proyectos, sino productos.