Especificación de producto para equipos Scrum

Se requiere que el propietario del producto desarrolle una hoja de ruta de lanzamiento

Contrariamente a la creencia popular, Scrum no significa una gestión del asiento de los pantalones sin planificación previa. El propietario del producto debe desarrollar una hoja de ruta de lanzamiento. Sin embargo, hay dos requisitos clave para una hoja de ruta de lanzamiento en Scrum:

1. La línea de tiempo en la hoja de ruta del lanzamiento debe basarse en la velocidad real del equipo.
2. Debe quedar claro que el próximo lanzamiento está definido, pero más adelante hay un pronóstico que cambiará según las condiciones del mercado y las firmas de contratos de los clientes.

Si necesita ayuda con el proceso de desarrollo de dicha hoja de ruta de lanzamiento y el formato para presentarla, puedo recomendar la hoja de ruta de producto orientada a objetivos (GO) de Roman Pichler.

Para mí, la palabra preocupante aquí es "especificación". No sé qué significa en su organización, pero estoy acostumbrado a que signifique una descripción completa del alcance del producto. El equipo de desarrollo debería tratar de resolver las necesidades de su usuario, no cumplir con una lista de requisitos en un documento de especificaciones. Nuevamente, no sé qué es una especificación de producto en su organización, pero la preocupación sería que está trabajando con un proyecto de alcance fijo donde los desarrolladores son recompensados ​​​​por completar tareas según una especificación, no por crear software valioso.

Como mencionó Ashok, una hoja de ruta puede ser muy útil. Sin embargo, recuerda que en Agile valoramos responder al cambio por encima de seguir un plan. Cada paso del proyecto es una oportunidad para aprender más sobre las necesidades de su cliente. Como tal, la mayoría de los proyectos descubren que su hoja de ruta es incorrecta en algún momento del proyecto. Es importante que pueda cambiar la hoja de ruta según sea necesario sin una cantidad excesiva de esfuerzo y sin crear problemas para usted mismo en su organización.

La respuesta aquí es lamentablemente... tal vez .

Depende de su organización y del tipo de desarrollo en el que esté trabajando.

En nuestro departamento contamos con Especificaciones de Requerimientos de Negocio además del Backlog de Producto.

La razón de esto es doble

• Tenemos múltiples proyectos que ingresan al mismo Equipo Scrum
• Tenemos dependencias a gran escala que requerimos que otros departamentos completen antes de que el Equipo Scrum comience su trabajo. Dado que requieren un BRS y lo ingresamos, tiene sentido que ayudemos a escribir el BRS y nos aseguremos de que nuestro Backlog sea reflexivo.

Por ejemplo, nuestro departamento maneja el Almacén comercial front-end y el Desarrollo de objetos comerciales y el Propietario del producto puede hablar en nombre del negocio.

Sin embargo, los arquitectos de SAP R/3 (por separado) requieren especificaciones detalladas con respecto al trabajo preparatorio de back-end de Business Warehouse. Por lo tanto, se producen las especificaciones de requisitos comerciales, aunque tenemos una cartera de productos más compleja a la que podemos recurrir para la planificación de Sprint a nivel de tarea.

Yo diría que absolutamente debería tener un documento de requisitos detallado si alguno de los siguientes es cierto

• El equipo Scrum está aguas arriba o aguas abajo de otro equipo no ágil que produce el mismo producto o un derivado de ese producto.
• El Equipo Scrum / PO debe anticipar las necesidades comerciales de múltiples proyectos, flujos de trabajo o trabajos pendientes.
• Los procesos de Scrum no tradicionales están diluyendo el marco de Scrum debido a las limitaciones comerciales
• El Product Backlog es un proyecto altamente técnico o complejo y resistente a User Story Breakdown EG SAP Master Data con más de 1000 partes interesadas en todo el panorama global. Hay muy pocas formas de eludir la necesidad de un documento grande que detalle el alcance exacto, fuera del alcance y la gestión de riesgos de este trabajo.

La verdad es que la mayoría de los ejemplos de Scrum siempre usan la explicación más simple posible sin considerar el entorno de trabajo personalizado.

No todos los Backlog pueden ser

Como cliente de Amazon, quiero poder poner artículos en una cesta para pagarlos en el futuro.

Los beneficios de Scrum para nuestro equipo son que podemos responder excepcionalmente rápido a los cambios del proyecto, podemos filtrar y trabajar en varios proyectos a la vez como un backlog fusionado, nuestra planificación de capacidad y el ciclo de sprint brindan cronogramas de planificación más realistas (obtienen un tiempo de iteración caja y pueden hacer algo de trabajo en esa caja, si el trabajo excede la caja, pidan otra caja) y lo más importante podemos fomentar la innovación y el desarrollo multifuncional.

seguramente la especificación del producto debe ser las características y los temas definidos y acordados con el propietario del producto como parte de la visión del producto (o el nombre que desee darle)?

Prefiero no usar 'hoja de ruta' para esto, ya que para mí la hoja de ruta transmite la noción de cómo va a llegar allí, por ejemplo, el plan de lanzamiento.