top of page
Buscar

Justificación del Negocio en la metodología Scrum

  • mateosolorzanov
  • 12 oct 2024
  • 7 Min. de lectura

4.1 Introducción

  • Propósito: El objetivo es asegurar que cualquier proyecto dentro de un entorno Scrum esté justificado desde el punto de vista del negocio, garantizando que aporta valor antes de invertir recursos.

  • Importancia: La justificación del negocio es crucial para que los tomadores de decisiones entiendan la necesidad de cambios o nuevos productos/servicios.

  • Aplicabilidad: La justificación del negocio se aplica a cualquier industria y tipo de proyecto (productos, servicios, etc.), y es relevante para proyectos de cualquier tamaño, desde pequeños hasta grandes proyectos complejos.

  • Relación con el Product Owner: El Product Owner utiliza esta justificación para crear un backlog priorizado del producto, que se ajuste a las expectativas de los interesados y la alta gerencia.

4.2 Guía de roles

  • Product Owner: Tiene la principal responsabilidad de la justificación del negocio, ya que prioriza el backlog y asegura que los proyectos generen valor empresarial.

  • Scrum Master: Debe estar familiarizado con las secciones clave del capítulo (entrega basada en valor, justificación continua, y realización de beneficios). Facilita el trabajo del equipo y gestiona los riesgos e impedimentos.

  • Equipo Scrum: Colabora en la entrega de valor mediante la creación de entregables y participa en la identificación de riesgos, así como en la mejora de procesos en las retrospectivas.

Figura 1. El Equipo Scrum conformado por el Product Owner, Scrum Master y Desarrolladores

4.3 Entrega basada en valor

Un proyecto busca crear nuevos productos o servicios que aporten valor al negocio. En Scrum, la entrega anticipada y continua de valor es crucial.

Debido a la incertidumbre de los resultados en proyectos, es fundamental entregar valor lo antes posible. Esto facilita la retroalimentación y ajustes, así como la gestión del cambio y riesgos.

A fin de ofrecer una entrega basada en valor, es fundamental:

  • Entender lo que agrega valor a los clientes y usuarios y dar prioridad a los requerimientos de alto valor que encabezan el backlog priorizado del producto.

  • Disminuir la incertidumbre y atender constantemente los riesgos que potencialmente pudieran reducir el valor en caso de materializarse.

  • Crear entregables basados en las prioridades determinadas por la producción de incrementos del producto potencialmente entregables durante cada sprint.


En Scrum, el concepto de la entrega basada en valor hace que el marco de trabajo de Scrum sea muy atractivo para los interesados del negocio y para la alta gerencia. Este concepto es muy diferente en comparación a los modelos tradicionales de gestión de proyectos.

Figura 2. Diferencia de la entrega de valor entre un proyecto Scrum y un proyecto tradicional


4.3.1 Responsabilidades del Product Owner en la justificación del negocio

La responsabilidad de priorizar y entregar valor de negocio para los proyectos en una organización le corresponde principalmente al Product Owner. Para los programas y portafolios, la responsabilidad recae en el Program Product Owner y en el Portfolio Product Owner, respectivamente. Como se muestra en la siguiente figura, muestra las responsabilidades de la justificación del negocio de los Propietarios del Producto.

Figura 3. Responsabilidades en la justificación del negocio del Product Owner


4.3.2 Responsabilidades de otros roles de Scrum en la justificación del negocio

Personas en proyectos de Scrum que también contribuyen considerablemente en la justificación del negocio son:

  1. El patrocinador proporciona los fondos para el proyecto y supervisa constantemente el proyecto para confirmar el logro de los beneficios.

  2. Los clientes y usuarios participan en la definición de la lista priorizada de los requisitos y de las historias de usuario en backlog priorizado del producto.

  3. El Scrum Guidance Body puede proporcionar directrices y recomendaciones relacionadas a las técnicas de justificación del negocio.

  4. El Scrum Master facilita la creación de entregables del proyecto.

  5. El Equipo Scrum trabaja en la creación de entregables del proyecto y contribuye a la creación de valor del negocio para todos los interesados del negocio y en el proyecto.

Figura 4. Los clientes, Equipo Scrum y Scrum Master que contribuyen a la justificación del negocio

4.4 La importancia de la justificación del negocio

La justificación responde a la pregunta: “¿Por qué es necesario este proyecto?" Debe ser evaluada constantemente durante el ciclo de vida del proyecto.


4.4.1 Factores para determinar la justificación del negocio

Existen numerosos factores que un Product Owner debe tomar en cuenta para determinar la justificación del negocio de un proyecto. Estos son:

  • Razonamiento del proyecto: Por qué el proyecto es necesario (p.ej., satisfacción del cliente, utilidad, o necesidades legales).

  • Beneficios del proyecto: Mejoras cuantificables derivadas de la finalización exitosa del proyecto.

  • Costo de oportunidad: El valor de la segunda mejor opción descartada.

  • Riesgos mayores: Riesgos que pueden comprometer el éxito del proyecto.

  • Plazos y costos del proyecto: Duración y costos necesarios para obtener los beneficios.


4.4.2 La justificación del negocio y el ciclo de vida del proyecto

Antes de iniciar un proyecto, primero se evalúa la justificación del negocio y se verifica constantemente durante todo su ciclo de vida. La forma de captar la justificación del negocio es:

  • Evaluar y presentar un caso de negocio: La justificación del negocio para un proyecto normalmente la analiza y la confirma el Product Owner.

  • Justificación continua de valor: Una vez que los tomadores de decisiones aprueban la declaración de la visión del proyecto, esta se utiliza como base de referencia y forma la justificación del negocio.

  • Confirmar la realización de beneficios: El Product Owner confirma el logro de los beneficios organizacionales durante el proyecto y al completar las historias de usuario en el backlog priorizado del producto.

Figura 5. Justificación del negocio y el ciclo de vida del proyecto

4.5 Técnicas de justificación del negocio

Las siguientes secciones abordan algunas de las herramientas que se utilizan para valorar y evaluar la justificación del negocio, así como otros aspectos relacionados a la justificación y selección del proyecto. No es necesario, ni se recomienda utilizar todas las técnicas disponibles para cada proyecto.


4.5.1 Estimación del valor del proyecto

El valor que se obtendrá por medio de los proyectos del negocio puede calcularse con diversos métodos, como:

  • ROI (Retorno de la inversión): Calcula los ingresos netos previstos en comparación con los costos del proyecto.

  • NPV (Valor presente neto): Determina el valor actual de los futuros beneficios esperados, considerando inflación o tasas de interés.

  • IRR (Tasa interna de retorno): Evalúa la tasa de retorno de un proyecto comparando sus flujos de efectivo.

4.5.2 Planificar según el valor

Después de justificar y confirmar el valor de un proyecto, el Product Owner debe considerar las políticas de la organización, los procedimientos, las plantillas y las normas generales dictadas por el Scrum Guidance Body (SGB) en la planificación de un proyecto. Algunas herramientas dictadas por el SGB son mapeo de flujo de valor, análisis de Kano o esquemas de priorización MoSCoW ayudan a identificar los elementos que aportan más valor al cliente.

Figura 6. Mapeo de flujo de valor como herramienta para aportar valor al cliente


4.5.3 Clasificación de priorización relativa

La clasificación de priorización relativa (Relative Prioritization Ranking) es una simple enumeración de historias de usuario por orden de prioridad. El objetivo es crear una lista simple, con el único objetivo de dar prioridad a las características, en vez de distraerse con múltiples esquemas de priorización.


4.5.4 Mapeo de historias

El mapeo de historias (Story Mapping), es una técnica para proporcionar un esquema visual del producto y sus componentes clave. El mapeo de historias que se muestra en la figura 7 se muestra cómo el Equipo Scrum planea las distintas liberaciones y les asigna una mayor prioridad a las liberaciones a corto plazo. Se espera que el equipo entienda mejor las historias de usuario en la siguiente liberación, y entre más separadas estén las liberaciones, más probabilidades hay de que cambien las futuras liberaciones.

Figura 7. Técnica de mapeo de historias

4.6 Justificación continua de valor

Es fundamental revisar constantemente si el proyecto sigue siendo viable y si sigue generando valor. El Product Owner juega un rol clave en esta evaluación continua.

4.6.1 Análisis del valor ganado (EVA) Mide el rendimiento real del proyecto comparado con el plan, utilizando gráficos visuales como la curva S.

Algunas fórmulas que se usan para calcular el valor ganado son:

Figura 8. Formulas del valor ganado


4.6.2 Diagrama de flujo acumulado (CFD)

Ayudan a visualizar el progreso del proyecto y detectar cuellos de botella en el proceso. Un ejemplo del uso del CFD es la figura 9, el cual es la aplicación del CFD para un proyecto grande.

Muestra cuántas historias de usuario están por crearse, las que están en proceso de creación y las que ya se han creado. A medida que cambian los requisitos de los clientes, se produce un cambio en las historias de usuario acumuladas que serán entregadas. Los puntos de cambio 1 y 2 son donde el Product Owner ha eliminado las historias de usuario existentes del backlog priorizado del producto, ajustado al riesgo, mientras que los puntos de cambio 3 y 4 son donde el Product Owner agregó nuevas historias de usuario a dicha lista.

Figura 9. Ejemplo de diagrama de flujo acumulado (CFD)

4.7 Confirmar la realización de beneficios

A lo largo del proyecto es importante verificar si se están logrando los beneficios. Ya sea si los productos de un proyecto Scrum son tangibles o intangibles, se requieren técnicas adecuadas de verificación para confirmar que el equipo esté creando los entregables que lograrán los beneficios y el valor definido al inicio del proyecto.


4.7.1 Prototipos, simulaciones y demostraciones

  • Prototipos y simulaciones: Permiten demostrar las funcionalidades a los clientes para validar si estas cumplen sus expectativas.

  • IKIWISI: ("Lo sabré cuando lo vea"). Los clientes a menudo no pueden definir completamente sus requisitos hasta que ven el producto funcionando.

4.8 Resumen de responsabilidades

El resumen de las responsabilidades que se vieron se muestra en la siguiente figura:

Figura 10. Resumen de las responsabilidades pertinentes a la justificación del negocio

4.9 Scrum vs. Gestión tradicional de proyectos

  • Planificación tradicional: Se basa en una planificación extensiva inicial, con cambios que son difíciles de gestionar y el valor entregado al final del proyecto.

  • Planificación en Scrum: Es iterativa, permitiendo una mayor flexibilidad y adaptabilidad a los cambios. La entrega temprana y continua de valor reduce costos y aumenta el ROI. Además, aunque un proyecto se cancele antes de completarse, Scrum garantiza que al menos se entregue una versión funcional con las características mínimas de mercado (MMF).


Figura 11. Metodología Scrum vs Metodología tradicional


 
 
 

Comments

SUSCRIBETE

bottom of page