Los procesos de Scrum abordan las actividades y el flujo específico de un proyecto Scrum. En total hay diecinueve procesos que se agrupan en cinco fases: Iniciar, Planear y Estimar, Implementar, Revisión y retrospectiva y Lanzamiento.
Los procesos relacionados con la iniciación de un proyecto:
- Create Project Vision—En este proceso, el Project Business Case es revisado para crear un Project Vision Statement que servirá de inspiración y proporcionará un enfoque de todo el project. El Product Owner se identifica en este proceso.
- Identificar al Scrum Master y al/a los stakeholder(s)—En este proceso, el Scrum Master y los stakeholders se identifican utilizando criterios de selección específicos.
- Form Scrum Team—En este proceso, se seleccionan a los miembros del Scrum Team. Normalmente, el Product Owner es el responsable principal de la selección de los miembros del equipo, pero a menudo lo hace en collaboration con el Scrum Team.
- Develop Epic(s)—En este proceso, el Project Vision Statement sirve como la base para el desarrollo de epics. User Group Meetings pueden tomar lugar para discutir el/los Epic(s) apropiado(s).
- Create Prioritized Product Backlog—En este proceso, los Epic(s) son refinados, elaborados, y luego priorizados para crear el Prioritized Product Backlog del proyecto. Lo que se conoce como Done Criteria también se establece en este punto.
- Conduct Release Planning—En este proceso, el Scrum Core Team revisa los User Stories en el Prioritized Product Backlog para desarrollar un Release Planning Schedule, que es esencialmente un program de implementación por fases que se puede compartir con los stakeholders del project. Los Length of Sprints también se determinan en este proceso.
Entradas
Project Business Case
Un caso de negocio (business case) puede ser un documento bien estructurado o simplemente una declaración verbal que expresa la razón para iniciar un project. Puede ser formal y detallado, o informal y breve. Independientemente del formato, a menudo incluye información sustancial sobre los antecedentes del project, los objetivos del negocio y los resultados deseados, un SWOT y Gap Analysis, una lista de los risks identificados, y las estimaciones de tiempo, el esfuerzo y costo.
El project se inicia con la presentación del Project Business Case. Un caso de negocio se le presenta a los stakeholders y patrocinadores (sponsors). Los stakeholders así comprenden los beneficios de negocio esperados de tal project y los patrocinadores confirman que van a proporcionar los recursos financieros para el project.
Program Product Owner
El Program Product Owner es la persona responsable de maximizar el valor del negocio para un program. Él/ella es responsable de la articulación de requisitos de los customers y de mantener business justification para el program y puede aportar de forma importante sobre qué projects deben ser implementados, y de que manera, en un program. El Program Product Owner también administra el Program Product Backlog.
El Program Product Owner interface con el Portfolio Program Owner para asegurar la alineación del programa con las metas y objetivos del portfolio. Él/ella también tiene que ver con el nombramiento de los Product Owners para los proyectos individuales, y debe asegurar que la visión, los objetivos, los resultados, y las liberaciones de los projects individuales en el program estén alineados con los del programa.
Program Scrum Master
El Program Scrum Master es un facilitador que asegura que todos los equipos del project en el program dispongan de un entorno propicio para completar con éxito sus projects. El Program Scrum Master guía, facilita y les enseña las prácticas de Scrum a todos los que participan en el program; también sirve como guía para los Scrum Masters de los distintos projects; elimina los impediments de los diferentes equipos del project; coordina con el Scrum Guidance Body para definir los objetivos relacionados con la normativa de calidad, el gobierno, la seguridad y otros parámetros claves de la organización; y asegura que los procesos de Scrum se estén siguiendo de manera efectiva a lo largo del program.
El Program Scrum Master debe interactuar con el Portfolio Scrum Master para segurar la alineación del program con las metas y objetivos del portfolio. También tiene que ver con el nombramiento del Scrum Masters para projects individuales y debe asegurar que la visión, los objetivos, los resultados, y las liberaciones de los proyects individuales en el program estén alineados con los del program.
Program Stakeholder(s)
Program Stakeholder(s) es un término colectivo que incluye a los customers, los usuarios y patrocinadores para un program. Influyen en todos los projects del program durante todo el desarrollo del project. El/Los Program Stakeholder(s) también puede(n) ayudar a definir la visión del project y a proporcionar orientación en relación con el valor del negocio.
El/Los Program Stakeholder(s) debe(n) interactuar con los Portfolio Stakeholders para asegurar la alineación del program con las metas y objetivos del portfolio. Ellos también están involucrados con el nombramiento del/de los Stakeholder(s) para projects individuales y se aseguran que la visión, los objetivos, los resultados, y los lanzamientos de los projects individuales en el program estén alineados con los del program.
Chief Product Owner
En el caso de grandes projects con numerosos Scrum Teams, podría ser neceario tener un Chief Product Owner. Esta función se encarga de coordinar el trabajo de los múltiples Product Owners. El Chief Product Owner prepara y mantiene el Prioritized Product Backlog para los projects grandes, usándolo para coordinar el trabajo a través de los Product Owners de los Scrum Teams. Los Product Owners, a su vez, gestionan sus respectivas partes del Prioritized Product Backlog.
El Chief Product Owner también se comunica con el Program Product Owner para asegurar la alineación de los projects grandes con las metas y objetivos del program.
Program Product Backlog
El Program Product Owner desarrolla el Program Product Backlog del product que contiene una lista de prioridades de negocios de alto nivel y los requisitos del project escritos preferiblemente en forma de Program Backlog Items del program. Luego, estos son refinados por los Product Owners de los projects individuales, ya que crean y dan prioridad a pedidos pendientes del product para sus projects.
Estos Prioritized Product Backlogs tienen User Stories más pequeños pero detallados que pueden ser aprobados, estimados, y aplicados por miembros del Scrum Team.
El Program Product Owner mantiene de forma continua el Program Product Backlog para garantizar que los nuevos business requirements se añadan y que los requisitos existentes estén debidamente documentados y priorizados. Esto asegura que a los requisitos más valiosos en el cumplimiento de los objetivos del program se les esté dando alta prioridad y que los restantes reciban una prioridad más baja.
El Program Product Backlog creado para el program presenta una imagen más grande de todos los projects que forman parte del program. Por lo tanto, puede servir de orientación en relación con los objetivos del project, el alcance, los objetivos y los beneficios esperados del negocio.
Trial Project
Si es factible, un demo o prueba del project en pequeña escala podría ser ejecutado como un experimento para predecir y evaluar la viabilidad, tiempo, costo, risks, y los posibles efectos del project. Esto ayuda a evaluar el entorno de práctica y guías del diseño del project con anterioridad a la iniciación del project.
Proof of Concept
Proof of Concept demuestra y verifica que la idea detrás del proyecto actual es potencialmente viable en el entorno real. A menudo esto se hace en la forma de un prototipo diseñado para determinar la viabilidad técnica y financiera, ayudar a comprender los requisitos, y ayudar en la evaluación de las decisiones de diseño al principio del proceso. Sin embargo, Proof of Concept no necesita representar necesariamente los verdaderos Deliverables (Entregables) del project.
Company Vision
La comprensión del Company Vision ayuda a que el project mantenga su enfoque en los objetivos de la organización y el futuro probable de la empresa. El Product Owner se puede guiar por el Company Vision para crear el Project Vision Statement.
Company Mission
Company Mission ofrece un marco para la formulación de las estrategias de la empresa y orienta la toma de decisiones en general en la empresa. Project Vision debe enmarcarse de tal manera que su cumplimiento ayuda a la organización a llevar a cabo su misión.
Market Study
Market Study se refiere a la investigación organizada, la recopilación, la comparación y el análisis de datos relacionados con las preferencias de los customers sobre los products. A menudo incluye numerosos datos sobre las tendencias del mercado, la segmentación del mercado y los procesos de comercialización.
Estudio de mercado podría incluir también un estudio analítico de los competidores que proporciona una mejor comprensión de las fortalezas y debilidades de los competidores y puede ayudar a los que toman decisiones a formular productos mejor posicionados.
Recomendaciones del Scrum Guidance Body
El Scrum Guidance Body (SGB) es una función opcional. Por lo general, se compone de un grupo de documentos y/o un grupo de expertos que normalmente están involucrados en la definición de objetivos relacionados con la calidad, las regulaciones gubernamentales, la seguridad y otros parámetros claves de la organización. Estos objetivos guían la labor llevada a cabo por el Product Owner, Scrum Master, y el Scrum Team. El Scrum Guidance Body también ayuda a capturar las mejores prácticas que se deben utilizar en todos los projects Scrum en la organización.
El Scrum Guidance Body no toma decisiones relacionadas con el project. Este actúa como una consultoría o una estructura de orientación para todos los niveles de jerarquía en el project de organización del portfolio, program y project. Los Scrum Teams tienen la opción de pedirle asesoramiento al Scrum Guidance Body.
Es importante asegurarse de que la visión del project esté alineada con las recomendaciones proporcionadas por el Scrum Guidance Body y que los procesos cumplan con las normas y directrices establecidas por el Body (la Administración).
Maria Eugenia Arevalo Lizardo 