Vertical Slicing (VII) — Creación y gestión del product backlog con incrementos

Todo esto esta muy bien, pero ¿Cómo encajo esto en mi Jira?

Respuesta corta: ¿Por qué tiene que encajar? No adaptemos nuestro desarrollo a la herramienta, adaptemos la herramienta a nuestro proceso de desarrollo.

Respuesta larga: Como había comentado en el segundo post, Adapta la herramienta a tu slicing, no tu slicing a la herramienta. Jerarquizar items del backlog para organizar el trabajo puede ser de ayuda, sin embargo, hacer slicing de una manera específica solo para adaptarse a los conceptos de tu herramienta de gestión — épica, feature, theme, tarea… — no ayuda para nada.

La idea es trabajar solamente con incrementos. Tendremos incrementos con más incertidumbre, que desarrollaremos de forma aún más iterativa e incremental haciendo slicing en más incrementos y otros más simples que podremos desarrollar de una sola vez.

No debemos confundir conceptos de la gestión del trabajo para organizarnos mejor dentro del equipo o para facilitar el reporting con la gestión y el seguimiento del progreso de la construcción del producto.

Incrementos como stories en el backlog

Cada incremento para construir la solución es una story.

Para tratar de dar una respuesta más práctica y menos disruptiva — que no les explote la cabeza a nuestros POs, PMs o Scrum Masters — podríamos equiparar lo que es una story a cada incremento.

Os dejo algunos links e información para que podamos tener claro el origen del concepto “story”. Nos servirán para sentar las bases y entender cada story como un incremento. Podéis hacer el ejercicio de analizar si de verdad lo empleáis de la manera que estaba pensado originalmente.

• En Extreme programming explained y Planning extreme programming especifican el origen de una “story”: un “cachito” de un comportamiento deseado de nuestro sistema. Esto sería exactamente lo que es un incremento para nosotros.
• En estos libros también nos explican como una story es un recordatorio de una conversación. No tiene que ser inicialmente muy detallada, debe ser simple y entendible por todos. Mike Cohn nos deja varios buenos ejemplos reales que utilizaron en un proyecto real.
• Recordad las 3C de Ron Jeffries — Conversation, Card, Confirmation — cuando registréis en vuestra herramienta preferida un incremento o story.
• Mike Cohn, autor de User Stories applied, explica que el concepto de Épica es más bien una “etiqueta” para identificar Users Stories grandes. Cuando las divides, la épica desaparece, no es un contenedor de user stories.
• Aquí los amigos de ThoughtWorks nos explican correctamente que es una épica y como tratarlas para ayudar al vertical slicing. En nuestro caso, evitaremos el concepto épica y hablaremos sólo de un incremento o story con aun mucha incertidumbre como para desarrollarlo con confianza.
• Hace poco leí esto en el Twitter de Ivan Badia. Me sirve para recordar que una story o incremento requiere de colaboración y conversación con el cliente o usuario, por lo tanto, debemos crearlas, identificarlas y detallarlas con ellos.

• Podemos seguir usando el template As a… I want… so that… para iniciar la conversación y el refinamiento. Nos ayudará a ir directamente a responder, quién, qué y para qué. Cuestionará si cada incremento es necesario o si de verdad estamos añadiendo valor desarrollándolo. Podéis también obviarlo o utilizar otro si os permite cuestionar de la misma forma cada incremento.

Pasemos ahora a ver como quedaría nuestro backlog con los ejemplos del checkout y del bot traductor de Slack.

Cómo construir un Product Backlog

Al inicio tendríamos algo tan genérico como una petición de un Checkout y una necesidad de un bot que traduzca en Slack. Podemos empezar por aquí.

Nos metemos en faena, y empezamos con algún tipo de inception o refinamiento con nuestro cliente, usuarios y stakeholders necesarios. Empezaremos a entender un poco el problema y a resolver ciertas dudas.

Con el checkout, nos podríamos dar cuenta que realmente son 4 necesidades distintas a resolver y que podrían tener diferentes tipos de usuarios.

Entenderíamos que el bot es realmente para un equipo específico que requiere la traducción ENG-ESP y de qué forma usan Slack. Pero aún tendríamos que indagar más para poder encontrar los primeros incrementos de la solución.

Disclaimer: Evito escribir el “so that” del template para facilitar la lectura del ejemplo, pero es uno de los datos más importantes que podeis obtener de una story.

Empleamos el ejercicio para empezar a encontrar nuestros primeros incrementos. Buscamos las actividades, descubrimos las complejidades que conllevan esas actividades y empezamos a seleccionar nuestros slices verticales que aporten algo de feedback y valor.

Vemos como nuestras stories grandes, con mucha incertidumbre, se van a construir con varios incrementos.

Algunas de estas stories aún pueden necesitar pensar un poco más como construirlas de forma iterativa e incremental. Nuestro ejercicio aún cuenta con el paso 6, donde analizaremos más técnicamente como resolver este trabajo.

Para ello, mi recomendación es simplificar todo el proceso, al igual que Kent Beck, en TDD by Example, utiliza una checklist para ir registrando y añadiendo los tests según los vaya necesitando y descubriendo, aquí, podríamos hacer lo mismo para los incrementos más técnicos.

Construyendo la story de manera iterativa e incremental, podremos ir descubriendo la incertidumbre técnica e incluso avanzar a la siguiente story cuando consideremos que hemos desarrollado lo necesario para darla por cerrada.

Recordad que estamos resolviendo problemas complejos, por lo tanto el backlog no es cerrado ni definido completamente. Nos será difícil encontrar desde el principio todas las stories necesarias.

Construyendo de manera iterativa e incremental añadiremos nuevas stories al backlog si hemos encontrado algún concepto o complejidad nueva que no habíamos descubierto antes de ponernos manos a la obra. Por ejemplo, podríamos encontrar en esta primera story que la gestión de errores es insuficiente con algo genérico y debemos crear una story nueva en el backlog para indagar que necesita nuestros usuarios con respecto a los errores.

1. Vertical Slicing (I) — Desaprende lo que sabes sobre user stories y pon el foco en desarrollo iterativo e incremental.
2. Vertical Slicing (II) — “Merciless slicing”, cómo encontrar los incrementos.
3. Vertical Slicing (III) — Ejemplo práctico (Checkout de un e-commerce).
4. Vertical Slicing (IV) — Desarrollo iterativo e incremental como modelo mental (al igual que en TDD).
5. Vertical Slicing (V) — Ejemplo práctico (Bot en Slack para traducir mensajes)
6. Vertical Slicing (VI) — Otros casos reales donde usar desarrollo iterativo e incremental.
7. Vertical Slicing (VII) — Creación y gestión del product backlog con incrementos
8. (Próximamente) Vertical Slicing (y VIII) — Facilitación del Workshop.
9. Slides del workshop