×
×

Tipos de PBI en desarrollo de hardware con Scrum

Cuando desarrollamos un producto nuevo, quizás sabemos a dónde queremos llegar o cuál es el producto final, pero no sabemos exactamente cómo lo vamos a realizar debido a su complejidad, dificultad e incertidumbre. Por este motivo, tenemos que ser conscientes de que necesitamos un enfoque distinto para cada reto o requisito. Por ejemplo, en caso de desarrollar un refrigerador tradicional, conocemos las leyes físicas, la arquitectura del producto y hay documentación accesible acerca de este producto. Gracias a eso, sabemos cómo construirlo y los pasos a seguir. Pero si desarrollamos un nuevo tipo de refrigerador, uno que nunca antes se haya visto, con nuevas mejoras y características, no será tan sencillo como el refrigerador tradicional. Necesitaremos un enfoque apropiado para cada requisito, y así, facilitar la investigación y el desarrollo en este complejo tópico en particular. Porque no hay documentación, no hay experiencia o conocimiento detrás de este nuevo producto.

El equipo Scrum refleja estos requisitos en “Product Backlog Items” (PBIs) y tienen la opción de usar diferentes maneras de describir PBIs. Estas son las situaciones con las que me he encontrado en un equipo de desarrollo.

  • Empezaremos con las fáciles: cuando necesitamos hacer algo que es cuestión de tiempo. Sabemos lo que necesitamos y sabemos cómo lo vamos a hacer. Tan solo necesitamos formular el “acceptance criteria” para tener un claro entendimiento del PBI entre el “Product Owner” y el “Development Team” (Dev Team). En este tipo de “item” no hay ningún problema para terminarlo en el “Sprint”.
  • Cuando sabemos lo que queremos hacer y sabemos cómo hacerlo (como el anterior), pero no tenemos suficiente tiempo para acabarlo en un “Sprint”. En este caso, debemos partir el “item” en pequeños paquetes de trabajo, de tal manera que, al menos cada parte, se puede completar en un Sprint.
  • Cuando sabemos lo que queremos hacer, pero no estamos seguros de cómo lo vamos a hacer. Este “item” tiene una dosis de incertidumbre por su complejidad y no sabemos con certeza si vamos a ser capaces de terminarlo en el Sprint. Pero si el equipo de desarrollo es suficientemente valiente y se siente seguro dentro de la organización, irán a por ello. También formulamos un “acceptance criteria” muy claro para que el “Product Owner” y el “Dev Team” estén alineados. Ambos saben que es algo difícil y que hay un riesgo de no acabarlo en el Sprint. En este caso, es especialmente importante que haya transparencia en todas las partes del equipo.
  • Cuando tenemos que pensar fuera de nuestra zona de confort o cuando tenemos que innovar. Como he comentado anteriormente, a veces inventamos un nuevo producto que no tiene documentación o experiencia al alcance. Pues confiamos en los desarrolladores para crear una tecnología nueva fruto de sus ideas, conocimientos, etc. En este caso, el “Dev Team” necesita la confianza y el apoyo del “Product Owner” para crear algo nuevo. Para ello, el “Product Owner” puede utilizar el “acceptance criteria” para inspirar al “Dev Team” y describirlo utilizando expresiones como “Inventar algo magnífico”, “Un diseño de genio” o “Crear al superior”. Con este tipo de expresiones, el “Product Owner” está mandando un mensaje inconsciente al “Dev Team”: “No se lo que quiero exactamente, pero confío en vosotros y estoy seguro de que encontraréis una solución”. Porque el “Product Owner” no sabe lo que quiere, pero cree en el “Dev Team” para crear resultados asombrosos.
  • Cuando sabemos lo que queremos, pero no tenemos suficiente información para formular el “acceptance criteria”. Estamos atascados porque nos falta el conocimiento sobre la materia o nuestro cliente no sabe lo que quiere, etc. Hay tanta incertidumbre, que no tiene sentido intentar hacer ese requisito en particular porque no iremos a ninguna parte. En este caso, podemos utilizar un “Spike”. Un “Spike” es una cantidad de tiempo dada al “Dev Team” para investigar sobre aquello que resulta tan complejo y disminuir incertidumbre, tanto como sea posible. Queremos desatascar la situación para saber cual es el siguiente paso a seguir después del “Spike”, de tal manera que sea posible formular un “acceptance criteria” y trabajar de cara a un objetivo más claro.

Cabe recordar, que respetar los 3 pilares básicos de Scrum (transparencia, inspección y adaptación) y los “Scrum Values” (coraje, franqueza, respeto, compromiso y concentración) es fundamental para ser capaz de utilizar el enfoque apropiado para cada requisito. Sino, el equipo Scrum tiene altas probabilidades de fracasar al intentar conseguir sus objetivos.

Estos son los enfoques que he utilizado durante mi experiencia en un equipo de desarrollo Scrum. Pero estoy seguro de que hay muchos más que no he vivido. Si crees que puedes aportar otros enfoques en un ámbito de investigación y desarrollo, te invitamos a enviarnos un mensaje con tus propuestas. Apreciamos mucho tu feedback!