Artículos Boletín TenStep

En un proyecto Scrum, son los miembros del Equipo Scrum los responsables de entregar el producto o servicio deseado, y no el Marco Scrum. Por lo tanto debemos ser cuidadosos al crear los Equipos Scrum.

“El Equipo Scrum es a veces conocido como el Equipo de Desarrollo debido a que es responsable del desarrollo del producto, servicio o resultados. Consiste en un grupo de individuos que utilizan las Historias de Usuarios del Backlog del Sprint para crear entregables para el proyecto.” SBOK, edición 2013.

A continuación se describen las características esenciales del Equipo Scrum para entregar los resultados deseados del proyecto.

Autoorganizado: Los miembros del Equipo Scrum son individuos motivados que no esperan que sus superiores les asignen tareas. Ellos toman la responsabilidad, comparten el riesgo, toman decisiones y trabajan colectivamente hacia una meta común.

Empoderado: El Equipo Scrum, o el equipo de desarrollo, recibe los recursos que requiere para entregar los productos o servicios deseados, con la autoridad para tomar decisiones. Si el equipo tiene solo la responsabilidad pero no la autoridad para tomar decisiones, el desarrollo continuo/iterativo es difícil.

Colaboración: La Dirección de Proyectos es un proceso de creación de valor compartido con equipos que trabajan e interactúan juntos para entregar el mayor valor. El Equipo Scrum debería compartir el conocimiento, ideas, riesgos y responsabilidades y trabajar en armonía con los miembros del equipo para entregar los resultados deseados.

Objetivo Compartido: Los individuos dentro del equipo, trabajan de manera colectiva hacia un objetivo común. El objetivo del equipo debe imponerse ante los objetivos individuales tales como crecimiento, evaluación y dinero.

Tamaño Óptimo: Un Equipo Scrum pequeño puede no tener el set de habilidades requerido para desarrollar el producto o servicio y un Equipo Scrum grande puede arruinar el trabajo según la colaboración entre ellos se dificulte. Según se define en el SBOK, el tamaño óptimo de un Equipo Scrum es generalmente de seis a diez personas. Esto asegurará que el Equipo Scrum sea suficientemente grande como para poseer las habilidades necesarias para entregar el proyecto y suficientemente pequeño como para colaborar.

Multifuncional: El Equipo Scrum debería poseer colectivamente las habilidades necesarias para entregar los objetivos del proyecto. Durante la formación del equipo, los miembros deben ser seleccionados manteniendo en mente las habilidades requeridas para entregar los resultados del proyecto.

Co ubicado (Colocated): Es recomendable formar un Equipo Scrum con miembros ubicados en el mismo lugar. Esto asegura la comunicación, colaboración y coordinación entre los miembros del equipo.

Autor: SCRUMstudy

Traducción: Adela Vega, TSPM, SMC, SDC

Adaptación: Enrique Ledesma M.Sc., PMP, CDA, STC, SPOC, SMC, SDC

En un proyecto Scrum, cada Sprint comienza con la Reunión de Planificación del Sprint. El objetivo principal debería ser solamente, planificar el sprint. Debes asegurarte de que todos los miembros, incluyendo el Product Owner y el Scrum Master, participen en la reunión. Puedes también incluir a las personas a tiempo parcial en esta reunión. Esta es una oportunidad importante para el Equipo Scrum de seleccionar cuánto trabajo pueden llevar a cabo en el sprint venidero.

Sobre la base del Cuerpo de Conocimiento de la Guía de Scrum (SBOK Guide), la reunión se limita a ocho horas para un sprint de un mes, y se divide en dos partes: Definición de Objetivos y Estimación de Tareas.

1.- Definición de Objetivos: Durante la primera mitad de la reunión, el Product Owner explica al Equipo Scrum la Historia de Usuario o requisito con la mayor prioridad en el Backlog Priorizado del Producto. Entonces, el Equipo Scrum, en colaboración con el Product Owner, define el objetivo del Sprint.

2.- Estimación de Tareas: Durante la segunda mitad de la reunión, el Equipo Scrum decide “cómo” completar los ítems seleccionados del Backlog Priorizado del Producto para alcanzar el objetivo del Sprint.

Durante las reuniones de planificación del Sprint, se discute sobre las Historias de Usuarios que se ha aprobado, estimado y comprometido. Cada miembro del Equipo Scrum hace una estimación rápida de las tareas, utilizando herramientas tales como Planning Pocker. Si la discusión toma más tiempo, significaría que las Historias de Usuarios no estuvieron completamente listas para que se las asuma en el Sprint.

Cada miembro del equipo Scrum usa también la Lista de Estimación del Esfuerzo por Tarea para seleccionar las tareas en las que ellos planean trabajar en el Sprint, sobre la base de sus habilidades y experiencia. El equipo alcanza consenso acerca de la cantidad de trabajo que requiere incluir en este sprint. Durante las Reuniones de Planificación del Sprint, el Equipo Scrum también crea el Backlog del Sprint y el Gráfico del Trabajo por Realizar, utilizando las Historias de Usuarios y la Lista de Estimación de la Duración de Tareas. El equipo puede comprometerse verbalmente a completar las tareas planificadas para el Sprint.

Trata de evitar hacer las siguientes tareas durante el Sprint. Ellas ayudan con la preparación, y debes estar preparado antes de iniciar la reunión.

Refinar: Ayuda a asegurar que el Refinado de los requisitos y sus Historias de Usuarios se realice con bastante antelación a la Reunión de Planificación del Sprint, de tal manera que el Equipo tenga un set de historias bien analizadas y claramente definidas, que pueden ser partidas fácilmente en tareas y luego, ser estimadas.

Actualizaciones/Revisiones: Las actualizaciones pueden incluir revisiones de las Historias de Usuarios originales, sobre la base de la creación de tareas y factores de complejidad discutidos durante la Reunión de Planificación del Sprint.

La conclusión es que si sigues estos puntos, podrás hacer una planificación efectiva sin perder mucho tiempo.

Autor: SCRUMstudy

Traducción: Adela Vega, TSPM, SMC, SDC

Adaptación: Enrique Ledesma M.Sc., PMP, CDA, STC, SPOC, SMC, SDC

Entregar el máximo valor para el negocio en el período de tiempo más corto posible, está arraigado en el Marco de Scrum. Generalmente, se espera que los proyectos Scrum creen Valor para el negocio o servicio, lo cual hace atractivo al marco Scrum para los interesados del negocio.

Pero, no está claro si el Valor para el Negocio puede alcanzarse a través de reducir los costos incurridos, incrementar la ganancia final, incrementar la satisfacción del cliente, minimizar el riesgo o incrementar la capacidad organizacional.  El Valor para el negocio y su función es una tarea subjetiva que requiere balancear mucha información sobre la base de bastantes prioridades cambiantes. El Propietario del Producto lo utiliza como un indicador para priorizar el Backlog del Producto.

La priorización del Backlog del Producto incluye muchas otras variables y atributos, por lo tanto, la priorización basada en el Valor para el negocio no debería ser el único enfoque. Un buen Product Owner debería comprender profundamente la Visión del Proyecto y tener una buena relación con el cliente y el equipo de desarrollo. El Propietario del Producto también debe tener en cuenta el riesgo y el esfuerzo, mientras prioriza el Backlog del Producto.

De hecho, las empresas difieren en los procesos de venta que determinan el valor potencial de una característica del producto al lanzarla al mercado, y el momento adecuado para vender el producto en el mercado.  Los interesados y la gerencia senior de una empresa deciden qué liberar a continuación para ganar valor. Sin embargo, los Interesados imponen sus deseos individuales sobre los equipos de desarrollo o los Propietarios de Productos según difieran sus prioridades. Se alcanza un acuerdo común entre los interesados con respecto al hecho de que el Propietario del Producto debe ser el responsable general de definir las prioridades.

Se estima el Valor para el negocio de la misma manera en que los desarrolladores estiman la complejidad. El Poker de Estimación ayuda a los Propietarios del Producto e Interesados a reunirse, compartir información relacionada con los Valores para el Negocio. El alcanzar acuerdos trae comprensión y respeto entre ellos y los miembros del equipo.

La práctica de estimar el Valor para el Negocio de cada Historia muestra algunos problemas tales como asignar un valor discreto a pequeñas características o pedacitos de funcionalidades y determinar el costo de las mismas. Sin embargo, eso no significa que debamos hacer un análisis de tasa interna de retorno de las Historias de Usuarios o asignar valor del negocio a las características. Durante tal análisis y estimación, se debe mantener un balance entre el Valor y el costo asociado. Es mejor hacerlo al nivel de Historias de Usuarios grandes.

Autor: SCRUMstudy

Traducción: Adela Vega, TSPM, SMC, SDC

Adaptación: Enrique Ledesma M.Sc., PMP, CDA, STC, SPOC, SMC, SDC

El Scrum Master es el “líder de servicio” del equipo Scrum, quien modera y facilita las interacciones del equipo como el coach y motivador del mismo. El Scrum Master es responsable de asegurar que el equipo tenga un ambiente productivo a través de protegerlo de influencias externas, removiendo cualquier obstáculo y promoviendo los principios, aspectos y procesos Scrum.

Cada proyecto Scrum tiene diferentes requisitos, de ahí la necesidad de distintos niveles de Scrum Masters.

A continuación los tres roles:

Jefe Scrum Master

Los proyectos grandes requieren múltiples equipos Scrum para trabajar en paralelo. Es posible que la información que un equipo genera se requiera comunicar correctamente a los otros equipos. El Jefe Scrum Master es responsable de esta actividad. El rol de un Jefe Scrum Master es necesario para asegurar la correcta colaboración entre los equipos Scrum. Normalmente, en la reunión de Scrum de Scrums se realiza la coordinación entre varios equipos Scrum de un proyecto No existe jerarquía entre Scrum Masters; todos son colegas. El Jefe Scrum Master simplemente trabaja en un nivel multiequipos, mientras que los Scrum Masters trabajan al nivel de un solo equipo. Normalmente, cualquier problema entre equipos es resuelto por las partes interesadas en una reunión inmediatamente posterior a la de Scrum de Scrums.

El Jefe Scrum Master puede ser el del proyecto grande o puede ser alguien más. Para cada proyecto grande, se recomienda tener un Jefe Scrum Master, quien no puede ser también el Scrum Master de un equipo porque el esfuerzo requerido puede impedirle trabajar adecuadamente con su equipo. En cualquiera de los casos, el Jefe Scrum Master debe tener suficiente experiencia en Scrum como para ser capaz de conseguir colaboración y ayudar y guiar a otros con la implementación de Scrum para una entrega sin problemas del producto del proyecto.

Aparte de eliminar impedimentos y asegurar un ambiente de proyecto apropiado para los equipos Scrum, el Jefe Scrum Master también colabora con el Chief Product Owner, otros Scrum Masters y otros Product Owners, en actividades como desarrollar la lista de componentes y recursos que necesiten en común para todos los equipos a través del proyecto. Facilita todo lo que va más allá del campo de un solo Equipo Scrum. El Jefe Scrum Master también interactúa con el Scrum Master de Programa para asegurar alineación del proyecto grande con los objetivos y metas del programa.

Scrum Master del Programa

El Scrum Master del Programa es un facilitador quien se asegura de que todos los equipos de proyecto de un programa tengan el ambiente apropiado para completar sus proyectos exitosamente. El Scrum Master del Programa guía, facilita y enseña la práctica de Scrum a todos quienes están involucrados en el programa; provee guía a los Scrum Masters de proyectos individuales; elimina impedimentos a los diferentes equipos de proyecto; coordina con el Cuerpo de Guía Scrum para definir los objetivos relacionados con la calidad, regulaciones gubernamentales, seguridad y otros parámetros organizacionales clave. También, se asegura de que los procesos Scrum se sigan eficientemente a través del programa.

El Scrum Master del Programa interactúa con el Scrum Master del Portafolio para asegurarse de que los objetivos del programa estén alineados con los objetivos y metas del portafolio. Igualmente está involucrado en nombrar a los Scrum Masters para los proyectos individuales y asegurarse de que la visión, objetivos, resultados y entregas de los proyectos individuales dentro del programa, estén alineados con los del programa. Este rol es similar al del Scrum Master, excepto porque logra las necesidades del programa o negocio en lugar de un solo Equipo Scrum.

Scrum Master del Portafolio

Este rol es similar al del Scrum Master, excepto porque cubre las necesidades del Portafolio o negocio en lugar de un solo Equipo Scrum.

Autor: SCRUMstudy

Traducción: Adela Vega, TSPM, SMC, SDC

Adaptación: Enrique Ledesma M.Sc., PMP, CDA, STC, SPOC, SMC, SDC