El refinamiento de la cartera de productos (PBR) es el proceso continuo de mejorar la lista de trabajo (de software) por realizar. La PBR es la piedra angular para decidir qué se debe hacer y en qué orden. En este artículo describimos las principales actividades de refinamiento de la cartera de productos y cómo se pueden acelerar con el analizador de requisitos inteligente de ScopeMaster®.
Refinamiento de la cartera de productos
El refinamiento de la cartera de productos es la actividad habitual que realiza la mayor parte o todo el equipo en una reunión con el objetivo de preparar actividades para las próximas iteraciones. Las actividades clave son:
- Aclarando historias de usuarios, para que el equipo tenga un entendimiento común de ellos.
- Dividiendo historias que son demasiado grandes para caber en una iteración.
- Creando nuevas historias de usuario y eliminando otros según nuevos conocimientos.
- Asignación de estimacións a historias
- Asignar prioridades a historias
El refinamiento de la cartera de productos es una actividad costosa y que requiere mucho tiempo, y que normalmente consume entre 5 y 151 TP3T del tiempo total de trabajo de los equipos. Sin embargo, es absolutamente esencial ya que es el paso clave para garantizar que el equipo trabaje en lo correcto. Si no se dedica suficiente tiempo y esfuerzo a esto, el equipo perderá tiempo en actividades equivocadas, lo que puede resultar aún más costoso.
Veamos cada una de estas actividades de PBR con un poco más de detalle y veamos cómo la automatización puede ayudar.
¿Qué hay en la cartera de productos?
Una cartera de productos generalmente contiene historias de usuarios (que describen la funcionalidad), epopeyas de alta granularidad e historias de usuarios más detalladas. El trabajo pendiente del producto debe excluir otras tareas que puedan estar involucradas pero que no proporcionen directamente la funcionalidad al usuario.
Actividades de Refinamiento del Backlog:
1. Aclarar historias de usuarios
El idioma inglés es inmensamente flexible. Tenemos muchas palabras alternativas para lo mismo. Podemos cambiar el orden de las palabras para alterar el significado y cambiar cómo se interpretará la historia. Las variaciones son casi infinitas, incluso una historia de usuario de 12 palabras tiene 87 mil millones de permutaciones en el orden de las palabras. Con cada variación, es probable que la interpretación del lector sea ligeramente diferente. E incluso entonces, la interpretación de cada individuo de la historia de un usuario depende de su propio vocabulario y capacidad lingüística. Es más que probable que dos personas que lean una historia de usuario tengan interpretaciones diferentes.
Si los miembros del equipo no comparten una comprensión común de un elemento del trabajo pendiente, es probable que quienes trabajen posteriormente en él pierdan tiempo construyendo o probando algo incorrecto. Por lo tanto, una comprensión coherente por parte de todo el equipo es esencial para minimizar el esfuerzo desperdiciado.
De acuerdo a scrum.org "Por lo general, un elemento del Product Backlog pasa por tres reuniones de refinamiento antes de que se considere que está listo". Para que esta discusión sea fructífera, cuanto mejor sea la calidad de la historia que llega a la reunión, menos tiempo se perderá.
La mayoría de los elementos del trabajo pendiente describen la intención funcional, el OMS y Qué de la historia del usuario. Aquí es donde ScopeMaster puede eliminar completamente la ambigüedad en una fracción del tiempo, eliminando largas discusiones.
2. Dividir historias para que quepan en un sprint
Las historias de usuarios ágiles deben completarse en una sola iteración o sprint (normalmente dos semanas). No se debe permitir que la finalización de una sola historia abarque dos sprints. La finalización también debe incluir todas las pruebas unitarias. Si una historia es demasiado larga, es necesario dividirla en trozos pequeños. Normalmente, un desarrollador podrá crear (incluidas las pruebas unitarias) alrededor de 8 puntos de función COSMIC (CFP) por sprint. Esta estimación de productividad individual varía significativamente, pero si una sola historia excede los 8 CFP, debe compartirse entre más de un miembro del equipo y/o dividirse en “porciones” más pequeñas, cada una de las cuales puede completarse dentro de un sprint/iteración.
La capacidad de ScopeMaster para detectar el tamaño funcional proporciona una estimación inmediata de si es necesario dividir una historia.
3. Crear nuevas historias de usuarios y eliminar otras.
Los equipos de software deben adaptarse a las demandas cambiantes del negocio. Durante el refinamiento del trabajo pendiente, será necesario dividir algunas historias, crear otras nuevas y eliminar otras. Esto garantiza que el trabajo que se realiza se dirija a la necesidad empresarial tal como se conoce actualmente. Crear nuevas historias para satisfacer las demandas cambiantes está bien, pero los cambios deben mantenerse bajos siempre que sea posible, ya que los niveles excesivos de cambio perturban al equipo. Muchas “incógnitas” son, de hecho, “conocibles”. Los cambios deberían limitarse a aquellas cosas que inicialmente eran incognoscibles. Siempre que sea posible, resulta útil anticipar los requisitos generales lo antes posible. Esto ayuda a planificar el trabajo del equipo de manera más eficiente.
La capacidad de ScopeMaster para analizar un conjunto de historias de usuarios en busca de funcionalidades faltantes o duplicadas permite al equipo obtener una mejor comprensión del alcance general mucho antes.
4. Asignar estimaciones a historias
La estimación de historias es quizás uno de los aspectos que consume más tiempo en el refinamiento de la cartera de productos. Por lo general, esto implica jugar juegos de “póquer de historias”, donde los participantes del equipo adivinan el esfuerzo requerido para contar la historia en tallas de camiseta o, más tarde, en puntos (arbitrarios) de la historia. No sólo lleva mucho tiempo sino que es tedioso, subjetivo, inconsistente y de poca utilidad para la gestión de proyectos, especialmente en proyectos de gran escala. Además, las estimaciones de los puntos de la historia suelen ser "trucadas" para lograr un resultado particular.
La capacidad de ScopeMaster para estimar al instante Las historias de usuario de tamaño funcional (en puntos de función COSMIC) significan que el equipo necesita dedicar muy poco tiempo en las reuniones a discutir el tamaño de la historia. El tamaño funcional de la historia refinada es un valor consistente, estandarizado e inmutable. Esto libera tiempo al equipo para discutir las mejores formas de cómo para entregar la historia de la manera más eficiente.
5. Asignar prioridades a las historias
Dar prioridad a las historias es una consecuencia de lo importantes que son para el negocio, de qué otras historias dependen y cuánto esfuerzo requerirán para entregarlas. Si las otras actividades de refinamiento del trabajo pendiente ya se han automatizado parcial o mayoritariamente, el equipo puede dedicar más tiempo a discutir esto en las reuniones de refinamiento del trabajo pendiente. Esto ayudará a garantizar que el equipo haga lo lo más importante cosas en el orden correcto.
