Como hacemos Pilas de Producto

La pila de producto es el corazón de Scrum. Es donde empieza todo. La Pila de Producto es, básicamente, una lista priorizada de requisitos, o historias, o funcionalidades, o lo que sea. Cosas que el cliente quiere, descritas usando la terminología del cliente. Llamamos a esto historias, o a veces simplemente elementos de la Pila.

Nuestras historias incluyen los siguientes campos:

• ID – un identificador único, simplemente un número auto-incremental. Esto nos permite no perder la pista a las historias cuando cambiamos su nombre.
• Nombre – una descripción corta de la historia. Por ejemplo, “Ver tu historial de transacciones”. Suficientemente claro como para que el Dueño de Producto comprenda aproximadamente de qué estamos hablando, y suficientemente clara como para distinguirla de las otras historias. Normalmente, 2 a 10 palabras.
• Importancia – el ratio de importancia que el Dueño de Producto da a esta historia. Por ejemplo, 10. O 150. Más alto = más importante. Suelo evitar el término “prioridad” porque típicamente “1” se considera la “máxima prioridad, lo que es muy incómodo si posteriormente decides que algo es más importante. ¿Qué prioridad le daríamos a ese nuevo elemento? ¿Prioridad 0? ¿Prioridad -1?
• Estimación inicial – la valoración inicial del Equipo acerca de cuanto trabajo es necesario para implementar la historia, comparada con otras historias. La unidad son “puntos de historia” y usualmente corresponde a “días-persona ideales”. Pregunta al Equipo: “si tuvierais el número óptimo de personas para esta historia (ni muchos ni pocos, típicamente 2) y os encerraseis en una habitación con cantidad de comida, y trabajaseis sin distracciones, ¿en cuantos días saldríais con una implementación terminada, demostrable, testeada y liberable?”. Si la respuesta es “con 3 tíos encerrados en una habitación nos llevaría 4 días”, entonces la estimación inicial son 12 puntos. Lo importante no es que las estimaciones absolutas sean correctas (es decir, que una historia de 2 puntos deba durar 2 días), lo importante es que las estimaciones relativas sean correctas (es decir, que una historia de 2 puntos debería durar la mitad que una historia de 4 puntos).
• Como probarlo – una descripción a alto nivel de como se demostrará esta historia en la Demo al final del Sprint. Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, y entonces debería ocurrir aquello”. Si practicáis TDD (Test-Driven Development, desarrollo orientado a test) esta descripción puede usarse como pseudo-código para vuestro test de aceptación.
• Notas – cualquier otra información, clarificación, referencia a otras fuentes de información, etc. Normalmente muy breve.

Pila de producto (ejemplo)

Hemos experimentado con muchos otros campos, pero al final estos seis campos son los únicos que realmente se usaban Sprint tras Sprint.

Mantenemos esta tabla en un documento Excel con “compartir” habilitado (es decir, muchos usuarios pueden editar simultáneamente la hoja). Oficialmente, el Dueño de Producto es el propietario del documento, pero no queremos dejar al resto de usuarios fuera. Muchas veces un desarrollador necesita abrir el documento para clarificar algo o cambiar una estimación.

Por la misma razón, no colocamos este documento en el repositorio de control de versiones; en vez de eso, lo almacenamos en una unidad de red compartida.

Esta ha demostrado ser la manera más simple de permitir múltiples editores diferentes sin causar problemas de bloqueo o fusión de documentos.

Sin embargo, casi todos los demás artefactos se colocan en el repositorio de control de versiones.