×
×

El Refinamiento del Backlog en Scrum, a fondo

 Introducción

Este artículo pretende describir el refinamiento con detalle, destacando los diferentes estilos y prácticas con los que se puede llevar a cabo, y aclarando dudas y mitos frecuentes sobre éste. Mi filosofía de Scrum es de un marco de trabaj abierto, que debe adaptarse y que obliga a sus usuarios a pensar como optimizarlo, al contrario de un libro de reglas cerrado que debe seguirse sin entenderse. Este enfoque se extiende al Refinamiento.

Es importante tener en cuenta que el Refinamiento del Backlog de Producto (PBR en inglés) se puede realizar de muchas maneras, en función de los diferentes contextos en los que se use Scrum, como p.e.:

  • Desarrollos pequeños o enormes.
  • Produtos más conocidos a priori o realmente inciertos.
  • Equipos pequeños o múltiples equipos trabajando en paralelo.
  • Product Owners técnicos y dedicados, o Product Owners con perfil más estratégico y de negocio.

 

 

 El refinamiento es un proceso, no un evento

Según la Scrum Guide, el Refinamiento es:

El refinamiento del Product Backlog es el acto de añadir detalle, estimaciones y orden a los ítems del Product Backlog. Este es un proceso contínuo en el que el product Owner y el Development Team colaboran en los detalles de los ítems del Product Backlog.

A diferencia de los eventos del Sprint, que tienen pautada el momento del Sprint en el que ocurren, su asistencia y elementos que se inspeccionan y adaptan, el refinamiento es una actividad de soporte no obligatoria en Scrum y que no prescribe ninguno de estas características que tienen los eventos, razón por la cual no es un evento.

 

 ¿Qué se hace en el refinamiento?

Como define Scrum, en el Refinamiento se trabaja en dar detalle a los ítems del Product Backlog que se realizarán en los próximos Sprints, habitualmente entre los Sprints N+1 y N+3, realizándose en el Sprint actual (N). Para dar detalle se realizan múltiples actividades como:

  • Entender el alcance de los ítems (p.e. características o requisitos a incorporar al producto).
  • Identificar las dependencias funcionales y técnicas entre ítems.
  • Analizar funcionalmente los ítems, usualmente considerando dichas dependencias.
  • Diseñar técnicamente las soluciones escogidas para realizar los ítems.
  • Definir criterios y pruebas de aceptación, ya sean más laxos o más esctrictos.
  • Estimar el coste de realización de los ítems, ya sea en tiempo o en tamaño relativo (p.e. puntos/historia).

 

 ¿Cuándo se hace el refinamiento?

El Refinamiento se hace cuando se considera necesario y cuando es posible. Algunos factores pueden aconsejar en qué momento hacerlos, p.e.:

  • En desarrollos de pocos Sprints puede realizarse principalmente en los primeros ciclos, pero siempre entregando producto al final de cada Sprint.
  • En desarrollos mayores puede realizarse de manera periódica para facilitar la asistencia de todos los participantes.
  • Las reuniones de refinamiento pueden ajustarse a la disponibilidad de las partes interesadas, como usuarios, expertos u otros roles, especialmente si es difícil convocarlos.

Adicionalmente, la preparación de los siguientes Sprints y la cantidad de Backlog refinado puede dictar la necesidad de realizar más o menos refinamiento.

 

 ¿Quién hace el refinamiento?

Existe una visión muy extendida que hace al Product Owner responsable exclusivo de definir los ítems y pasárselos al Development Team para que los convierta en software, derivada de la idea que estos últimos son básicamente técnicos (programadores, testers, etc.) y que no tienen capacidad de análisis. Esta visión como única opción es falsa, y va contra la idea de un Equipo Scrum polivalente y colaborativo. La Scrum Guide dice:

This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. ... The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. 

 

En esta definición no sé le da la responsabilidad al Product Owner ni de escribir requisitos ni pruebas de aceptación. El reparto de responsabilidad entre el Product Owner y el Development Team variará sensiblemente en función del perfil y disponibilidad del Product Owner. En la siguiente figura vemos posibles perfiles de Product Owner según Gunther Verheyen.

P50_scrumand-product-owner.png

 

Algunos contextos en los que es más probable que el Product Owner se encargue de la definición de los ítems de producto:

  • El Development Team es pequeño y no cuenta con especialistas funcionales.
  • El Product Owner es un experto en el dominio del problema.

Algunos contextos en los que probablemente el Product Owner delegue al los Developers el anàlisis y definición de aceptación de los ítems:

  • El Product Owner trabaja con un equipo grande o con varios equipos y no tiene capacidad para "alimentar" con requisitos a tantos developers.
  • El Product Owner tiene un perfil más estratégico o de negocio.

Cuando en los cursos de Scrum discutimos con los alumnos del reparto de responsabilidades entre el Product Owner y el Development Team, se entienden opciones de Scrum Team más autoorganizado y alejado de los roles tradicionales.

 

Finalmente, mi experiencia me dice que el Refinamiento no lo suele hacer todo el Development Team conjuntamente, ya que esto es muy ineficiente. Normalmente:

  • El refinamiento lo lideran los 2 o 3 miembros más senior del equipo, especialmente al principio.
  • El refinamiento suele particionarse en diferentes personas si tienen más experiencia que otras en partes del producto.
  • Las estimaciones suelen hacerse en una reunión muy corta (p.e. 1 hora) de todo el Development Team al final de cada refinamiento.

 

El refinamiento inter-equipo

En contextos donde hay varios equipos trabajando juntos en un producto, con un único Backlog y un único Product Owner, es fundamental que los varios Development Team trabajen alineados antes del Sprint durante el refinamiento:

  • Los equipos particionan en que parte del producto trabajaran cada uno. Es preferente que sean equipos capaces de tocar cualquier parte del producto (feature-teams) respecto a equipos específicos de componente.
  • Los equipos detectan y minimizan las dependencias. En este artículo se definen prácticas para realizar el refinamiento cross-team según Scrum.org: https://www.scrum.org/resources/cross-team-refinement-nexus
  • Los equipos planifican conjuntamente el alcance de los Sprints antes de realizar el refinamiento de los ítems que cada uno ha seleccionado.

 

En los cursos Scaled Professional Scrum explicamos con detalle como realizarlo. En otros modelos de escalado como LeSS (ver el diagrama siguiente) o SAFe se dan también guías sobre esto.

50_NexusInterteamRefinement.jpg

 

 El refinamiento, Ready y el evento de planificación

Como se ha visto anteriormente, el refinamiento incluye la actividad de estimación, que es imprescindible para que los eventos de Sprint Planning sean fluidos y efectivos. Según mi experiencia sirviendo como Scrum Master con algunos equipos, y con cientos de personas que han asistido a mis cursos, un Sprint Planning sin haber refinado adecuadamente y sin haber estimado los ítems suele estar plagado de dudas y acabar en una planificación muy poco realista. Esto no quiere decir que se pueda reestimar algún ítem durante la planificación, pero suele ser más la excepción que la regla.