Scrum es un framework ágil para crear productos digitales de forma iterativa e incremental. Comienza con una lista priorizada por el cliente de los incrementos deseados de las características del producto (un Backlog del producto) que se agregan periódicamente al producto, generalmente un período de una o dos semanas (un Sprint).

Todo comienza con el Backlog del Producto, aunque Scrum no tiene una definición de cómo construir un Backlog. Por lo tanto, estas son preguntas comunes:

  • ¿Cómo llegar a un Backlog?
  • ¿Cómo construir algo que tenga valor?
  • ¿Cómo satisfacer las necesidades reales del cliente?
  • ¿Cómo definir qué es prioridad para el cliente en el primer momento?

Intentando responder a estas preguntas, después de muchos años trabajando dentro de varios contextos y organizaciones, Fabio Aguiar creó el “PBB – Product Backlog Building“. El objetivo principal de PBB es ayudar a construir el backlog de producto de manera colaborativa, basada en una comprensión compartida del contexto del producto y las necesidades del usuario.

La dinámica de PBB consiste en construir el Backlog del Producto a través de una herramienta de facilitación, el PBB Canvas. Esta dinámica lleva a todos los interesados ​​en comprender, planificar y priorizar las características del producto a un taller práctico para diseñar y definir una cartera de productos efectiva que esté totalmente alineada con las necesidades del cliente y los valores comerciales.

Los principales beneficios de PBB son:

  • Asistir en la creación de un  backlog de productos de una manera efectiva y colaborativa.
  • Desarrollar una comprensión compartida de las necesidades del cliente, facilitando el descubrimiento del producto.
  • Describa la experiencia del usuario y su relación con las características del producto.
  • Facilitar el descubrimiento y la redacción de las historias de usuario.

PBB se logra siguiendo unos pocos pasos para facilitar la comprensión de las necesidades del cliente y el contexto de las características del producto.

Estos pasos están representados en una sola página, el PBB Canvas. Los siguientes son los pasos principales de PBB Canvas:

  1. Contextualizar el producto
  2. Describe las personas
  3. Comprender las características
  4. Mapa de los pasos de una característica
  5. Identifique los itens del backlog

 

Contextualizar el producto

Al principio, es importante aclarar y comprender cuál es el producto. Debe comprender los problemas y el estado deseado. Esto ayudará a comprender las expectativas y aclarar los objetivos principales.

NOMBRE DEL PRODUCTO: identifique el producto que se construirá. Imagine que este producto estaba en una caja; ¿Qué nombre se escribiría en la caja?

PROBLEMAS: Identifique y comprenda el estado actual señalando un conjunto de problemas y dolores en el contexto en cuestión. En esta etapa, los participantes deben buscar en colaboración la comprensión del estado actual describiendo los problemas y las necesidades. Comprender los problemas es esencial antes de encontrar una solución.

EXPECTATIVAS: Identifique el estado deseado alineando las expectativas relacionadas con los problemas actuales del estado. Evite describir la solución en detalle sobre cómo lograremos el estado deseado; en su lugar, enumere las expectativas (generalmente relacionadas con la eliminación o los cambios en los problemas del Estado actual).

Describa las Personas.

Una persona representa a un usuario del producto, describiendo no solo el rol sino también sus necesidades específicas. Esto crea una representación realista de los usuarios, ayudando al equipo a describir características desde el punto de vista de quién interactuará con el producto final.

PERSONA: Identificar los usuarios, roles y personas involucradas en el producto; Describa lo que hacen y esperan del producto.

Comprender las features

La feature es una descripción de la acción o interacción de un usuario con el producto. Por ejemplo: imprimir factura, ver extracto detallado e invitar amigos de Facebook. La descripción de una feature debe ser lo más simple posible. El usuario está intentando hacer algo. El producto debe tener una feature para ello. ¿Qué feature es esta?

Ejemplo de feature: comprar producto en línea

Haga las siguientes preguntas para cada una de las personas identificadas: ¿Qué hace esa persona? ¿Y qué espera esa persona? Por lo general, las respuestas describen las acciones o interacciones del usuario con el producto: las features.

FEATURES: Identifique las features que cada persona realiza en el producto, organizadas en secuencia de uso (de izquierda a derecha). Describa cada feature con una breve descripción; A continuación, describa los “Problemas” y los “Beneficios” relacionados con cada característica. Escriba los problemas de la función y los beneficios de la features en notas post-it más pequeñas y colóquela en el lado izquierdo y derecho del post-it con la descripción de la feature.

Consejo: limite el número total de features a un máximo de 10; más que eso crea un gran inventario, no una acumulación. Si hay una cantidad considerable de features, aplique algún método de priorización para seleccionar las diez features principales

Mapear los pasos de una Feature

Steps Maps es una técnica que ayuda a dividir una feature en iteraciones de trabajo pequeñas. Cada paso será un PBI – Artículo de Backlog del producto.

Los PBIs son itens que componen el backlog de productos. Idealmente, los PBIs reflejan las necesidades del cliente y del negocio, que pueden variar en especificaciones y requisitos. Por lo general, estos están representados por casos de uso, epopeyas, historias de usuarios o incluso errores o tareas.

La ruptura de una feature se realiza a través de los pasos del mapa, que representan una asignación de los elementos de trabajo de una entidad.

Comience preguntando el primer paso de trabajo para comenzar con la función. Escríbelo. Luego pregunte sobre el segundo paso de trabajo. Luego, el tercero y así sucesivamente, hasta completar el flujo de trabajo de la función, paso a paso. Tenga en cuenta que cada elemento de trabajo representa un paso hacia la construcción de entidades.

Por ejemplo, considere la feature de muestra: Realizar compra en línea. ¿Cuál es la feature primer paso? Para realizar una consulta de producto; ¿Que despues? Para hacer la selección del producto; luego hacer el pago del producto y así sucesivamente. Estos son los mapas de pasos.

Identificar los itens del backlog

En el momento de la construcción del backlog, la sugerencia es representar cada PBI por el modelo ARO: la representación comienza con un verbo, seguido del resultado deseado, y termina con el objeto dentro del contexto. Luego, puede convertir cada PBI en una historia de usuario, la representación más común para describir lo que debe hacerse para satisfacer las necesidades del usuario final.

ARO Acción-Resultado-Objeto

Del artículo original: “[Acción] el [resultado] [por | para | de | a] un (n) [objeto] Como ejemplos, considere estos:
  • Estime el precio de cierre de las acciones.
  • Generar un identificador único para una transacción.
  • Cambiar el texto que se muestra en un quiosco
  • Combinar los datos para transacciones duplicadas “
Lea más sobre el modelo ARO aquí.

PBI: para cada feature, escriba sus respectivos PBI. Primero, escriba en el modelo ARO, y luego represente cada PBI como una historia de usuario. Organice los elementos verticalmente, donde el más alto tenga la mayor prioridad.

Scrum no especifica cómo representar cada elemento en el Backlog, por lo que puede escribirlo de varias maneras. User Story es la forma más utilizada por los equipos ágiles de hoy para representar un elemento en el Backlog. Una historia de usuario es una breve descripción de lo que se requiere que un cliente tenga en el producto, que básicamente responde a 3 preguntas: ¿QUIÉN? ¿QUÉ? ¿POR QUÉ?

Ayuda de PBB para escribir las historias de usuario. Como puede ver en el PBB Canvas, tenemos el “¿QUIÉN?” ¿Cuál es la persona, el “QUÉ?” ¿Cuáles son en este caso los PBI ya representados en el modelo ARO y, por último, el “POR QUÉ?” ¿Cuál es el objetivo? y beneficios que la persona destacó en el bloque de características. La siguiente figura ofrece una ilustración simple de lo fácil que es escribir User Story con la ayuda de Product Backlog Building.

El mayor beneficio de Product Backlog Building es la facilitación y colaboración que brinda a todos los involucrados en la creación de un Backlog. Por lo tanto, ¡creemos una increíble cartera de pedidos con elementos de cartera muy bien estructurados!

>> Download the PBB Canvas

>> Check out the PBB Canvas Tip Sheet