Los equipos de Producto generan expectativas entre los stakeholders en el proceso de delivery. Preguntas como “¿Cuándo se entregará el producto?” o “¿Cuánto costará el desarrollo de la feature?” son comunes. Aunque es difícil predecir con certeza una fecha de entrega, es esencial proporcionar visibilidad y organizarse de manera eficiente.
Prever la entrega de las features
¿Por qué es difícil predecir?
Cuando se crea un producto digital, el desarrollo de cada nueva feature es único y requiere una implementación específica. Aquí no se trata de desarrollar una pieza de un producto físico producido a gran escala, donde sería posible conocer de antemano los detalles de la producción: materiales necesarios, tiempo para producir, proceso de producción. Para cada nueva feature, el tiempo necesario para su realización solo se conocerá una vez que esta esté terminada.
La incertidumbre es un componente del desarrollo y del Product Management. Cuando preparas el backlog, manejas elementos más o menos ciertos y de diferentes tamaños. Ten en cuenta que cuanto más pequeñas sean tus Historias de Usuario, más fiables serán las predicciones. Tomemos el ejemplo de un trayecto entre tu casa y tu lugar de trabajo. Si trabajas a cinco minutos a pie de tu casa, puedes predecir fácilmente el tiempo necesario para llegar a la oficina. Por otro lado, si vives a tres paradas de metro de tu oficina, el tiempo de viaje es un poco más incierto... Finalmente, si para llegar a tu trabajo necesitas tomar dos líneas diferentes en varias paradas cada una, se vuelve casi imposible predecir con certeza el tiempo de viaje necesario. Puedes formular una hipótesis, pero los posibles contratiempos (retraso, incidente, gran afluencia) podrían retrasarlo.
Hipótesis de entrega
Como habrás entendido, es imposible evaluar con certeza la complejidad de implementación de una feature, y por lo tanto, la fecha en la que podrá ser entregada. La fecha de entrega es, por lo tanto, una hipótesis que debe ajustarse a medida que avanza el desarrollo.
Es posible que a veces tengas que enfrentarse a restricciones fuertes (evento anual, rediseño mediático de la marca, contrato ineludible), para los cuales se te pedirá que te comprometas con una fecha. Si surgen contratiempos que ponen en peligro esta fecha impuesta, puedes jugar con tres variables de ajuste:
- Retrasar el lanzamiento.
- Reducir el alcance entregando menos funcionalidades de lo previsto.
- Aumentar los costos reforzando los equipos.
Como Product Manager, debes explicar estos elementos a tus stakeholder y acordar juntos el camino a seguir.
Este artículo es un extracto del libro:
Herramientas para la previsión y planificación
Estimaciones y velocidad en Scrum
Las estimaciones
El trabajo de previsión y planificación comienza durante la presentación del backlog a los desarrolladores. La estimación de las Historias de Usuario por el equipo es el primer elemento para refinar su comprensión de la complejidad.
La estimación expresa la complejidad para realizar la Historia de Usuario y puede ser anunciada en diferentes formatos con el objetivo de constituir un referente de comparación de un elemento a otro. Generalmente se elige un tamaño en talla de camiseta (XL, L, M, S) para las Épicas o un punto de complejidad para las Historias de Usuario (siguiendo la secuencia de Fibonacci: 1, 2, 3, 5, 8, 13).
Las Historias de Usuario deben ser estimadas por el equipo de desarrollo, idealmente en grupo. Así es como se desarrolla una sesión de estimación:
1. Describes el resultado funcional esperado de cada Historia de Usuario.
2. Cada desarrollador evalúa simultáneamente la complejidad de la Historia de Usuario utilizando el referente del equipo. Si las valoraciones dadas son diferentes, se invita a los desarrolladores a dialogar y llegar a un acuerdo sobre una estimación rápidamente (limitando el tiempo de intercambio a unos minutos).
3. ¿Y si no hay consenso? ¡Se toma la estimación más alta!
Gracias a cada estimación, dispones de información adicional que enriquece tu referente, permitiéndote comparar la complejidad de los diferentes elementos del backlog.
Ten en cuenta que el tiempo dedicado a estimar no necesariamente mejora la precisión de la previsión. Como dice John Cutler, experto en Producto y coach de renombre, «En lugar de enfocarse en “mejores” estimaciones (...) concéntrese en: trabajar en partes más pequeñas, entregar frecuentemente, exponer el trabajo a usuarios/clientes más rápidamente, probar hipótesis antes, limitar dependencias, tener un código menos frágil, limitar las transferencias. Sus estimaciones mejorarán.»
La velocidad del equipo
La velocidad mide la capacidad del equipo para producir, calculada con los puntos completados en sprints anteriores. Aunque la velocidad evoluciona y mejora con el tiempo, también puede disminuir por factores como ausencias o problemas técnicos.
La velocidad es una herramienta de predicción que permite dar visibilidad al equipo y a los stakeholders. No es una herramienta de control y, al igual que con las estimaciones, siempre hay un margen de error e imprevisibilidad. Aquí hay algunas reglas a tener en cuenta para usarla adecuadamente:
- Las estimaciones no son compromisos, sino apreciaciones que permiten organizar el desarrollo.
- Cuanto más maduro y regular es un equipo, más se afinan y refuerzan estas apreciaciones como un indicador de previsibilidad.
- Comparando la estimación y la realización, se adaptan de manera empírica las previsiones futuras y se puede afinar la visibilidad.
- La velocidad no es comparable entre equipos, cada uno tiene su propio referencial de estimación.
- La velocidad no es una medida del trabajo individual, ya que la entrega de una feature puede ser asegurada por varias personas del equipo.
El lead time y el flujo en Kanban
El lead time
El lead time mide en días el tiempo total necesario para realizar un elemento del backlog, desde su creación hasta la entrega. Esto incluye el tiempo de desarrollo, pero también el tiempo de refinamiento, los tiempos de espera...
Cálculo de Lead Time
Por lo tanto, el lead time ofrece una indicación sobre el tiempo necesario para entregar una feature. Partiendo del principio de que la feature contiene 4 Historias de Usuario de tamaño equivalente y que se necesitan 3 días para validar una Historia de Usuario, se plantea la hipótesis de que son necesarios 12 días para entregar la feature.
El flujo
El flujo representa el número de elementos completados al final del proceso. Tomando lo elementos del backlog, el flujo sería el número de elementos entregados en un período dado (por ejemplo, una semana). Haciendo el ratio del número de elementos con respecto al flujo, se obtiene una estimación del tiempo necesario para entregar una feature a sus usuarios. En nuestro ejemplo de feature que contiene 4 Historias de Usuario, y considerando un flujo de 2 Historias de Usuario terminadas por semana, se cuentan dos semanas para entregar la feature.
Planificación de desarrollos
Gestionar dependencias
Identificar las dependencias entre equipos es crucial para evitar retrasos. Las dependencias surgen cuando un equipo necesita el trabajo de otro para alcanzar sus objetivos. Detectarlas temprano, durante las sesiones de refinamiento, y coordinarse con otros Product Managers es clave.
Planificación PI
La planificación PI (Product Increment Planning) es una ceremonia de planificación a gran escala. Con una duración de uno a dos días, reúne en el mismo espacio a los diferentes equipos involucrados en el desarrollo de un producto. Durante esta ceremonia, los equipos planifican los desarrollos de las próximas 8 a 12 semanas, identificando y tomando en cuenta las dependencias entre todos.
Elaborar un plan de lanzamiento
El plan de lanzamiento se utiliza para planificar el desarrollo de las funcionalidades a corto plazo, en contraste con el roadmap, que establece el ritmo de la estrategia a medio/largo plazo. Complementario al roadmap, el plan de lanzamiento debe contener:
- El nombre del lanzamiento y la fecha. Puedes indicar una fecha precisa si es fija o un horizonte de tiempo (mes, semana, etc.).
- Las funcionalidades principales incluidas en el lanzamiento.
Puedes construir tu plan de lanzamiento utilizando, por ejemplo, la plantilla Go product roadmap de Roman Pichler, autor y formador reconocido. A pesar de su nombre, que puede llevar a confusión, esta tiene la ventaja de presentar la temporalidad, el objetivo, las funcionalidades y, posiblemente, las métricas a seguir después de la puesta en producción para medir el logro del objetivo establecido.
El plan de lanzamiento sirve, ante todo, para dirigir y sincronizar al equipo alrededor del objetivo común. Al igual que las otras herramientas del equipo de Producto, se actualiza a medida que avanza el desarrollo (después de cada final de sprint o puesta en producción) para reflejar de la mejor manera la situación actual.
Nuestros consejos
-
Compara elementos del backlog entre sí para facilitar las estimaciones.
-
Educa a los stakeholders sobre la importancia de dar visibilidad sin tomar fechas como compromisos fijos.
-
Reserva capacidad para correcciones de bugs y mejoras menores en tus lanzamientos.
Para saber más: descarga nuestro libro Las Claves del Product Management
Foto de Freepik
