Vertical Slicing: Cómo dividir el Product Backlog

Una de las grandes ventajas de Scrum es utilizar la inspección y adaptación para tomar decisiones. Cuando construimos un producto con una idea, tenemos que validar que estamos consiguiendo valor. Para eso, tratamos de construir pequeñas partes de nuestro producto y vamos adaptándonos a medida que aprendemos, a través del Vertical Slicing. Por esa razón, decimos que Scrum es iterativo e incremental. 

Para poder ser incrementales, tenemos que ser capaces de entender las necesidades de nuestros customers, la visión de lo que queremos resolver y traducirlo en features que aporten valor. Además, debemos ser capaces de construirlas de manera end-2-end, es decir, ser capaces, en cada iteración, de entregar valor al usuario, para poder recibir feedback lo antes posible. 

¿Cómo construir un producto digital? 

Si entendemos un producto digital (principalmente software) como un conjunto de features que creamos, evolucionamos o retiramos, podemos visualizar nuestro producto de la siguiente manera: 

Debemos entender que no existe final, salvo que retiremos el producto del mercado o decidamos no evolucionarlo más. Esta diferencia es vital, no estamos ante proyectos con fecha de inicio y fin, sino productos que se van incrementando con el tiempo en función de las necesidades que queramos cubrir o el problema que estemos resolviendo. 

El modelo tradicional asume que conocemos el final, que sabemos todo lo que vamos a construir. A veces, esto se sabe tras una “fase de análisis” donde detallamos todo aquello que haremos. Con el objetivo de optimizar recursos, construimos las aplicaciones con un enfoque waterfall, cuando acabamos el análisis, pasamos al diseño, después a la implementación etc. Así, agrupamos en cada momento las diferentes tareas que vamos a realizar, y podemos poner foco en cada capa. Por ejemplo, una vez el análisis está finalizado, podemos “liberar” al analista. 

La visión waterfall de construcción del trabajo tiene varios problemas. Por un lado, asumimos que conocemos el fin, algo que en el mundo del conocimiento no es así. Las necesidades de los clientes cambian contínuamente y no podemos estar mucho tiempo sin escucharlas. Otro motivo es que tardamos demasiado tiempo en hacer una entrega, y, por tanto, en recibir feedback o validar que vamos por el buen camino. De hecho, un proyecto waterfall tradicional puede llegar a consumir todo el presupuesto antes de que el usuario final obtenga algo, y en caso de haber fallado nos quedamos sin margen para rectificar. 

División por capas: ¿Horizontal Slicing?

Cuando planteamos un cambio de paradigma de waterfall a Agile, muchos equipos siguen dividiendo el trabajo de manera horizontal (Horizontal Slicing). Es decir, se plantean tareas de análisis, diseño, o pruebas de manera separada. 

Esta visión horizontal nos lleva al mismo punto que el waterfall, ya que es fácil caer en la tentación de agrupar todas las tareas de análisis en un “sprint de análisis” y tener “waterfall en Sprints”. A pesar de que usamos Scrum, la manera en la que organizamos el trabajo nos sigue impidiendo trabajar con foco en negocio gracias al feedback temprano (tenemos que esperar mucho a tener algo terminado que poder mostrar). 

Sí es cierto que, una vez hemos decidido qué parte del producto acometemos, los equipos de desarrollo dividen los elementos del Product Backlog en tareas técnicas. Estas tareas, por sí solas no suelen agregar valor, necesitan estar integradas. Por eso, disponemos de una Definition of Done que garantice que nuestro trabajo se orienta a terminar el trabajo. 

Vertical Slicing: división incremental

El objetivo de Scrum es mejorar la capacidad de adaptación de un equipo por lo que, para adaptarnos, tenemos que inspeccionar el resultado que nuestro producto produce y, para eso, necesitamos tener incrementos de features terminadas. Para conseguir esto, utilizamos el Vertical Slicing (división vertical). Con la visión vertical, tratamos de hacer features pequeñas que aporten valor y que podamos entregar a nuestros customer cuanto antes. 

De esta manera, obtenemos feedback cuanto antes y,así, sabemos si vamos por la dirección correcta. El Vertical Slicing es una buena estrategia cuando construimos un producto, ya que centramos la discusión sobre qué features son más importantes para maximizar el valor de nuestro producto.

Cuando construimos productos incrementales mediante Vertical Slicing, la Sprint Review gana relevancia. Recordemos que el objetivo de la misma es inspeccionar el impacto de nuestro producto en el mercado, para adaptar nuestro Product Backlog con las nuevas features que abordaremos. Con la visión vertical, nos centramos en el impacto de nuestro producto y no en el tanto por ciento de avance de nuestro proyecto para llegar a fecha. 

Cómo dividir mi producto mediante el Vertical Slicing

Quizás este sea el punto más complicado de Scrum. Conseguir una división del producto en vertical es de los conceptos de Agile que más me cuestan explicar. Además, es mucho más complicado cuando construimos un producto que sustituye a uno existente, no queremos que tenga menos funcionalidad que el original. 

Imaginemos que queremos construir un portal inmobiliario para pisos embargados. Nos gustaría tener muchas features: anuncios, mapas virtuales de las viviendas, zona de anuncios para las inmobiliarias y alertas cuando una vivienda baje su precio. Sin embargo, no podemos esperar tanto tiempo para saber si nuestro nuevo portal tendrá éxito, así que utilizamos el Vertical Slicing para dividir el trabajo. 

Podríamos añadir features de la siguiente manera: 

• En la primera entrega podemos crear un portal con solo anuncios donde tengamos el mínimo de información: teléfono, precio y calle.  Es algo simple, y posiblemente genere pocas llamadas, pero nos permite testar nuestra propuesta de valor de pisos embargados. 
• En la siguiente iteración, añadimos nuevas opciones: tamaño del piso, número de habitaciones y de baños, e incluso tipo de vivienda. 
• Para la tercera iteración permitimos fotos y filtros en las búsquedas
• En la cuarta, dejamos un formulario de contacto, y una zona de anuncios para las inmobiliarias. 
• Por último, añadimos un registro de usuarios donde puedas recibir alertas cuando un piso baja de precio o aparezcan viviendas que se acercan a la que buscas. 

Evidentemente, esta manera de dividir el trabajo debe adaptarse a medida que nuestros usuarios nos den feedback. Por eso, es clave añadir features en las que  los usuarios nos muestren su satisfacción y puedan comentarnos mejoras. Scrum no se propone hacer el trabajo más rápido, sino que seamos capaces de  adaptarnos para ser efectivos. 

Impedimentos del Vertical Slicing

El Vertical Slicing adolece de varios problemas que debemos tener en cuenta y que no son sencillos de resolver. Cuando decimos que un Scrum Master resuelve impedimentos, vamos a estudiar algunos de ellos que imposibilitan a un equipo ser incremental. 

El primer problema habitual es no disponer de equipos end-2-end, debido a la estructura organizativa en silos. Al no disponer de todas las skills para obtener producto, nos puede ocurrir que, por ejemplo, el Departamento de UX nos “preste” personas durante un tiempo corto y nos exija que acabemos todo su trabajo cuanto antes. Buscamos que las personas estén ocupadas en vez de centrarnos en entregar valor. 

El segundo problema que puede aparecer es tecnológico. Trabajé hace años en una aseguradora que quería renovar su web de venta directa de seguros. Hicimos un cambio tecnológico, visual y añadimos nuevas features para mejorar la experiencia de nuestros clientes. El problema radicaba en el motor de seguros, que estaba hecho en una tecnología antigua y no se podía renovar. El Vertical Slicing no era viable, ya que para obtener precios de los seguros debíamos enviar muchísima información que debíamos capturar en varias pantallas. Esto provocaba que tuviéramos features sin terminar hasta pasados varios Sprint. Todo esto nos llevaba a un riesgo elevado para averiguar si íbamos por el camino adecuado. La tecnología puede limitar nuestra capacidad de entregar, venimos de trabajar en proyectos de varios años y es complicado introducir una filosofía de división del trabajo en vertical. 

El tercer problema puede ser de recursos. Por ejemplo, si nuestra empresa solo dispone de un número limitado de servidores de preproducción, no nos dejarán usarlos hasta que tengamos una gran cantidad de features terminadas. Esto provoca que tengamos que esperar muchos Sprint para hacer una entrega real, lo que dificulta la obtención de feedback. Una vez más, este tipo de situaciones se dan porque orientamos las empresas hacia la eficiencia de recursos y no de flujo. La empresa prefiere tener pocos servidores y siempre ocupados que muchos y a veces ociosos. Pero esta estrategia genera colas y esperas en nuestra capacidad de entregar. 

Conclusiones

El Vertical Slicing es una herramienta más a tener en cuenta a la hora de un desarrollo de producto iterativo e incremental. Organizar el trabajo de manera vertical es esencial si queremos obtener resultados. Si no tenemos Vertical Slicing, no construiremos features terminadas y, sin ello, no podremos entregar, sin entrega no hay feedback y sin feedback… ¿Cómo sabemos que entregamos valor?