El libro User Stories Applied: For Agile Software Development de Michael Cohn es uno de los libros de cabecera de todo Product Owner. En él, Michael Cohn, nos muestra cómo crear buenas historias de usuario, qué errores evitar y también cómo priorizarlas para el desarrollo de nuestros productos.
Como Product Owner, aprenderás valiosas lecciones sobre las historias de usuario, estimaciones y otros aspectos que son vitales en tu día a día. De todas estas lecciones, he seleccionado 12 que me han parecido muy interesantes.
12 lecciones para un Product Owner extraídas del libro User Stories Applied
- Role Modelling: uno de los primeros pasos como Product Owner que debes dar junto a tu equipo y cliente es identificar quién utilizará tu producto. Hablamos de los roles. Utiliza una user role card y escribe el nombre de cada rol. Después, junta todos los roles escritos, elimina los duplicados y considera si alguno de ellos puede unirse. Con esto, obtendrás una lista definitiva de los roles de usuario con los que comenzar el proyecto. A partir de ahí, es el momento de que todo el equipo se una para hablar de cada rol y añadir detalles a su user role card correspondiente, basados principalmente en:
La frecuencia con la que el usuario utilizará el software
- El grado de experiencia del usuario
- El nivel general de competencia del usuario con ordenadores y software
- El nivel de competencia del usuario con el software desarrollado
- El objetivo general del usuario que utiliza el software
- Entrevistas: para escribir buenas historias de usuario, debes entrevistar previamente a los usuarios. Elabora cuestionarios con preguntas abiertas orientadas al producto y a su uso para favorecer la conversación. Puedes preguntarles, por ejemplo, con cuánta frecuencia usan las funcionalidades de tu producto o por qué no usan alguna de ellas.
3. Observa cómo los usuarios utilizan tu producto, te ayudará a ver qué puedes mejorar.
4. Realiza un story-writing workshop antes de cada planned Release: es una de las técnicas más efectivas para escribir historias de usuario. A este workshop debe asistir el Developer Team junto al Product Owner. Cada uno escribe historias de usuario, sin llegar a priorizarlas.
5. Limitar el backlog a historias de usuario le permite al Product Owner priorizar de forma más sencilla. Con todos los items en un formato entendible, la toma de decisiones entre una funcionalidad u otra se torna más fácil para el Product Owner.
6. Evita restricciones en las historias de usuario, como por ejemplo “el sistema debe funcionar en toda las versiones de Mac, debe soportar más de 50 usuarios, etc.”.
7. Si te sientes obligado a numerar las historias de usuario, prueba a añadir un título corto a la historia y usarlo para el resto del texto de la propia US.
8. No cambies el sizing de una US al finalizarla por considerar que fue más grande de lo inicialmente estimado.
9. Cuando comienza un sprint, solo el equipo puede añadir trabajo al mismo. Si el equipo considera que tiene tiempo para realizar alguna tarea más, se lo notificará al Product Owner para que les ayude a identificar qué item o items pueden agregar al sprint backlog. Nadie puede pedirle al equipo que añada historias de usuario al sprint, ni el propio Product Owner puede cambiar de opinión y pedir nuevas funcionalidades. En el caso de que en medio del sprint sucediese algo extraordinario que hiciera pensar a la compañía que es necesario realizar cambios, el sprint actual se aborta y comienza uno nuevo tras una sesión de sprint planning.
10. Considera cad bug como una historia de usuario. Si arreglar un bug puede llevar el mismo tiempo que acometer una historia de usuario, este puede ser tratado como tal. En el caso de que solucionarlo lleve menos tiempo, se puede crear una historia de usuario que incluya varios bugs.
11. Requisitos no funcionales, como mantenimiento, capacidad, rendimiento, reusabilidad, etc. a menudo pueden ser tratados como cards de restricción. Si el sistema tiene requerimientos más complejos que estos, complementa el enfoque de tu historia de usuario con otro formato o técnica adicional que exprese mejor estos requisitos.
12. Los pasos esenciales para elaborar un Release Plan son los siguientes y en este orden: elige una duración para la iteración, estima la velocidad, prioriza las historias de usuario y organiza las historias en una o más iteraciones.
Si quieres aprender más sobre cómo crear buenas historias de usuario y cómo mejorar en tu día a día como Product Owner, sin duda, User Stories Applied es un gran libro para comenzar.