¿Cómo fomentar que mantengamos el foco desde el Product Backlog?

Agile promueve que los equipos se focalicen en lo más relevante en cada momento. Hoy os contamos cómo ayudar a poner foco desde el Product Backlog.

Una de las primeras cosas que enseñamos a nuestros clientes y sus equipos es a identificar qué es lo más importante para el negocio y a trabajar primero en lo que más valor aporte a la empresa y a sus clientes. Es decir, que su capacidad de generar valor esté focalizada siempre en lo más importante.

A priori puede parecer relativamente sencillo, establecemos unos buenos criterios de priorización, definimos que se considera valor, identificamos el beneficio de cada necesidad, y ordenamos nuestro Product Backlog con ellos. ¿Fácil no?

Si además utilizamos Scrum o Kanban para asegurar que se ponen en marcha eventos de planificación, ya sea una sesión periódica o continuada según vamos teniendo hueco en nuestra capacidad, debería resultar fácil que los equipos tengan foco en lo más importante en cada momento.

Si a esto le añadimos un Backlog de Portfolio ordenado por consenso con las área de negocio, como se dice de manera coloquial está chupao.

¿Cuál es la realidad?

Antes de explicarte nuestra propuesta, quiero contarte qué me he encontrado en nuestros clientes. La realidad no es tan sencilla. En la mayoría de las PYMES el área o departamento de IT, Tecnología, Software o como lo llamen, se ocupa de dar servicio a muchos “clientes” internos y externos. Las mismas personas se ocupan de evolucionar y mantener un amplia variedad de productos que cubren las necesidades dispares de los clientes de la empresa y de las áreas de negocio. No tienen un único producto que crear, no tienen foco en una necesidad; ese lujo sólo lo tienen algunos equipos y en muy pocas empresas.

La realidad es que la gran mayoría de los equipos lidian en su día a día con cambios de foco constantemente, intentando repartir su capacidad para atender a las diferentes necesidades que les llegan. Y muy probablemente, además tendrán que atender las incidencias que ocurren en el día, que como ya os contamos son interrupciones directas, y por tanto, más cambios de foco en el trabajo de los equipos.

Puedes decirme “bueno, es que no están organizados por cadenas de valor y por eso tienen este problema.” Y tienes razón, pero de nuevo, una cosa es la teoría y otra lo que es posible en cada momento. Con la transformación Agile en el largo plazo la empresa debería llegar a un modelo basado en cadenas de valor, con equipos multidisciplinares capaces de atenderlas. Pero ¿y mientras llegan a ese estado “perfecto”? ¿Y si la empresa no quiere o no ve la necesidad de llegar a ese lugar? La realidad es más tozuda que cualquiera de nosotros, y siempre se impone.

Así que tenemos a uno o varios equipos, con Product Owners (o rol similar) teniendo que atender muchas necesidades dispares, con unas personas que ven como constantemente tienen que cambiar de foco, ya no por interrupciones, si no porque el producto a construir es diferente. Personas con la sensación de estar a todo y a nada a la vez, y que se ven impactadas por el efecto de esa multitarea: Efectos de la multitarea en tu productividad.

Poner foco desde Product Backlog

Te voy a contar una propuesta para ordenar el Product Backlog, que puedes utilizar tanto en equipos Scrum como Kanban. Ya la hemos puesto en marcha en nuestros clientes, y ha mejorado la sensación de las personas de estar más focalizados. En términos más cuantitativos, se han reducido los tiempos para entregar valor y el número de fallos en el producto entregado.

Cuando utilizamos Kanban el propio método te estará llevando a poner foco, ya que busca la eficiencia de flujo; es decir, focalizar al equipo en lo que entra en el sistema para sacarlo rápido del mismo. Entra y sale lo más rápido posible. Pero, ¿Qué hago si cada token es de una necesidad diferente? Eso va a provocar que cada elemento que entre en el sistema cambie el foco del equipo.

Cuando utilizamos Scrum en la planificación del Sprint debemos establecer el objetivo del Sprint. Eso hace que el equipo ponga foco en conseguir ese objetivo durante un Sprint. Pero ¿y si tengo más de un objetivo? ¿Y si tengo que cubrir varias necesidades en el mismo Sprint? Me puedo encontrar en una situación en la que cada PBI (Product Backlog Item) cambie el foco a una necesidad diferente. Así que, ¿Cómo preparamos nuestro Product Backlog para que nos ayude a tener menos cambios de foco? Te lo cuento desde un caso real.

Agrupa por área de negocio 

En uno de nuestros clientes tenemos un Backlog de Portfolio priorizado en consenso por las áreas de negocio. Este backlog contiene Épicas con la necesidad o iniciativa de negocio, que se dividen en Features, que son PBI que se pueden construir en 2 meses (4 sprints) o menos. Bimestralmente las Features se reparten entre 3 equipos Scrum, capaces de atender cualquier necesidad cualquiera de ellos. Cada equipo Scrum divide a su vez las Features en Historias de Usuario, que son las que planifican en sus Sprints. Hasta aquí nada fuera de lo habitual.

Los Product Owners, siguiendo el objetivo de distribución del conocimiento y que cualquier equipo atiende cualquier petición, se reparten las Features atendiendo a la prioridad establecida en el portfolio. Deciden junto con todo el equipo Scrum en que Sprint lo van a entregar, usando ese mismo criterio. Dividen en historias y las planifican en cada Sprint atendiendo de nuevo a la prioridad y a cuando deben empezar para entregar a tiempo. Lo cual está alineado con la idea de ocuparse primero de lo más importante. En realidad no estaban haciendo nada “mal”.

Pero esta forma de actuar estaba teniendo una consecuencia inesperada: cambios de foco constantes dentro del Sprint. Y generando un impacto negativo en las personas. Hemos hecho varios cambios en el reparto y planificación de los PBI en cada uno de los puntos del proceso.

 

    • A nivel de Portfolio la Features se reparten agrupando las de un área de negocio en un equipo.
      • Empezamos a hacer que al menos cada equipo Scrum se focalice en 2 ó 3 áreas de negocio.
    • A nivel de planificación bimestral, se colocan las Features por Sprint tratando de agrupar las de un área de negocio en los mismos Sprint.
      • Como equipo tiene que atender diferentes áreas, por lo tanto tratamos de realizar primero todas las de un área, luego las de otro, y tener los menos cambios de foco posible dentro del bimestre.
    • A nivel de Sprint Planning, se agrupan las historias por área de negocio, realizando primero todas las de un área, luego las de otro, y así sucesivamente.
      • Promovemos que haya 1 ó 2 cambios de foco durante el Sprint en la generación de valor.
Distribución de un Backlog de Portfolio

El concepto es simple (y de sentido común), hay tantas cosas que atender que el cambio de foco es inevitable, pero lo que sí podemos hacer es mitigarlo distribuyendo y planificando en cada nivel el producto a construir, de forma que nos ayude a que el número de cambios sea menor. Buscamos un equilibrio entre lo prioritario y la eficiencia, entre las necesidades de la empresa y las necesidades de las personas.
Se puede complicar aún más cuando tenemos diferentes tecnologías conviviendo en los equipos Scrum, puesto que nos podemos encontrar con sobrecarga o falta de trabajo en una parte del equipo. Si tú objetivo es que todos estén ocupados todo el tiempo, es un problema si, pero si estás buscando eficiencia en el flujo de entrega no lo será tanto.

Consíguelo de forma sencilla

Nuestra propuesta está inicialmente pensada para nuestros Clientes, y es perfectamente reproducible en cualquier empresa con equipos que se encuentren en una situación similar. Si quieres ponerlo en marcha o tienes cualquier pregunta que hacernos sobre tu caso, sólo tienes que ponerte en contacto con nosotros, estaremos encantados de atenderte.

También te puede interesar.

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.

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.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

El Product Owner: el desconocido y olvidado

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

Monta equipos Scrum de éxito

Cómo montar equipos Scrum de éxitoYa sabes lo que es un equipo Scrum. Es hora de dar un paso adelante y entender cómo montar un equipo Scrum de éxito. ¿Qué tipo de perfiles incorporas? ¿Cómo se balancean? ¿Cuándo les incorporas? Son preguntas que probablemente te...

Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. Una buena review te ayudará en la estrategia de producto.

¿Es conveniente tener un Equipo Scrum en exclusiva para Incidencias?

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.

¿Tiene mi equipo Scrum los conocimientos necesarios para construir mi Producto?

Scrum propone que nuestros equipos tengan todos los conocimientos para generar productos que cubran nuestras necesidades. Te traigo hoy una herramienta sencilla para averiguar si tus equipos Scrum son realmente multidisciplinares.

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.

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