Plantilla de tabla para el Product Backlog
Me gustaría mostrarte una forma muy sencilla de representar User Stories en un Product Backlog en formato de tabla. La idea surgió después de encontrarme con uno de mis viejos Product Backlogs de hace nueve años y pensar: "Vaya, en comparación con lo que hago hoy, está bastante obsoleto". Así que aquí te muestro una plantilla para un Product Backlog en forma de tabla (por ejemplo, Excel).
Como quizás ya sepas, soy un gran fan de escribir el Backlog con ayuda de User Stories y estructurar estas User Stories de la siguiente manera:
"Como ______ quiero ______, para que ________"
Eso podría verse así: "Como viajero frecuente, quiero poder acceder a Internet durante el vuelo, para poder actualizar mi blog también durante el viaje, en lugar de solo guardar un documento de texto con el que actualizaré el blog después". (¿Puedes adivinar dónde escribí esto?)
Al trabajar con una tabla Excel, encuentro más fácil tomar los elementos de texto de las User Stories como encabezados de columna. De esta manera se obtienen los encabezados "Como", "quiero" y "para que". La esencia de cada Story queda bien visible. También se pueden añadir más columnas, por ejemplo, para numeración, notas, estado, etc. En el siguiente ejemplo también he añadido una columna para el tema general de cada Story.
| ID | Tema | Como… | quiero… | para que… | Notas | Prioridad | Estado |
| 2 | Juego | Moderador | crear un nuevo juego ingresando un nombre y una descripción opcional | pueda invitar a otras personas a estimar | Si no se pueden guardar los juegos y volver a ellos, la descripción no es necesaria | requerido | hecho |
| 2 | Juego | Moderador | invitar a otras personas a estimar dándoles una URL con la que puedan unirse al juego | podamos comenzar el juego | La URL debe tener un formato que permita compartirla fácilmente por teléfono | hecho | |
| 5 | Juego | Estimador (persona que debe realizar una estimación) | unirme a un juego ingresando mi nombre en la página para la que recibí la URL | pueda participar en el juego | hecho | ||
| 6 | Juego | Moderador | iniciar una ronda ingresando un ítem en un campo de texto de varias líneas | podamos estimarlo | hecho | ||
| 8 | Juego | Estimador | ver el ítem que debe ser estimado | sepa para qué estoy dando una estimación | hecho | ||
| 40 | Juego | Participante | tener las cartas siempre en el mismo orden al sacarlas varias veces | sea más fácil comparar estimaciones | Reemplazado por A08 para que la Story no hable de "el mismo orden", porque eso puede ser un detalle de UI | hecho | |
| 35 | no funcional | Usuario | que la aplicación reaccione rápidamente a mis acciones | no me aburra | hecho | ||
| 36 | no funcional | Usuario | buenas páginas de error cuando algo sale mal | pueda confiar en el sistema y sus desarrolladores | hecho | ||
| A11 | no funcional | Investigador | que los resultados se guarden de forma no identificable | pueda estudiar datos, como por ejemplo si las estimaciones se parecen a la primera opinión del "Estimador A" | No se deben guardar nombres ni texto, pero sí cada carta, quién la jugó y la estimación final | ||
| A05 | Juego | Moderador | modificar uno de los ítems a estimar | refleje mejor la comprensión del equipo sobre el ítem | |||
| 22 | Archivo | Moderador | exportar los datos de un juego como archivo CSV | pueda seguir trabajando con las Stories y las estimaciones | El archivo exportado debería poder importarse directamente de vuelta al sistema | hecho |
Mi estructura favorita para User Stories
=> Escribir User Stories
