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.

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

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.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

¿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?

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

Multiplica los resultados de tu Sprint Planning

Hoy es día de Sprint Planning. Miras hacia tu equipo y… sólo ves pacas de paja rodar de un lado a otro. ¿Qué ha pasado con tus compañeros? ¿Dónde se esconderán? ¡Te han dejado solo! Te traigo 5 consejos para multiplicar los resultados de tu Sprint Planning.

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

Mi estrategia de Onboarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo??

Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

Definition of Ready y Definition of Done

¿Qué necesitas para poder comenzar una tarea? ¿Cuándo podemos dar una tarea por terminada? Para resolver estas dudas, en este vídeo te traemos el Definition of Ready y el Definition of Done

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

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

ACEPTAR
Aviso de cookies