Scrum: Product Backlog

Para poder desarrollar un producto con Scrum, un equipo necesita tener un Product Backlog.

Se trata de una lista priorizada de todo lo que el producto debe tener, y representa el entendimiento actual del alcance del producto. Como el Product Backlog es dinámico, a medida que se descubran nuevas características, su contenido irá evolucionando.

Esa evolución se da a través de los Sprints, a medida que:

• Se pasan ítems al Sprint Backlog, durante la Planning.
• Se agregan nuevos ítems que sean valiosos para el producto
• Se eliminen ítems cuyo valor ya no es relevante
• Se descompongan ítems grandes en otros más pequeños
• Se cambian las prioridades de los ítems, al reconsiderar su valor actual

Una idea central es que el Product Backlog es la única fuente de trabajo relativa al producto para el equipo. Sus ítems contienen todas las características, funcionalidades, mejoras, correcciones o extensiones que el producto necesite, y por lo tanto, todas se priorizan en conjunto, para ser desarrolladas por el mismo equipo ó equipos de producto.

Cuando un producto es muy grande, el esfuerzo puede distribuirse entre más de un equipo, con un único Product Backlog (y un único Product Owner), que representa la prioridad actual para el producto completo, en vez de prioridades parciales por componentes o áreas.

El Product Owner es el responsable por su contenido, visibilidad y priorización.

El Product Backlog sirve para responder a la pregunta "¿qué es lo próximo a desarrollar?" y aporta una restricción sana a la situación de que los Stakeholders siempre tendrán deseos aparentemente ilimitados para el producto, pero las organizaciones tiene recursos acotados.

Al hacer las prioridades transparentes para todos los involucrados, se habilita la discusión de cómo se distribuye el esfuerzo dentro de la capacidad disponible, siempre con la restricción adicional de la duración del Sprint.

Refinamiento del Product Backlog

Los ítems del Product Backlog (o PBI: Product Backlog Items) están ordenados entonces por su importancia en cada momento, y los más importantes suelen estar "refinados", es decir que ya están:

• Con su valor establecido (y ordenados en consecuencia)
• Divididos en los ítems más pequeño posibles
• Estimados (el equipo debe saber al menos que puede desarrollar varios en un Sprint)
• Detallados (suficiente como para que nada se bloquee en la Planning)

Los ítems que tienen menor prioridad (aún lejos de ser considerados en un Sprint o dos) pueden tener menos nivel de detalle, y aún no estar divididos en partes más pequeñas. Casualmente en Scrum diferimos estratégicamente esa tarea, para:

• Aprovechar todo el aprendizaje previo al momento de analizar un ítem, sobre todo el ver el incremento más reciente del producto, lo que influye muchísimo sobre próximas decisiones.
• Evitar analizar ítems que pueden variar (o desaparecer)

La actividad de agregar estos detalles al Product Backlog  no es un "evento" sino una tarea permanente del Product Owner, llamada Product Backlog Refinement, que realiza colaborativamente junto a los Stakeholders y resto del Scrum Team.

La recomendación de involucramiento del Development Team en esta actividad es que no exceda el 10% del tiempo disponible del Sprint, pero eso es usualmente bastante tiempo.

Más allá de esa recomendación no hay ningún proceso ni límite de tiempo establecido, y cada equipo Scrum decide y mejora continuamente cómo realiza el refinamiento.

Es importante entender que los ítems que se refinan durante un Sprint no son los que ya están en el Sprint Backlog (y por ende, durante la Planning, se fueron del Product Backlog), sino los que siguen en prioridad, y pueden ser incluidos en el próximo Sprint (y un poco más, ya que no se puede predecir con exactitud lo que sucederá en la siguiente Planning).

También es importante, en mi opinión, que las actividades de Refinamiento no se conviertan en una Planning anticipada. Si se baja a demasiado detalle, sobre todo con el Development Team, estaríamos causando una sobrecarga cognitiva, ya que están trabajando en una serie de ítems (el Sprint Backlog actual) y no queremos distraerlos con detalles que pueden quedar para la Planning, cuando ya están liberados y listos para comenzar otro ciclo.

La estructura de Scrum

Siguiendo con la premisa de que Scrum es "fácil de entender, pero difícil de dominar", avancemos con la parte fácil. 😁

Scrum está compuesto, además de sus pilares y valores, por una serie de artefactos, eventos y roles.

AVISO
Este artículo es una guía inicial, que se irá completando con links a detalles más completos (en artículos separados) a lo largo de las próximas semanas.

---

 Artefactos -> Transparencia

Los llamados "artefactos" de Scrum son elementos mínimos para lograr alto grado de transparencia respecto al planes, trabajo pendiente y resultados obtenidos.

Product Backlog

El Backlog (o Pila) de Producto es una lista ordenada de todo lo que el producto pueda necesitar. Es una lista en constante evolución, dinámica, y es la única fuente de trabajo para el equipo.

El orden en que están los ítems del Product Backlog transparentan la visión y estrategia de producto que clientes, gente de negocio y equipo comparten, poniendo énfasis en que lo que está en los primeros lugares es lo que queremos que el producto tenga en el más corto plazo.

Sprint Backlog

El Backlog (o Pila) del Sprint es un subconjunto del Product Backlog, seleccionado por el equipo para trabajar en un Sprint (o iteración), al que se agrega un plan de cómo convertir esos ítems en un incremento de producto cumpliendo el objetivo del Sprint.

El Sprint Backlog transparenta el trabajo del equipo durante el sprint, incluyendo el objetivo general y otros indicadores que sirvan al equipo y al resto de la organización.

Product Increment

El Incremento de Producto es la suma de todos los ítems del Product Backlog terminados durante el Sprint, agregado al valor obtenido en todos los Sprints anteriores.

Este Incremento transparenta de manera radical el estado del producto. Es una versión del producto utilizable y completa, independientemente de que se decida entregarlo o no a la audiencia final.

Para  asegurar esa usabilidad, el Incremento debe cumplir con la Definition of Done (definición de terminado) que el equipo tiene acordada.

---

Eventos -> Inspección y Adaptación

Los eventos de Scrum brindan la estructura temporal mínima, evitan reuniones adicionales, y tratan de minimizar el desperdicio de tiempo y esfuerzo.

Sprint

El Sprint (iteración) es el corazón de Scrum. Es un contenedor de todos los demás eventos más el trabajo regular de desarrollo. Marca el pulso de trabajo, siendo su duración inalterable y estable a lo largo del ciclo de vida del producto.

Cada Sprint comienza con una planificación de su Objetivo y su Sprint Backlog, trabajo de desarrollo de producto, que se sincroniza diariamente, un Incremento de Producto que es revisado sobre el final, y un espacio de reflexión para la mejora continua.

Sprint Planning

Al inicio de cada Sprint, el equipo se reúne para definir el Objetivo del Sprint, y seleccionar los ítems del Product Backlog en los que trabajarán para cumplirlo. Esos ítems, junto con información  adicional de cómo desarrollarlos, se convierten en el Product Backlog.

En la Planning el equipo inspecciona las expectativas de corto plazo sobre el producto y adapta su estrategia para lograr un resultado concreto.

Daily Scrum

Todos los días a la misma hora y el mismo lugar, el equipo se reúne durante un máximo de 15 minutos para inspeccionar cómo avanza hacia el objetivo del Sprint y adaptar sus planes para alcanzarlo.

El resto del día, a excepción de los eventos de inicio y fin del Sprint, el equipo se dedica al desarrollo del producto mismo.

Sprint Review

Sobre el final del Sprint, el equipo colabora con clientes, gente de negocios u otros interesados para inspeccionar el Product Increment, de manera de poder adaptar, a través de actualizaciones al Product Backlog y un entendimiento común, los planes hacia adelante.

Sprint Retrospective

La "Retro" es una oportunidad para que el equipo se auto-inspeccione, y adapte su manera de trabajar, mejorando de manera continua.

Es el momento principal en que el equipo decide cómo le conviene hacer todo lo que Scrum no dice, como temas de relacionamiento, técnicos, de comunicación, organizacionales, y otros.

---

Roles

Un equipo Scrum tiene solamente tres roles internos: el Development Team (o equipo de desarrollo), formado por múltiples profesionales, y otros dos que son individuales, el Product Owner y el Scrum Master.

La suma de las personas cubriendo estos tres roles en un equipo es lo que se llama Scrum Team (o equipo Scrum).

Todas las personas interesadas en el producto que pueden interactuar con el Scrum Team pero no forman parte de él son llamados Stakeholders, o involucrados. Entre ellos puede haber clientes, personas de negocios, personas de otras áreas de la organización que tienen influencia sobre el producto, como marketing, legales, tecnología, atención a clientes, y también personas externas a la organización como consultores, auditores, analistas de mercado, y muchos otros.

Development Team

Es un grupo multi-disciplinario de profesionales que se encargan de entregar un incremento de producto utilizable al final de cada Sprint.

Product Owner

Es la responsable de maximizar el valor del producto que entrega el Development Team. La manera en que lo hace es muy diferente en cada equipo, pero se centra alrededor de la administración del Product Backlog.

Scrum Master

Es la responsable de promover y dar soporte a Scrum, ayudando a que todos comprendan y usen apropiadamente sus valores, prácticas y reglas.

Pilares y Valores de Scrum

Una contradicción frecuente en personas y organizaciones interesadas en adoptar Scrum es que no se resignan a dejar de preguntar cosas como: "¿Cuándo va a estar lista exactamente ésta característica del producto tal cuál yo pedí?"

La pregunta no está mal en sí misma, pero corresponde a lo que se conoce como "Control de procesos definidos", donde tenemos un plan establecido, y el alcance del proyecto/producto está completamente cerrado. Este tipo de procesos sigue siendo útil en temas como la ingeniería civil, o la industria de la construcción, por milenios, aunque como sabemos, las predicciones en este modelo muchas vez no son correctas.

Procesos de Control Empírico

Scrum no sirve como modelo predictivo, porque se encuadra dentro del modelo empírico. Este modelo se aplica cuando aceptamos que el nivel de incertidumbre de nuestro desafío es alto.

No por casualidad, Scrum tiene mucho éxito en lo que llamamos contextos VICA:

• Volatilidad
• Incertidumbre
• Complejidad
• Ambigüedad

De este estilo de control de procesos Scrum hereda sus tres pilares fundamentales.

Pilares de Scrum

Transparencia, Inspección y Adaptación

Podemos recorrer estos tres principios pensando en la pregunta original. Si el problema es complejo y la solución es incierta, ¿cómo podemos entonces saber cómo vamos?

La transparencia en Scrum es de doble vía: los clientes o el "negocio" deben brindar información concreta al equipo sobre sus hipótesis, objetivos y dependencias, y el equipo debe dar transparencia de sus planes, decisiones y sobre todo, resultados.

En base a esos datos, y en iteraciones cortas, el equipo mostrará resultados concretos (no planes, diseños ni porcentajes, sino un producto funcional) que inspeccionarán junto a los clientes o "negocio", entendiendo:

• Decisiones acertadas o no
• Hipótesis de negocio comprobadas o no
• Calidad del producto
• Estado actual frente a un contexto volátil
• Comprensión correcta entre todos, en un entorno ambiguo

Basados en este aprendizaje, el equipo y sus clientes adaptan su plan hacia adelante, poniendo en juego una nueva serie de premisas, objetivos de corto plazo y estrategias.

Todo esto se repite en ciclos permanentes, ya que los procesos empíricos se basan casualmente en la iteración continua.

Pero Scrum agrega a estos pilares una serie de principios que se encuentran detrás de cada uno de los roles, eventos y artefactos, junto con los pilares.

Valores de Scrum

Compromiso, Coraje, Foco, Apertura, Respeto

Estos valores, que muchas veces se ignoran en adopciones de Scrum, tomando solamente la parte mecánica (los roles, eventos y artefactos) son los que revelan la intención detrás del marco de trabajo, y permiten entender mejor el porqué de cada pieza.

Veamos un poco el origen de estas palabras (en su versión inglesa original) y porqué tienen tanta importancia en Scrum:

Compromiso (commitment)

Viene de "confiar a alguien, delegar autoridad", y refiere a unirse por un objetivo común.

En Scrum, los miembros del equipo se comprometen de manera personal, para cumplir con un objetivo colectivo. Dentro del equipo cada uno es responsable y rinde cuentas a los demás, pero hacia fuera comparten una responsabilidad y rinden cuentas como grupo.

La importancia de este principio es que no se puede afectar la autonomía del equipo como tal, tratando de "gestionar" a miembros individuales, ni se puede reducir ese compromiso haciendo que los miembros tengan responsabilidades fuera de su equipo.

Coraje (courage)

Originalmente, "desde el corazón", se entiende como el tomar acción en base a nuestras creencias o principios.

En Scrum, se espera que el equipo mantenga los principios de Scrum y sus acuerdos, sobre todo cuando no sea fácil hacerlo. Tiene que ver con "hacer lo correcto, de la manera correcta", y refiere a mantener el objetivo común y la calidad técnica, pero implica un alto nivel de autonomía.

Un equipo Scrum no puede sentirse limitado por decisiones externas, y constantemente cuestionará normas o políticas que no considere positivas para alcanzar sus resultados de manera sostenible.

Foco (focus)

Proviene de "fuego", y tiene que ver con reunirse alrededor de la fuente de calor. Por eso lo usamos para algo que nos mantiene "mirando hacia ese lado".

Scrum es una manera de mantener al equipo permanentemente enfocado en el trabajo de la iteración actual (sin preocuparse por detalles de lo que vendrá, más allá de la visión de conjunto) y de sus objetivos como equipo, que surgen siempre de lo que es importante "ahora" para el producto.

Apertura (openess)

Algo abierto es algo expuesto y evidente.

En Scrum (dado el pilar de transparencia) se expone abiertamente tanto el plan, el trabajo en marcha, los resultados, y sobre todo, los desafíos (del equipo, de la organización, del producto, del mercado, de los clientes, y otros).

La apertura en cuanto a todo, incluyendo feedback abierto sobre todos los temas, permiten efectuar todo el tiempo el proceso de inspección y adaptación.

Respecto (respect)

Refiere originalmente a "ver" o "volver a mirar", y significa apreciar sinceramente las características únicas de otras personas.

En Scrum se propicia el respeto cruzado, de los clientes hacia la capacidad y autonomía del equipo, del equipo al entendimiento del negocio y sus desafíos de los clientes, pero también entre cada miembro del equipo, y por sus roles y responsabilidades.

Pero ese respeto implica que todo está abierto a cuestionamientos, de manera amable, con el objetivo de que las partes se entiendan lo mejor posible, elevando siempre la transparencia.

¿Y cuál es la respuesta?

Antes de comprender la estructura de Scrum, entonces, es importante entender que podemos preguntar o no.

Esto no quiere decir que no podamos tener fechas límites, o limitaciones de presupuesto. Lo que no trata de hacer Scrum es predecir nada.

Scrum no es un modelo predictivo, es un modelo adaptativo.

Las preguntas constantes en Scrum serán entonces, inspeccionando el producto frecuentemente:

• ¿El producto agrega valor?
• ¿Estamos más cerca de resolver el problema?
• ¿Vale la pena seguir adelante, o hay otro problema más valioso por resolver?

Y así, mediante continua inspección y adaptación, en muchos casos podremos tener resultados mejores a los que tenemos tratando de cumplir con predicciones que ya no son relevantes.

¿Qué es Scrum y para qué se usa?

Aquí comienza una serie de artículos en que intentaré describir el marco de trabajo Scrum, cubriendo temas que en su momento no quedaron incluidos en el libro "Proyectos Ágiles con Scrum" que escribimos con mi amigo Martín Alaimo. Tal vez al terminar la serie tenga el material para una nueva edición, o para un libro nuevo, pero eso ya lo veremos.

Sitio de la Guía de Scrum

¿Qué es Scrum?

Según la Scrum Guide (la guía oficial que mantienen Ken Schwaber y Jeff Sutherland, los desarrolladores originales) Scrum es (mi traducción):

Un marco de trabajo en el que las personas abordan problemas adaptativos complejos, mientras entregan productos del mayor valor posible de manera productiva y creativa.

Me gusta esa  definición que fue evolucionando a lo largo del tiempo, pero voy a tratar de analizarla por partes, para evitar algunas confusiones comunes.

Un marco de trabajo...

Como dicen los autores, Scrum no es un proceso, ni una técnica, ni un método definido. Es un marco intencionalmente incompleto.

Scrum brinda apenas un conjunto mínimo de Roles, Eventos, Artefactos y las reglas que los enlazan, sin entrar en detalles profundos sobre los mismos. Scrum no viene "listo para usar", y no es algo que un equipo (mucho menos varios equipos) pueden aprender y dominar en un par de semanas.

Scrum requiere paciencia para adaptarlo constantemente, y no hay una situación en la que alcanzamos el "máximo nivel posible". Como con casi todo sistema de mejora continua, si creemos que ya alcanzamos el máximo rendimiento, seguramente estamos en graves problemas.

...en el que las personas...

Esto es fundamental, y es fuente de muchísimas confusiones. Scrum no es una herramienta de management, al menos en el sentido tradicional. No es un marco para dirigir y controlar "recursos". Es un marco en el que las personas, individualmente y como equipo, se auto-organizan para lograr un objetivo común.

...abordan problemas adaptativos complejos, mientras entregan productos...

Scrum no es útil para problemas bien definidos o de baja complejidad. Por ejemplo, es probable que no aporte valor en un proceso de manufactura o prestación de servicios en serie, una vez que estos ya fueron definidos. Incluso si en ambos casos se puede aplicar mejorar continua, hay marcos mas útiles.

Mas allá de que Scrum es utilizado cada vez en más industrias y áreas, en líneas generales aplica al desarrollo de productos (o servicios) a lo largo de todo su ciclo de vida.

Pero tampoco es una definición exacta. Por la dificultad de determinar qué es un productoy que no. Y también porque nuestro contexto es cada vez más complejo.

...del mayor valor posible de manera productiva y creativa

El gran aporte de Scrum (al igual que otros marcos ágiles) es la entrega continua y frecuente de un producto para resolver ese problema adaptativo complejo.

La productividad de Scrum está basada en que el equipo de trabajo usa su creatividad y auto-organización para entregar un producto que se puede observar en períodos muy cortos, sobre el que se puede reflexionar y ajustar para seguir desarrollándolo.

Es común ver adopciones de Scrum que no ponen énfasis en entregar producto de forma frecuente, o sólo lo hacen a nivel interno, sin ponerlo en producción, ó lanzarlo al mercado, ni siquiera para una audiencia reducida que luego vaya en aumento.

Otras características

Una a frase adicional que destaca otras características de Scrum es que "es un marco de trabajo liviano, simple de comprender, pero difícil de dominar".

Es liviano porque no requiere demasiada supervisión. Por lo contrario, lo que suele costar en organizaciones con alto nivel de formalidad, es que requiere menos supervisión y más delegación de responsabilidades.

Es tan simple de comprender que los cursos iniciales son de dos días como máximo, y la Guía mencionada tiene menos de 20 páginas, que al quitar portada, índice, agradecimientos y demás agregados llegan apenas a una docena.

Pero es difícil de dominar porque requiere práctica y adaptación al problema, el producto, el equipo, la organización y muchas otras variables que hacen al contexto en que será utilizado. Al no haber una receta, depende del equipo mismo. La buena noticia es que Scrum sirve casualmente para eso, para ayudar a que un equipo madure de manera continua mientras entrega incrementalmente un producto.

Hacia adelante

Esta definición es de muy alto nivel, y lo que queda para entender Scrum, a través del resto de esta serie, son sus elementos:

(nota: en la serie utilizaré para la mayoría de los elementos los nombres originales en inglés, ya que las traducciones pueden ser ambiguas, y son términos sencillos y muy utilizados)

• Pilares: Transparencia, Inspección y Adaptación
• Valores: Compromiso, Coraje, Foco, Apertura y Respeto
• Estructura general
• Artefactos: Product Backlog, Sprint Backlog, Product Increment
• Eventos: Sprint, Planning, Daily Scrum, Review, Retrospective
• Roles: Development Team, Product Owner, Scrum Master (y stakeholders)
• y las pocas reglas que los vinculan: 
• Definition of Done
• Refinement

3 elementos para una Arquitectura más Ágil

Esta semana me pidieron en un cliente si podía compartir algunas definiciones o lineamientos sobre agilidad en Arquitectura de Software, para trabajar en una reunión interna.

Como otras veces, después de pensar la respuesta y escribir un poco, les pedí permiso para compartir las ideas en este blog, y aquí van los tres elementos a los que llegué, a través de algunas preguntas de ellos:

Arquitectura incremental

Igual que con el diseño funcional, desconfiamos del "gran diseño preliminar", y tratamos de empezar con la arquitectura mínima necesaria para la funcionalidad que estamos encarando. Podemos hacer este ejercicio, idealmente, Sprint a Sprint, decidiendo sobre la arquitectura en cada planning.

IMPORTANTE: esto no implica que no iniciemos con algunos elementos mínimos de referencia, que nos son comunes (un lenguaje, un framework, una base de datos, etc). Es común que dentro de una organización tengamos algunos lineamientos (idealmente definidos de manera colaborativa). Lo que nos dejamos abierto es la posibilidad de cambiar algo más adelante, si nos damos cuenta que nos conviene.

Validación continua

Más allá de una visión general de guía, igual que con la funcionalidad, tratamos de dejar una prueba automatizada que nos ayuda a validar que logramos el efecto que queríamos al implementar cada pieza de arquitectura: por ejemplo, pruebas de performances, de extensibilidad, validaciones de nivel de acoplamiento o complejidad, etc. Esas pruebas se ejecutan de manera continua, al igual que las pruebas unitarias o de aceptación.

Esa validación permanente en el entorno de desarrollo/QA se extiende también a mediciones en el proceso automatizado de deployment, y al monitoreo de la solución en el ambiente productivo (monitoreo de servidor, clientes, dispositivos, plataforma, etc). Todo ese seguimiento es lo que nos permite entender si nuestra arquitectura realmente está soportando lo que necesitamos en este momento, y también comprobar si cualquier cambio tiene el efecto deseado o no. Ese nivel de feedback es lo que nos permite encarar cambios en la arquitectura sin entrar en pánico.

Demasiado importante para dejárselo a los Arquitectos

Como no diseñamos la arquitectura por completo en el inicio, tampoco se define desde un rol centralizado o mediante especialista en un silo. Aunque haya personas en el equipo con el título de Arquitecto, el tema se discute con todo el equipo y con los involucrados del negocio, y las decisiones se realizan de manera colaborativa, teniendo en cuenta todos los puntos de vista.

Las decisiones tampoco suelen ser finales, sino que se diseñan experimentos, con métricas asociadas y un objetivo a alcanzar, que se validado o no en la implementación.

Nuevamente, este no quita que exista un equipo de Arquitectura Corporativa o algo similar. La diferencia es que esos grupos se ocupan más de entender las restricciones generales necesarias para el negocio, la plataforma común, el ecosistema de diferentes aplicaciones (propias y de terceros), y actúa como un participante frecuente en las reuniones de planificación de los equipos, no para imponer definiciones, sino para tener feedback y colaborar en las definiciones de cada aplicación.

Finalmente, como para otras actividades, interese o tecnologías (testing, diseño, JS, bases de datos, temas de negocios) el intercambio y alineamiento de temas de arquitectura entre diferentes equipos se puede realizar mediante espacios de Comunidades de Práctica.

 

Continuando la discusión

Obviamente estas ideas están resumidas y tienen mucho más detrás. Si te interesa continuar este tema, algunas de las cosas en las que he trabajado a lo largo de los años son:

• El paper “Software Architecture in the Agile Life Cycle” que publicamos en 2010 con mi amigo y colega de la vida Diego Fontdevila.
  (Original en inglés, en el Architecture Journal; ó versión en español, actualizada en 2013)
• Mi libro en progreso, Agile Software Architecture.
• Mi Agile Architecture Workshop, que doy varias veces al año en distintas ciudades de América Latina
  (cuando hay fechas programadas aparecen a la derecha)
• Otros libros relacionados de colegas varios: 
• Building Evolutionary Architectures, de Rebecca Parsons, Neil Ford y Patrick Kua
• Lean Architecture, de James Coplien y Gertrud Bjørnvig