Dia Mundial Retrospectiva 2019

Kanban Limitar el trabajo en proceso (WIP)

Limitar el trabajo en proceso (WIP)
Los límites del WIP (work in progress - trabajo en curso) consisten en acordar
anticipadamente, la cantidad de ítems que pueden abordarse en cada actividad (es
decir, en cada columna del tablero). El principal objetivo de establecer estos límites,
es el de evitar cuellos de botella.

Reunión de retrospectiva cuantas practicas ?

Reunión de retrospectiva del sprint—Esta reunión tiene un time-box de cuatro horas en un sprint de un mes, y se lleva a cabo como parte del proceso Retrospectiva del sprint. Durante esta reunión, el Equipo Scrum se reúne para revisar y reflexionar sobre el sprint anterior en relación a los procesos que se siguieron, las herramientas empleadas, la colaboración y los mecanismos de comunicación, así como otros aspectos de interés para el proyecto. El equipo discute lo que salió bien durante el sprint anterior y lo que no salió bien, con el objetivo de aprender y mejorar sprints futuros. Algunas oportunidades de mejora o las mejores prácticas de esta reunión también podrían actualizarse como parte de los documentos del Scrum Guidance Body.

Retrospectiva del proyecto—En este proceso, mismo que concluye el proyecto, los stakeholders y miembros del equipo principal de Scrum se reúnen para hacer una retrospectiva del proyecto e identificar, documentar e internalizar las lecciones aprendidas. A menudo, estas lecciones llevan a la documentación de Agreed Actionable Improvements, que se implementarán en futuros proyectos.

Retrospectiva de lanzamientos del programa o portafolio—En este proceso, el Program Product Owner o el Portfolio Product Owner y los stakeholders clave se reúnen para hacer una retrospectiva sobre el lanzamiento de un programa o portafolio e internalizar las lecciones aprendidas. Por lo general dichas lecciones aprendidas llevan a mejoras aceptadas (Agreed Actionable Improvements) para ser implementadas a futuro.

11.2.2.1 Reunión de retrospectiva del sprint*

La reunión de retrospectiva del sprint es un elemento importante del framework de “inspección-adaptación” de Scrum y es el último paso en un sprint. Todos los miembros del Equipo Scrum asisten a la reunión, misma que organiza y modera el Scrum Master. Se recomienda que asista el Product Owner, aunque no es obligatorio. Un integrante del equipo se desempeña como secretario y documenta las discusiones y los elementos para acciones a futuro. Es esencial celebrar esta reunión es un entorno abierto y relajado a fin de fomentar la completa participación de todos los miembros del equipo. Las discusiones en la reunión de retrospectiva del sprint abarcan tanto lo que salió mal como lo que salió bien. Los objetivos primordiales de la reunión son identificar tres elementos específicos:

1) Las cosas que el equipo necesita seguir haciendo: mejores prácticas

2) Las cosas que el equipo necesita empezar a hacer: mejoras en el proceso

3) Las cosas que el equipo necesita dejar de hacer: problemas de proceso y embotellamiento 

Estas áreas se analizan y se crea una lista de mejoras accionables aceptadas (Agreed Actionable Improvements).

11.2.2.2 Explorador—Comprador—Vacacionista—Prisionero (ECVP)

Es un ejercicio que se puede llevar a cabo al inicio de la reunión de retrospectiva del sprint para entender la mentalidad de los participantes y establecer el tono de la reunión. Se les pide a los asistentes que indiquen de forma anónima lo que mejor representa su punto de vista en la reunión.

• Explorador (Explorer)—Quiere participar y aprender todo lo que se discutió en la retrospectiva

• Comprador (Shopper)—Quiere escuchar todo y elegir lo que entiende de la retrospectiva

• Vacacionista (Vacationer)—Quiere relajarse y ser turista en la retrospectiva

• Prisionero (Prisoner)—Quiere estar en otro lugar y asiste a la retrospectiva por ser obligatorio

El Scrum Master reúne las respuestas; prepara y comparte la información con el grupo.

11.2.2.3 Speed Boat

El Speed Boat es una técnica que se puede utilizar para llevar a cabo la reunión de retrospectiva del sprint. Los miembros juegan el rol de la tripulación en una lancha. La lancha debe llegar a una isla: simbólicamente la visión del proyecto. Los asistentes utilizan notas adhesivas para llevar un registro de motores y anclas. 

Los “motores” ayudan a llegar a la isla, mientras que las “anclas” son cosas que están obstaculizando la llegada. Este ejercicio tiene un time-box de unos cuantos minutos. Una vez que se documentan todos los elementos, se reúne la información, se discute y se prioriza por medio de un proceso de votación. Se reconocen los motores y se planifican las acciones de mitigación para las anclas dependiendo de la prioridad

11.2.3.5 Lecciones aprendidas del Equipo Scrum

Se espera que el Equipo Scrum (equipo auto organizado y empoderado) aprenda de los errores cometidos durante el sprint y que estas lecciones aprendidas ayuden a mejorar su desempeño en futuros sprints.

Estas lecciones aprendidas también pueden documentarse en las recomendaciones del Scrum Guidance Body para compartirse con otros equipos de Scrum.

Puede haber varias lecciones positivas aprendidas como parte de un sprint. Estas lecciones positivas aprendidas son parte clave de la retrospectiva y deben compartirse adecuadamente dentro del equipo y con el Scrum Guidance Body conforme el equipo avanza hacia una auto-mejora continua.

12.2.2.1 Reunión de retrospectiva del proyecto*

La reunión de retrospectiva del proyecto es una reunión para determinar las formas en las que la colaboración y eficacia del equipo puede mejorarse en futuros proyectos. También se analizan las oportunidades positivas, negativas y potenciales para mejorar. Esta reunión no tiene un time-box asignado y se puede llevar a cabo en forma presencial o en formato virtual. Entre los asistentes se encuentran: el equipo del proyecto, el Chief Scrum Master, el Chief Product Owner y el (los) stakeholder(s). Durante la reunión, se documentan las lecciones aprendidas y los participantes buscan oportunidades para mejorar los procesos y atender las ineficiencias.

Retrospect Sprint Log(s)

Los registros de la retrospectiva del sprint, o Retrospect Sprint Log(s), son registros de las opiniones, debates y elementos accionables planteados en la reunión de retrospectiva del sprint. El Scrum Master puede facilitar la creación de dicho registro con la aportación de los miembros del equipo principal de Scrum.

Fuente SBOK

La autoorganización principio esencial en Scrum

La autoorganización como principio esencial en Scrum conduce a lo siguiente:

• La participación del equipo y la propiedad compartida.
• Motivación, que conduce a un mejor nivel de rendimiento del equipo.
• Entorno innovador y creativo propicio para el crecimiento.

Aunque la priorización la realiza principalmente el propietario del producto, que representa la voz del cliente, el equipo Scrum autoorganizado está involucrado en el desglose y estimación de tareas. Durante estos procesos, cada miembro del equipo es responsable de determinar qué trabajo realizará. Durante la ejecución de un Sprint, si los miembros del equipo necesitan ayuda para completar sus tareas, Scrum lo soluciona a través de la interacción regular obligatoria con las reuniones diarias de soporte. El Equipo Scrum en sí mismo interactúa con otros equipos a través de las Reuniones de Scrum of Scrums (SoS) y puede buscar orientación adicional según lo requiera el Cuerpo de Orientación de Scrum.

Finalmente, Scrum Team y Scrum Master trabajan estrechamente para demostrar el incremento del producto creado durante el Sprint donde se aceptan los entregables debidamente completados. Dado que los entregables son potencialmente enviables, (y las historias de usuarios priorizan la acumulación de productos priorizados en el orden de valor creado por ellos), el propietario del producto y el cliente pueden visualizar y articular claramente el valor que se crea después de cada Sprint. y los Equipos Scrum, a su vez, tienen la satisfacción de ver que el cliente y otras partes interesadas aceptan su arduo trabajo.

Scrum cree que los empleados se motivan a sí mismos y buscan aceptar una mayor responsabilidad. Por lo tanto, ofrecen un valor mucho mayor cuando se autoorganizan. El estilo de liderazgo preferido en Scrum es el "liderazgo de servicio", que enfatiza el logro de resultados al enfocarse en las necesidades del Equipo Scrum. La autoorganización no significa que a los miembros del equipo se les permita actuar de la manera que ellos quieran. Solo significa que una vez que se define la Visión del producto, se identifican el Propietario del producto, Scrum Master y el Equipo Scrum. Además, el propio Scrum Core Team trabaja muy de cerca con los interesados ​​relevantes para mejorar los requisitos de refinación. La experiencia del equipo se utiliza para evaluar los insumos necesarios para ejecutar el trabajo planificado del proyecto. Este juicio y experiencia se aplican a todos los aspectos técnicos y de gestión del proyecto.

fuentes: http://blog.scrumstudy.com/what-is-self-organizing/ 

Priorizacion de historias de usuario, tecnicas

A continuación se presentan 4 de las técnicas mas utilizadas para priorizar las Historias de usuario o los requisitos en el Registro de productos priorizados, en función del valor comercial:

1. Esquema de priorización de MoSCoW: el  esquema de  priorización de MoSCoW deriva su nombre de las primeras letras de las frases "Debe tener", "Debería tener", "Podría haber" y "No tendrá". Este método de priorización es generalmente más efectivo que los esquemas simples. Las etiquetas están en orden de prioridad decreciente, con "Debe tener" Historias de usuario sin las cuales el producto no tendrá ningún valor y "No tendrá" Las Historias de usuario serán aquellas que, aunque sería bueno tener, no son necesarias ser incluido

2. Comparación por pares:  en esta técnica, se prepara una lista de todas las Historias de usuarios en el Registro de productos priorizados. A continuación, cada historia de usuario se toma individualmente y se compara con las otras historias de usuario de la lista, una a la vez. Cada vez que se comparan dos Historias de usuarios, se toma una decisión sobre cuál de las dos es más importante. A través de este proceso, se puede generar una lista priorizada de Historias de usuarios. 

3. Método de 100 puntos: el método de  100 puntos fue desarrollado por Dean Leffingwell y Don Widrig (2003). Implica dar al cliente 100 puntos que puede usar para votar por las Historias de usuario que son más importantes. El objetivo es dar más peso a las Historias de usuario que son de mayor prioridad en comparación con las otras Historias de usuario disponibles. Cada miembro del grupo asigna puntos a las diversas Historias de usuarios, lo que da más puntos a aquellos que consideran más importantes. Al finalizar el proceso de votación, la priorización se determina calculando los puntos totales asignados a cada historia de usuario.
 4. Análisis de  Kano: el análisis de Kano fue desarrollado por Noriaki Kano (1984) e incluye la clasificación de características o requisitos en cuatro categorías según las preferencias del cliente:
Exciters / Delighters: características nuevas o de alto valor para el cliente
Satisfechos: características que ofrecen valor al cliente.
Insatisfechos: características que, si no están presentes, pueden hacer que al cliente no le guste el producto, pero no afectan el nivel de satisfacción si están presentes
Indiferente: características que no afectarán al cliente de ninguna manera y deben eliminarse.

Curiosamente, las características generalmente bajan la lista de clasificación a lo largo del tiempo; los clientes llegarán a esperar características (por ejemplo, cámaras en los teléfonos) y estas características pasarán de ser excitantes / encantadoras a satisfechas y eventualmente a insatisfechas

A nivel de programa o cartera, normalmente hay una cantidad menor de requisitos / historias de usuario que a nivel de proyecto. El porcentaje de historias de usuarios con un valor muy tangible / necesidad empresarial / impacto en el usuario suele ser mucho menor que en el nivel de proyecto. Eso significa que la selección de técnicas que son útiles a nivel de programa o cartera será menor. Por ejemplo, el análisis de Kano tiene limitaciones porque no habrá desilusionadores ni excitantes. Sin un número significativo de partes interesadas, especialmente los usuarios, el método de 100 puntos tiene un valor limitado. La técnica MoSCoW también tiene limitaciones porque no habrá ninguna característica "agradable de tener" o "No tendrá" a nivel de programa y cartera.
Fuente : http://blog.scrumstudy.com/user-story-prioritization-techniques/