Cómo medir el software de trabajo entregado diferente de contar Story Points entregados en un sprint

El recuento de puntos de la historia entregado en cada Sprint (también conocido como velocidad ) es más una herramienta de planificación que un medio para medir el software en funcionamiento , y tendría cuidado de usarlo como un KPI porque podría desencadenar comportamientos disfuncionales como inflar puntos.

Software de trabajo es más que solo un recuento de puntos de historia . He visto equipos que asignan puntos a –y gastan todo el Sprint trabajando– en el trabajo, por ejemplo, análisis y diseño de requisitos, que no da como resultado un software que funcione.

No importa si el trabajo completado en Sprint se cuenta como puntos de historia , días ideales o cantidad de elementos implementados, al final de cada Sprint, el Equipo de Desarrollo debe demostrar al Propietario del Producto y a las partes interesadas que el Incremento del Producto resultante es realmente software de trabajo y es potencialmente liberable . Esto generalmente significa que más que enfocarse en la velocidad , el Equipo de Desarrollo adopta una Definición de Hecho (DoD) que reduce agresivamente las razones que impiden que la organización libere el Incremento de Producto . En otras palabras, el propietario del producto debería estar más feliz por el valor y la calidad del incremento del producto que por la velocidad del equipo de desarrollo.

En pocas palabras: los equipos tienen software de trabajo [y valioso] no cuando completan cierto número de puntos de la historia , sino cuando hacen que la liberación del software sea una decisión comercial, en lugar de una técnica.

Tal vez deberíamos dejar de andar por las ramas: la mejor medida del software de trabajo proviene de sus clientes / usuarios. Esto conduce a una variedad de posibles medidas:

Algunas entradas son negativas, otras son positivas, muchas son ambas:

  • cantidad y tamaño de defectos en el producto entregado (esta medida también podría provenir de algún equipo interno de control de calidad antes del lanzamiento)
  • quejas del cliente, o características solicitadas y cantidad de trabajo para responder a los cambios necesarios para corregir los errores o admitir nuevas características (los Story Points pueden usarse aquí, cuanto menos, mejor)
  • intervalos entre versiones entregadas por el cliente (basadas en la idea de que un software debe recopilar una cantidad crítica de mejoras antes de ser lanzado como una “nueva versión”)
  • cifras de ventas (número de unidades vendidas, precio de reventa del producto en el mercado)
  • cantidad de visitas si se trata de algún software en línea
  • valor de los conjuntos de características del producto en comparación con otros productos similares disponibles en los mercados.
  • cantidad de llamadas al servicio de asistencia sobre su producto (cuanto menos, mejor)
  • comentarios positivos / negativos
  • etc.

La idea que estoy tratando de transmitir aquí es que definir “software de trabajo” no es parte de la responsabilidad del equipo del desarrollador. Ese ni siquiera es el rol de PO. Lo que importa es el usuario final y generalmente lo expresa comprando / usando el producto.

Lamentablemente, he visto demasiadas veces que los equipos intentan entregar menos a sus clientes porque no entienden esto. El software de trabajo no se trata de obtener el mejor pulido para la función incluida, se trata de usuarios felices. A veces están listos para aceptar características básicas menos pulidas para obtener también un conjunto de características más grande. A veces prefieren menos funciones pero un producto más simple y receptivo. Pero sea cual sea la medida que elija, intente elegirla de los comentarios de los clientes.

Estoy de acuerdo con Melvin en todo lo que ha dicho. Y Christophe tiene algunas excelentes sugerencias sobre cómo determinar qué significa “trabajar” en “software de trabajo”. Esta es una gran oportunidad para que el OP consulte al equipo de marketing de la compañía para encontrar métricas de marketing / ventas apropiadas que puedan determinar cuánto valor ven los clientes en cada lanzamiento.

Por supuesto, si sus clientes están presentes en las reuniones de Sprint Review durante las cuales se demuestra el incremento del producto, su OP simplemente puede preguntar: “¿Funciona esto para usted?” Si la respuesta es “Sí”, entonces ha progresado. Esta aceptación del cliente del incremento / función demostrada puede ya ser parte de su Definición de Hecho.

¿Qué hay de los puntos de valor?

Dices que quieres medir el software de trabajo pero ¿qué significa el software de trabajo?

Si se dice que el software que resuelve un problema tal como está diseñado funciona, entonces el valor derivado por el cliente debido al uso del software debería ser un muy buen indicador del software en funcionamiento.

Si es ágil, debe tener algún contacto con sus clientes o beta o clientes potenciales, de lo contrario, solicite al propietario de su producto que sea un cliente proxy y evalúe las historias para determinar sus puntos de valor.

Aún mejor, si el software tiene un objetivo como optimizar el tiempo para cobrar, puede demostrar ciclo de efectivo más rápido o menor requerimiento de capital de trabajo, entonces debe estar en el camino correcto para medir el software de trabajo.

La idea no es obsesionarse con la cantidad de funciones, sino tratar de obtener una cuantificación del valor para su cliente.

Otra idea es preguntar o responder cuánto más se le pagaría por el software con las nuevas funciones adicionales entregadas.

¿O cómo ha mejorado la clasificación del software frente a los competidores debido a las nuevas características?

Te estás enfocando en la producción, en los puntos de la historia, cuando deberías enfocarte en cambio en el resultado, el software de trabajo, potencialmente ya enviado a tus clientes.

Y puede tomar “software de trabajo” literalmente en este contexto.

Es posible que desee realizar una encuesta rápida para verificar si también está practicando otras formas de culto de carga ágil en su organización. Puede descargar el cuestionario aquí.

Soy un gran fanático de medir el valor en lugar de cosas como los puntos de la historia. Entreno a los propietarios de productos para que coloquen valores relativos en los elementos de la cartera de pedidos de productos y vean cuánto valor logramos entregar cada sprint.

Por ejemplo, si el artículo uno vale $ 100 arbitrarios y el artículo dos tiene el doble de valor, entonces valdría $ 200. Estos valores estarían relacionados con el grado en que ayudan al propietario del producto a lograr su visión.

El desafío entonces es cuánto valor podemos obtener, no cuántos puntos de historia podemos hacer. Hay un incentivo inherentemente menor para que el propietario de un producto juegue la cifra de valor que para un equipo de desarrollo para calcular la cifra estimada.