Blog

Sprint Planning En Scrum la planificación no es una etapa o un evento único, es una actividad continua durante todo el Sprint.  La Adaptación continua no es sinónimo de desorden o improvisación. Los eventos de Scrum proveen un ambiente de colaboración, aprendizaje y enseñanza además de reforzar el sentimiento de unidad y de equipo hacia un objetivo y propósitos compartidos. En los eventos de Scrum se viven los valores de Scrum y se usan los tres pilares para fomentar la capacidad de respuesta al cambio y la adopción del empirismo. El Sprint sirve para probar las hipótesis que se encuentran en

Objetivos en EBM La Gestión Basada en Evidencia de Scrum.org (EBM) es un marco que facilita la gestión empírica de productos a través de la medición de la entrega de valor a los clientes (Outcome), mejora de resultados de negocio y la medida de las capacidades para sostener la entrega de valor (Salidas – Output). Para mejorar la adaptación a los cambios y reducir el riesgo de la incertidumbre a largo plazo EBM define tres tipos de objetivos: Estratégico, Intermedio y Táctico. Estos objetivos pueden ser conectados a los objetivos de Scrum de la manera más apropiada. Una de ellas podría

Scrum no es una metodología prescriptiva, es un marco adaptativo Scrum se ha convertido en el marco ágil de trabajo más usado para el desarrollo de productos complejos en el mundo. Uno de los beneficios de Scrum es la entrega de incrementos de producto en periodos de tiempo cortos para mejorar el aprendizaje de los clientes y el mercado con el propósito de mejorar los resultados de negocio a través de la innovación de productos. Scrum promueve la autogestión, el trabajo en equipo, la mejora continua y la entrega de un incremento de producto con valor en cada Sprint. Scrum está

Los Criterios de Terminado son el compromiso del Incremento de Producto Al entregar el Incremento de Producto el compromiso es cumplir con los Criterios de Terminado. Los criterios de terminado deben cubrir todos los aspectos necesarios para producir un incremento de producto que potencialmente se pueda lanzar al mercado. Idealmente el lanzamiento se debe producir muchas veces durante el Sprint para validar la entrega de valor y adaptarse hacia el el Objetivo del Producto. Los criterios de terminado incluyen los estándares de la organización, estos estándares pueden incluir los aspectos de arquitectura, seguridad, entre otros y tienen que ser seguidos por el

Scrum maximiza el aprendizaje de los clientes Scrum ayuda a resolver problemas complejos. Estos problemas son los que aparecen en un entorno de incertidumbre o de cambios. Estos cambios provocan riesgos de lograr los resultados de negocio y de producir un producto alineado a las necesidades de los clientes. En Scrum, los Sprints se enfocan en entregar un incremento de producto con valor terminado, potencialmente entregable al cliente a través del lanzamiento de este incremento. El aprendizaje de los clientes se maximiza cuando recibimos sus comentarios acerca del valor recibido cuando usan el producto y validamos las hipótesis asumidas durante el

Maximizar la entrega de valor versus entregar más rápido La agilidad y Scrum no tienen como objetivo la mejora única de la eficiencia para tratar de entregar más producto en menos tiempo, es decir mejorar solamente la eficiencia no es el propósito de Scrum. El uso de Scrum y la agilidad se trata fundamentalmente de maximizar la entrega de valor a través del uso del empirismo entregando producto en ciclos cortos para aprender de los clientes y adaptarnos en base a este aprendizaje validado. Si una empresa necesita mejorar la eficiencia de su flujo sin considerar la adaptación a los cambios

Reflexiones sobre el Objetivo de Producto en Scrum   ¿Por qué es importante el Objetivo del Producto en Scrum? ¿Qué es un objetivo? ¿Cómo sabemos que nos estamos acercando a lo que necesitamos lograr? El objetivo nos da propósito, dirección y alineación para fomentar la colaboración. Visión: Quiero ser un reconocido Agile Coach o Scrum Master. El objetivo: Obtener la certificación PSM en tres meses. Este es el primer paso hacia nuestra visión. Posibles actividades u opciones: Lea artículos en línea Leer libros con un grupo (también conocidos como clubes de lectura) Tome la capacitación de PSM de los expertos Producto

Un único Product Owner para un Producto Un producto tiene un sólo Product Backlog y es gestionado solamente por un único Product Owner. El Product Owner es responsable de la visión, aclaración, ordenamiento del Product Backlog y valor final que proporciona el producto o servicio. Este Product Owner puede recibir ayuda de los Desarrolladore y tener a otras personas que le ayuden a una mayor descomposición del Product Backlog o en la identificación de las dependencias. Al escalar Scrum, pueden existir muchos equipos Scrum, pero aun así existe un único Product Owner para el producto. Un ejemplo de dependencias puede involucrar aspectos de arquitectura, infraestructura y seguridad. En este escenario los Desarrolladores pueden aportar

Gestión Basada en Evidencia de Scrum.org (EBM). Medir el valor entregado a los clientes La Gestión basada en evidencia de Scrum.org es un marco de trabajo que provee un enfoque empírico para mejorar continuamente el valor entregado a los clientes, las capacidades organizacionales para entregar ese valor y los resultados de negocio en un entorno de alta incertidumbre. Ayuda a definir un modelo de métricas para la gestión ágil del desarrollo de producto. https://www.scrum.org/resources/evidence-based-management-guide En el modelo de gestión basada en la evidencia de Scrum.org se definen tres tipos de objetivos: Objetivos estratégicos, intermedios y tácticos. Cada uno de ellos está

Competencias de un Product Owner Aunque la lista de competencias puede ser amplia y variar según el tipo de producto y el escenario a enfrentar las siguientes áreas de competencia pueden ser tomadas en cuenta para ser un gran Product Owner. Experto en Agilidad y Scrum. Dominio del enfoque de desarrollo guiado por valor para maximizar el alineamiento estratégico del desarrollo de producto con la estrategia de la organización y proveer valor. Entender, fomentar y usar el empirismo. Entender la tecnología. No en el grado del dominio, pero si en su relación con el impacto en la entrega de valor a los

Objetivo de Producto en Scrum El Objetivo de Producto define el norte y ayuda a visualizar de mejor manera el compromiso que debe lograr y aportar el Equipo Scrum en cada Sprint. Sin un objetivo de producto podría ser que no sea transparente o sea ambiguo el resultado que se deben lograr. Este objetivo mejora la transparencia, dirección y foco para que la inspección pueda ser realizada de una manera más apropiada para evaluar el progreso dando como resultado una adaptación con mejor sentido. La evaluación del progreso de negocio es hacia el Objetivo del Producto y la forma de lograrlo es

La velocidad en puntos de historia no es obligatoria en Scrum Scrum se ha convertido en el marco ágil de trabajo más usado en el desarrollo de software en el mundo. Uno de los beneficios de Scrum es la entrega de incrementos de producto en periodos de tiempo cortos. El trabajo se basa en la colaboración y trabajo en equipo. Algunos aspectos como el descubrimiento, el empirismo y la inspección continua son claves para lograr un proceso de mejora continua y de innovación en el producto a construir.  Scrum está basado en un proceso de empírico y sirve para construir productos

La productividad en Scrum Scrum es un marco orientado a maximizar la entrega de valor usando el empirismo y el trabajo en equipo. En ese sentido, la productividad se mide en base al valor entregado. Aspectos de eficiencia como productividad individual de cada miembro de equipo en base a las tareas terminadas o la velocidad en puntos de historia que se entregan no representan una medida adecuada de la productividad en problemas complejos; un control excesivo de tareas puede llevar al microcontrol e impactar en forma negativa en la creatividad y la autogestión. Además, objetivos individuales de productividad son peligrosos porque

El Objetivo del Sprint El objetivo del Sprint no es una funcionalidad, es un resultado a lograr dentro del Sprint. Si el objetivo del Sprint se define como una funcionalidad se reduce la flexibilidad, autogestión y creatividad del equipo para adaptarse y encontrar las mejores formas de resolver el problema planteado. Además una funcionalidad reduce el compromiso y la motivacion. Es importante considerar que los objetivos representan metas a lograr en terminos de entrega de valor. Ejemplos de malos objetivos del Sprint: Para una plataforma de cursos en línea. Entregar la página web en un listado de cursos disponibles. Para una

Scrum o Scrum Cascada Scrum es un marco flexible que ofrece muchas ventajas para el desarrollo de productos complejos, pero puede ser fácilmente mal interpretado. Justamente esa libertad puede llevar a distorsiones en su uso. Una distorsión muy frecuente es no entender el propósito de los eventos de Scrum y su impacto en el cambio cultural y la adopción del empirismo. Por ejemplo, a veces se puede asumir que el Sprint Planning es un evento donde se debe planificar todo trabajo en tareas detalladas del Sprint y que esa planificación debe cumplirse sin aceptar cambios. También podría creerse que el Sprint Review es el único

Objetivo de Producto en Scrum El Objetivo de Producto define el norte, brinda dirección para el equipo Scrum y los interesados. Ayuda a visualizar de mejor manera el compromiso que el Equipo Scrum debe lograr en terminos de valor. Sin un objetivo de producto podría ser que el Product Backlog y el resultado a lograr no sean transparente. Este objetivo mejora la transparencia, dirección y foco para que la inspección pueda ser realizada de una manera más apropiada para evaluar el progreso dando como resultado una adaptación con mejor sentido. Pensar en técnicas más allá de Scrum para complementar el marco

Equipo Scrum Los valores de Scrum son la base para definir el comportamiento y formas adecuadas de convivir de las personas. Por ejemplo, respetar y tener apertura pueden ser expresados como la tolerancia para expresar ideas de la manera adecuada y elevar al nivel de la conversación hacia aspectos útiles para el equipo sin hacer daño a los demás. Los Equipos Scrum son multifuncionales, es decir que los miembros aportan todas las competencias necesarias para crear valor en cada Sprint. Son autoorganizados y autogestionados. La autoorganización es el punto de partida para el empoderamiento y colaboración como cultura que se requiere

Scrum provee límites para la Autogestión A veces se puede tender a confundir la autogestión con un equipo que toma decisiones sin límites. Por ejemplo, se puede creer o se puede mal interpretar que los equipos pueden hacer todo lo que quieran porque son autoorganizados. Otro mal entendido frecuente del liderazgo servicial es que el Scrum Master está al servicio del equipo para hacer todo lo que le pidan como una secretaria. También se puede llegar a proceder como si el Product Owner o el Scrum Master tuvieras jerarquías como de jefes. Estas son malas interpretaciones que limitan la colaboración y

Claves de una Transformación Ágil exitosa La Agilidad es un cambio cultural. Implica moverse de entornos de control y jerarquía a equipos autogestionados para entregar valor. No hay recetas para lograr una transformación ágil, se requiere un trabajo duro y continuo para promover una mentalidad que lleve a formas diferentes de gestionar el desarrollo de producto a través del aprendizaje de los clientes y las capacidades de respuesta a los cambios en el mercado. Aunque no existen recetas, hemos aprendido algunos patrones que pueden ayudar como claves de una transformación Ágil exitosa: Definir objetivos de negocio. La Agilidad requiere impulsores de

Product Backlog priorizado versus ordenado La guía de Scrum cambió la definición de del Product Backlo de priorizado por ordenado. La definición tiene un sentido que refuerza el uso del empirismo en Scrum y la capacidad de toma de decisiones del Product Owner sobre el Product Backlog. Priorizar puede indicar una posición de un ítem dentro del Product Backlog en comparación a otros elementos siguiendo una secuencia según un criterio predefinido, por ejemplo, si priorizamos el Product Backlog en función de menor a mayor complejidad. Esta priorización puede basarse en un conjunto de criterios que no necesariamente cubren todos los escenarios que pueden ir surgiendo en