Crear o mejorar

El Product Owner es el encargado de la gestión del Backlog del producto. Para ello, entre sus responsabilidades está la priorización de los siguientes trabajos a realizar. Estos pueden ser, entre otros, añadir nuevas funcionalidades o mejorar lo existente ¿Cómo escoger entre crear o mejorar? Sigue leyendo

En nuestros smartphones es normal recibir notificaciones cuando una aplicación o el SO tienen actualizaciones disponibles. En cada actualización, es normal encontrar un espacio donde se enumeren las características que se añaden o las correcciones sobre las que aplican. Aunque existan casos donde se limiten a escribir correcciones de errores y mejoras en la aplicación, lo ideal es que el usuario reciba la información detallada para manejar las expectativas respecto al cambio en la app.

Para crear el paquete de la actualización, como Product Owner necesitas priorizar el Backlog en función de la estrategia del producto. A tu disposición tienes un listado de funcionalidades nuevas que ofrecer a tus usuarios, pero también hay correcciones o mejoras que incluir en los sistemas y que no tienen por qué ofrecer una mejora directa a los usuarios. Para tomar una decisión deberás escuchar al equipo de desarrollo para entender los beneficios de las mejoras y así poder priorizarlas correctamente junto a las nuevas funcionalidades.

Sin embargo, ¿qué ocurre cuando la carga de nuevas funcionalidades y mejoras no está nivelada?

Más funcionalidades que mejoras
A priori esta solución debería tener a nuestros usuarios más contentos, porque incorpora funcionalidades nuevas en cada actualización. Pero, con el paso del tiempo, es muy probable que nuestra aplicación empiece a mostrar errores o problemas. Aunque hayamos construido nuestro software con mucha calidad existen imprevistos a los que el equipo de desarrollo tiene que prestar atención: actualización de librerías externas, nuevos dispositivos sobre los que desplegar el software, aumentar capacidad para soportar más usuarios… Al final el usuario acabará descontento porque tiene a su disposición un montón de funcionalidades que no funcionan o tienen muchos errores.

Más mejoras que nuevas funcionalidades
Dentro de las mejoras podemos encontrar acciones para optimizar los sistemas sobre los que se ha construido el equipo. Dedicar iteraciones a la mejora de los sistemas, puede ayudarnos a tener una base sólida sobre la que construir nuestro producto. Pero, mientras tanto, el usuario no notará grandes cambios ni obtendrá nuevas funcionalidades.

Dentro de las mejoras también hay acciones para corregir deuda técnica, es decir, solucionar problemas que se producen por no haber cuidado el desarrollo del software. Si como Product Owner comienzas a priorizar más deuda técnica que nuevas funcionalidades de nuestro producto, puede ser un indicador de que el producto no se ha ido construyendo con la calidad necesaria. Corregir este tipo de deuda es más costoso que desarrollar el software con unos estándares mayores de calidad. El esfuerzo de crear una funcionalidad con calidad, es mucho menor que aumentar la calidad de una funcionalidad que ha ido creciendo con el tiempo.

En el equilibrio está la virtud
Un Product Owner tiene que prestar atención a estos casos. En el Product Backlog no solo debes incluir las funcionalidades si no todos los trabajos que el producto necesite. Los refinamientos son un buen lugar para identificar junto al equipo de desarrollo todas las mejoras que requiere el producto. Es necesario que como dueño del producto comprendas bien el beneficio de la mejora y qué impacto puede tener en el producto, para poder priorizarla frente al resto de nuevas funcionalidades.

Una herramienta que te puede ayudar son las métricas. En uno de nuestros clientes hemos puesto al servicio de los equipos un gráfico en el que por cada iteración se identifica la cantidad de funcionalidad vs mejoras. Esta información ha servido a los equipos para iniciar conversaciones sobre cómo están construyendo su producto y qué acciones necesitan tomar para mejorar. Para completar esta información, habrás de comprobar que la satisfacción del usuario respecto del producto no disminuye al incluir las mejoras. Esto puedes hacerlo durante la review, mientras se muestra el incremento de producto a los usuarios que asisten al evento o mediante algún mecanismo de encuesta a los usuarios finales.

También te puede interesar.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

Plan para formar a Scrum Master propios de la empresa

En todo acompañamiento en la transformación a la agilidad con Scrum, llega un momento en que los Agile Coach y Scrum Master externos a la empresa deben dejar al Cliente que siga su camino. Y con garantías de que no se va a perder lo conseguido y se va a seguir fomentando la mejora continua y el customer centric.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

¿Quién debe priorizar el Product Backlog en Scrum?

Agile y Scrum nacen principalmente del mundo del Software, aunque en los últimos años se han llevado a otros ámbitos de las empresas. Scrum plantea al Product Owner como una única persona. La realidad de la empresa nos empuja a implementar algún tipo de escalado de Scrum, en el que aparecen, de una forma y otra, Product Owners de Product Owners. ¿Significa esto que se está haciendo una mala implementación de Scrum? ¿O nos estamos adaptando a las necesidades tal y como indica Agile? ¿Tiene que de verdad ser una única persona? ¿O hay otras posibilidades manteniendo la cultura Agile?

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

Lo que te estás perdiendo por hacer «tu» Scrum

¿Qué ocurre si decides utilizar sólo parte de Scrum? Dejar de usar roles, eventos o artefactos tiene sus riesgos.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

El Product Owner: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies