Prepárate para la negociación de la próxima release!

 

En cada nuevo release, existe un proceso de negociación extremadamente importante y complejo, que debe ser factual, considerar dependencias, anticipando riesgos, considerando las preocupaciones y objetivos del Product Owner, incluir los requisitos no funcionales (por ejemplo, pruebas u otros requisitos de calidad seguridad, rendimiento, etc.). En un proceso de negociación de release estaremos esencialmente haciendo coincidir expectativas con capacidad de producción, desafiando el grado de previsibilidad del equipo de desarrollo. ¿Debe considerar sólo su Minimum Possible Product (MPP)? ¿Cómo puede evitar emociones en este proceso de negociación y planificación de release?

En el caso de que se trate de un problema,

Pero me gustaría volver a estos conceptos para compartir algunas reflexiones y técnicas de facilitación del proceso de planificación de release, haciéndolo más eficiente.

Mi sugerencia de proceso de negociación de release pasa por 3 fases:

Fase 1- Cuando el Product Owner expresa su ambición

El Product Owner expresa su ambición a través de una lista de características deseables para el release a comenzar la negociación. Si es un producto completamente nuevo, le llamamos normalmente MVP.

Fase 2 – La primera estimación por parte de Dev Team

Esta es una tarea hecha en conjunto con Scrum Master (si la metodología de desarrollo utilizada es Scrum) o con el Delivery Manager (si hacemos Kanban). Durante este proceso, el equipo de desarrollo o el equipo de devolución del equipo estimar el esfuerzo para implementar la lista de deseos del Product Owner. Este proceso se deriva como un normal proceso de refinamiento de historias, según mi experiencia. Personalmente recomiendo también que se estimen las historias a través de story points, combinando complejidad y esfuerzo.

Suponiendo que nuestro MVP es igual a nuestro MPP, entonces rápidamente se asume que el riesgo es reducido y el equipo puede comprometerse. Pero hacer esta asunción, si aún no se consideraron dependencias puede ser arriesgado, pues dependencias llevar considerable capacidad al equipo, para resolverlas o por bloquear partes del desarrollo.

Si no estime regularmente dependencias, su capacidad no reflejará este esfuerzo y tendrá un MPP más grande que el real.

Si usted no considera dependencias regularmente en la estimación de sus historias, le recomiendo que lo haga a un nivel más alto, a nivel de los epics, lo importante es que no deje de reservar capacidad para ellas.

En esta fase, quisiera dejar algunas consideraciones sobre:

– Unidad métrica de estimación – si suele estimarse en Story points, por favor, mantenga la misma unidad métrica durante la estimación de la nueva versión.

También puede utilizar el método de tamaño de camiseta, pero obtendrá resultados más fiables si sabe, en promedio, el valor de los puntos de referencia para cada tamaño de las camisetas: XS, S, M, L, XL. Si usted no sabe cuánto vale en los puntos de puntuación cada tamaño, cambiar entre las unidades de estimación no le ayudará a obtener resultados más precisos.

– Considere el esfuerzo para implementar las historias no funcionales – Recuerde que la mayoría de los Product Owners no son conscientes de las historias no funcionales que son obligatorias para la implementación del producto, las operaciones, el mantenimiento, el rendimiento, la calidad y la seguridad. Estas historias forman parte de las preocupaciones de Dev Team o Scrum Master y normalmente son ellos quienes reservan capacidad.

– Capacidad de las historias que forman parte de las obligaciones legales.

Estoy seguro de que si usted hace este ejercicio correctamente, probablemente se dará cuenta de que su MPP inicial se reducirá. Usted debe estar listo y apoyado por hechos en este proceso de negociación y conocer la real capacidad del equipo, sólo así, dentro del tiempo de la release, implantar el valor más alto para el producto.




Fase 3- El proceso de negociación entre Product Owner y Dev Team

Yo recomiendo para iniciar este proceso de negociación tratando de entender el valor individual de cada Epic para el producto o para el release.

Preguntas como:

  • Cuál es la diferenciación competitiva que el Epic detrás para el producto?
  • Nuestros competidores ya tienen esta funcionalidad?
  • Nuestros procesos internos o productividad están siendo afectados?

 

Explique al Product Owner cómo estima su esfuerzo en Story points. Él debe saber lo que traduce de Story Point.

Intente completar esta matriz junto con su Product Owner, Dev Team y Scrum Master:

 

En el eje del x usted tendrá su esfuerzo de implementación en Story Point (obtenido durante la fase 2), en y usted va a distribuir el valor relativo que cada Epic aporta al producto para su lanzamiento o release.

Este valor relativo, normalmente es dado por el Product Owner. Puede expresar también su prioridad e importancia para el negocio. Dependiendo del posicionamiento de los Epics en la matriz, debemos decidir:

  • Go / Avanzar – ya que hay un bajo esfuerzo de implementación y un alto valor para el producto / Release
  • Investigar – alto esfuerzo de implementación y alto valor para el producto / Release
  • Quick Wins – bajo esfuerzo de implementación y bajo valor para el producto / Release
  • y en el go! O No implementar – Alto esfuerzo de implementación y bajo valor para el producto / Release

Tenga en cuenta que usted debe considerar las historias de implementación para cumplir con las obligaciones legales, bloqueando la capacidad necesaria para hacerlo.
Otro consejo es no comenzar inmediatamente todos los Epics posibles pues tener muchas actividades en paralelo no son eficientes, reduciendo la productividad. Sólo debemos comenzar el desarrollo cuando tenemos ciertos presupuestos y recursos disponibles.

 

 




Dejar una respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.