Coleccion de Epicas relacionadas para describir un sistema o subsistema en su totalidad.
Es una historia de usuario que es demasiado grande para caber en un Sprint. A menudo este termino se utiliza para describir una gran User Story que tendra que ser dividida en Stories mas pequeñas.
Se descompone a un tamaño mas adecuado para ser gestionada con los principios y tecnicas agiles: estimacion y seguimiento.
Es una representacion de un requisito del usuario en forma escrita, de una o dos frases, utilizando lenguaje comun del usuario.
No utilizan lenguaje tecnico, se escriben desde la perspectiva del usuario, para contextualizar al Development Team.
modelo INVEST
-
Independence, independientes unas de otras.
-
Negotiables, no es suficientemente explicita como para considerarse un contrato. La discusion con el usuario debe permitir esclarecer su alcance.
-
Valuable, deben ser importantes, valoradas mas que para el Developer.
-
Estimable, el resultado de la discusion de la Story es la estimacion de tiempo que tomara completarla.
-
Small, Stories largas son dificiles de estimar e imponene restricciones.
-
Testable, en general son verificables, la verificacion debe automatizarse, para que pueda ser verificada en cada entrega.
-
Mantienen el foco en el usuario, una lista de pendientes mantiene al equipo centrado en las tareas que necesitan ser marcadas, las Stories mantienen al equipo centrado en la resolucion de problemas de usuarios reales.
-
Permiten la colaboracion, asi el equipo trabaja en conjunto para decidir cual es la mejor manera de servir al usuario y alcanzar el objetivo.
-
Impulsan soluciones creativas, estas animan al equipo a pensar de manera critica y creativa sobre la mejor manera de resolver un objetivo final.
-
Crean impulso, el Development team disfruta de un pequeño desafio y una pequeña victoria.
Card
Descripcion escrita de los que necesita, esta debe responder 3 preguntas:
Persona + necesidad + proposito
Persona: Para quien lo creamos? buscamos el perfil de la persona, tenemos emparia a esta persona.
Necesidad: Para que?, describimos la intencion y no sus funciones... que es lo que intenta conseguir realmente, el objetivo del usuario.
Proposito: Cual es el gran problema que necesita resolverse?
Como Sascha, quiero organizar mi trabajo para que pueda sentir que lo tengo todo controlado.
Como gestor, quiero poder comprender el progreso de mis compañeros para poder informar mejor de nuestros éxitos y fracasos.
Conversation
Product Owner y Development Team aclaran los detalles.
Confirmation
Sirve para determinar lo que se espera. Product Owner y Development Team dan conformidad y confirman que todo esta entendido.
Transparencia
Trabajo tecnico que realiza el Development team para completar un item del Product Backlog.
La mayoria de las Tasks, se definen como pequeñas, lo que representa no mas de unas pocas horas del dia.
Las Tasks tienen asignada una persona para su realizacion.
Modelo SMART
- Specific, detallado y concreto.
- Measurable, debe ajustarse a criterios de medicion factibles.
- Achievable, ajustado a la realidad.
- Result-oriented, plantear la tarea en funcion del resultado a conseguir.
- Time-limited, debe tener un momento de realizacion.
Se compone de:
- Identificacion
- Responsable
- Descripcion
- Estimacion
Son los acuerdos del Product Owner con los Stakeholders que contiene todas las condiciones que deben de cumplir los items del Product Backlog para considerar un Sprint completado o finalizado.
Agrega valor verificable y demostrable al producto.
Se utiliza para centrarse en lo que debe ser completado con el fin de completar una determinada tarea.
Son componentes objetivos por los cuales se juzga la funcionalidad de un User Story.
El criterio de aceptacion se define para cada User Story, y se aplica individualmente a cada uno
DOD se aplica a todas las User Story
Done es un conjunto de reglas que se aplican a las user Stories en un determinado Sprint.
Ejemplos de DOD:
- Todas las pruebas unitarias y funcionales son correctas.
- Todos los criterios de aceptación se cumplen.
- OK del equipo: UX, desarrollador, Product Owner, etc.
- Pruebas en dispositivos/navegadores pasada.
- Pruebas de rendimiento pasadas.
- Se han corregido todos los bugs.
- Entorno preparado para la subida a producción.
Consiste en fijar un tiempo maximo para conseguir un objetivo.
Todos los eventos Scrum son bloques de tiempo que tienen una duracion maxima.
La consecuencia de esta limitacion temporal favorece la priorizacion de objetivos/tareas y fuerza la toma de decisiones.
- Procesos de desarrollo eficiente.
- Menos gastos generales.
- Alta velocidad para los equipos.
- Ayuda a gestionar eficazmente la planificacion y ejecucion de proyectos.
Algo que fabricamos, una herramienta para solucionar un problema
Los artefactos de Scrum representan trabajo o valor en diversas formas que son utiles para proporcionar transparencia y oportunidades para la inspeccion y adaptacion.
Los artefactos estan definidos especificamente para maximizar la transparencia de la informacion clave, necesaria para asegurar que todos tengan el mismo entendimiento del artefactos.
Lista ordenada de todo lo que se conoce que es necesario en el producto, es la unica fuente de requisitos para cualquier cambio a realizarse en el producto. El responsable es el Product Owner, incluyendo su contenido, disponibilidad y ordenacion.
La Product Backlog nunca esta completa. E desarrollo mas temprano de la misma solo refleja los requisitos conocidos y mejor entendidos al comienzo. Luego la Backlog evoluciona a medida de que el producto y entorno en el que se usara tambien lo hacen. La Product Backlog es dinamica, cambia constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y util. Si un producto existe, su Product Backlog tambien existe.
Enumera todas las caracteristicas, funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a realizarse sobre un producto para entregas futuras. Los elementos del Product Backlog tienen como atributos: descripcion, orden, estimacion y valor. Los elementos de la Product Backlog muchas veces incluyen descripciones de las pruebas que demostraran la completitud de tales elementos cuando esten "Done".
A medida que un producto es utilizado y se incrementa su valor y el mercado proporciona retroalimentacion, el Product Backlog se convierte en una lista mas larga y exhaustiva. Los requisitos nunca dejan de cambiar asu que la Product Backlog es un artefacto vivo. Los cambios en los requisitos de negocio, las condiciones del mercado o la tecnologia podrian causar cambios en el Product Backlog.
A menudo, varios equipos Scrum trabajan en el mismo producto. Para describir el trabajo a realizar sobre el producto se utiliza una unica Product Backlog. En ese caso podria emplearse un atributo de la Product Backlog para agrupar los elementos.
Es el acto de añadir detalle, estimaciones y orden a los elementos del Product Backlog. Se examinan y revisan los elementos del Product Backlog.
El Scrum Team decide como y cuando se hace el refinamiento. Este usualmente consume no mas del 10% de la capacidad del Development Team. Sin embargo los elementos del product Backlog pueden actualizarse en cualquier momento por el criterio del Product Owner.
Los elementos del Product Backlog, de orden mas alto son mas claros y detallados que los de menor orden. Se realizan estimaciones mas precisas basandose en la mayor claridad y detalle. Mientras mas bajo el orden, menor es el detalle.
Los elementos de los que se ocupara el Dev Team en el siguiente Sprint tienen una granularidad mayor, habiendo sido descompuestos de forma que cualquier elemento puede quedar "Done" dentro de los limites del Time Boxing del Sprint. Los elementos que pueden quedar "Done" por el Dev Team en un Sprint son considerados "Ready" para ser selecionados en una Sprint Planning. Los elementos del Product Backlog adquieren este grado de transparencia mediante las actividades de refinamiento.
El Development Team es responsable de estas estimaciones. El Product Owner podria influenciar al Dev Team ayudandoles a entender y selecionar sus compromisos, pero es el Dev Team el que hace la estimacion final.
El Product Owner hace seguimiento del trabajo restante total al menos en cada Sprint Review. Asi, compara esta cantidad con el trabajo restante en Sprints Reviews previos, para evaluar el progreso hacia la finalizacion del trabajo proyectado en el tiempo deseado para el objetivo. Esta informacion es transparente a todos los interesados.
Para predecir el progreso de ha utilizado Burndown (trabajo pendiente), Burnup (trabajo completado), y Cumulative Flow (flujo acumulado). Si bien son utiles no reemplazan la importancia del empirismo. En entornos complejos se desconoce lo que ocurrira. Solo lo que ya ocurrido puede utilizarse para la toma de decisiones con miras al futuro.
Son los elementos del Product Backlog selecionados para el Sprint, mas un plan para entregar el Incremento de producto y conseguir el objetivo del Sprint. Esta es una prediccion hecha por el Development Team acerca de que funcionalidad formara parte del proximo incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento "Done".
El Sprint Backlog hace visible todo el trabajo que el Dev team identifica como necesario para alcanzar el Sprint Goal. Para asegurar el mejoramiento continuo, el Sprint Backlog incluye al menos una mejora de procesos de alta prioridad en la Retrospective anterior.
El Sprint Backlog, es un plan con un nivelk de detalle suficiente como para que los cambios en el progreso se puedan entender en el Diary Scrum. El Development Team modifica el Sprint Backlog durante el Sprint y este Sprint Backlog emerge a lo largo del Sprint. Esto ocurre a medida que el Dev Team trabaja en lo planeado y aprende mas acerca del trabajo necesario para conseguir el Sprint Goal.
Cuando se requiere nuevo trabajo, el Dev Team lo agrega al Sprint Backlog del Sprint. A medida que el trabajo se completa, se va actualizando la estimacion de trabajo restante. Cuando algun elemento se considera innecesario, es eliminado. SOlo el Dev Team puede cambiar su Sprint Backlog del Sprint durante el Sprint. La Sprint Backlog pertenece unicamente al Dev Team.
En cualquier momento durante el Sprint es posible sumar trabajo restante total en los elementos de la Sprint Backlog del Sprint. El Dev Team hace seguimiento de este trabajo restante total al menos en cada Diary Scrum para proyectar la posibilidad de conseguir el Sprint Goal. Haciendo gestion de trabajo restante a lo largo del Sprint, el Dev Team puede gestionar progreso.
Es la suma de todos los elementos del Product Backlog completados durante un Sprint y el valor de los Incrementos de todos los Sprints anteriores. Al final de un Sprint el nuevo Incremento debe quedar "Done", lo cual significa que esta en condiciones de ser utilizado y cumple la Definition of Done (DOD). Un Incremento es un cuerpo de trabajo inspeccionable y terminado que respalda el empirismo al final del Sprint. El Incremento es un paso hacia una vision o meta. El Incremento debe estar en condiciones de utilizarse si el Product Owner decide liberarlo o no.
El Scrum Master trabaja con el Scrum Team y la organizacion para mejorar la transparencia de los artefactos. Este trabajo usualmente incluye aprendizaje, conviccion y cambio. La transparencia no ocurre de la noche a la malana, si no que es un camino.
Los eventos tienen como fin crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Una vez que comienza un Sprint, su duracion es fija y no puede acortarse o alargarse. Los demas eventos pueden terminar siempre que se alcance el objetivo del evento, asegurando que se emplee una cantidad apropiada de tiempo sin permitir desperdicio en el proceso.
Cada uno de los eventos, constituye una oportunidad formal para la inspeccion y la adaptacion de algun aspecto. (Pilaes Scrum!)
| Scrum Event | Time-Boxing (for 1 month Sprint) | Participants |
|---|---|---|
| Sprint Planning | 8 HRS | Scrum Master, Product Owner, Development Team |
| Daily Scrum | 15 HRS | Scrum Master (optional), Product Owner (optional), Development Team |
| Sprint Review | 4 HRS | Scrum Master, Product Owner, Development Team and all key stakeholders |
| Sprint Retrospective | 3 HRS | Scrum Master, Product Owner, Development Team |
El corazon de Scrum, es un Time Boxing con duracion de 1 a 4 semanas, durante el cual se crea un Incremento de producto "Done" utilizable y potencialmente desplegable. Es conveniente que la duracion de los Sprints sea consistente a lo largo del esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente despues de la finalizacion del Sprint Anterior.
Los Sprint contienen y consisten Sprint Planning, Daily Sprint, Trabajo de Desarrollo, Sprint Review, Sprint Retrospective.
- No se realizan cambios que puedan afectar el Sprint Goal.
- Los objetivos de calidad no disminuyen.
- El alcance puede clarificarse y regegociarse entre el Product Owner y el Dev Team a medida que se va aprendiendo mas.
Los Sprints no se usan para lograr algo, cada Sprint tiene una meta de lo que se construira, un diseño, un plan flexible que guiara su construccion, el trabajo del equipo y el Incremento de producto resultante.
Cuando el horizonte del Sprint es demasiado grande, la definicion de lo que se esta constriyendo podria cambiar, la complejidad podria incrementarse y el riesgo podria aumentar. Los Sprints habilitan la predictividad al asegurar la inspecciony adaptacion del progreso al menos en cada mes calendario. Tambien limitan el riesgo al costo de un mes calendario.
Puede cancelarse antes de que el Time Boxing llegue a su fin. Solo el Product Owner tiene autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, del Development Team o del Scrum Master.
Podria cancelarse si el Sprint Goal llega a quedar onbsoleto. Esto podria ocurrir si la compañia cambia la direccion o si las condiciones del mercado o tecnologia cambian. En general se cancela si no tuviera sentido seguir con el dadas las circunstancias, pero debido a la corta duracion de los Sprints, su cancelacion rara vez tiene sentido.
Cuando se cancela un Sprint se revisan todos los elementos del Product Backlog completados y "Done". Si una parte es potencialmente entregable, el Proyect owner, normalmente la acepta. Todos los elementos del Product Backlog no completados se vuelven a estimar y se vuelven a introducir en la Product Backlog. El trabajo finalizado en ellos pierde valor con rapidez y por lo general debe volverse a estimar.
Es un cambio urgente? No: Los cambios se harian en un futuro Sprint Si: Cancelar el Sprint y reiniciar el Sprint Planning
La cancelacion consume recursos ya que todos se reagrupan en otra Sprint Planning para comenzar otro Sprint. Las cancelaciones de Sprints son a menudo traumaticas para el Scrum Team y son muy poco comunes.
Se planifica el trabajo a realizar durante el Sprint. El plan se crea mediante el trabajo colaborativo del Scrum Team completo.
La planificacion tiene un maximo de 8 horas para un Sprint de 1 mes. El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su proposito. El Scrum Master enseña al Scrum Team a metenerse en el Time Boxing.
El Dev Team trabaja para proyectar la funcionalidad que se desarrollara durante el Sprint. El Product Owner discute el objetivo que el Sprint deberia lograr y los elementos del Product Backlog, que si se completan en el Sprint, lograrian el Sprint Goal. El Scrum Team completo colabora en este entendimiento.
La entrada a esta reunion esta constituida por el Product Backlog, el ultimo Incremento del producto, la capacidad proyectada del Dev Team para el Sprint y el rendimiento pasada del Dev Team. El Numero de elementos del Product Backlog seleccionados para el Sprint depende solo del Dev Team. Solo ellos puede evaluar que podran lograr en el Sprint que comienza.
En el planning, el Scrum Team define el Sprint Goal. Este deberia lograrse durante el Sprint, a traves de la implementacion del Product Backlog y proporciona una guia al Dev Team de porque se esta construyendo el Incremento.
Luego de establecido el objetivo y selecionados los elementos del Product Backlog para el Sprint, el Dev Team decide como construira esta funcionalidad para formar un Incremento de producto "Done" durante el Sprint. Esta lista de selecionados mas el plan para terminarlos se llama Sprint Backlog (Pendientes).
Durante el Sprint Planning se planifica suficiente trabajo como para que el Dev Team pueda hacer una proyeccion de lo que cree que puede completar en el Sprint que comienza. Al final de esta reunion, el trabajo planificado por el Dev Team para los primeros dias es descompuesto en unidades de un dia o menos.
El Dev Team se autoorganiza para asumir el trabajo de la Sprint Backlog, tanto durante la Sprint Planning como a lo largo del Sprint.
El Product Owner puede ayduar a clarificar elementos del Product Backlog selecionados. Si el Dev Team considera que tiene mucho trabajo, o que no tiene suficiente trabajo, puede renegociar los elementos del Product Backlog seleccionados con el Product Owner.
Al finalizar la reunion, el Dev Team deberia ser capaz de explicar al Product Owner y al Scrum Master como pretende trabajar de forma autoorganizada para lograr el Sprint Goal y crear el Incremento esperado.
Es una meta establecida para el Sprint que puede lograrse mediante la implementacion de la Product Backlog. Es una guia al Dev Team acerca de por que se esta construyendo el Incremento. Se crea durante el Sprint Planning. Brinda cierta flexibilidad al Dev Team con respeto a la funcionalidad implementada en el Sprint. El Sprint Goal puede representar otro nexo de union que haga que el Dev Team trabaje en conjunto y no por separado.
Si el trabajo resulta ser diferente de lo que el Dev Team espera, ellos colaboran con el Product Owner para negociar el alcance de la Sprint Backlog.
Es un bloque de tiempo de 15 minutos para el Development Team. Se lleva a cabo cada dia del Sprint, en el se planea el trabajo para las siguientes 24hrs. Esto optimiza la colaboracion y desempeño del equipo, inspeccionando el trabajo avanzado en el ultimo Daily Scrum y haciendo una proyeccion del trabajo del Sprint a realizar a continuacion. Se realizada siempre a la misma hora y en el mismo lugar todos los dias para reducir complejidad.
El Dev Team usa el Daily Scrum para evaluar el progreso hacia el Sprint Goal, y para evaluar que tendencia sigue este progreso hacia la finalizacion del trabajo contenido en la Sprint Backlog. Cada dia, el Dev Team deberia entender como intenta trabajar en conjunto como un equipo autoorganizado para lograr el objetivo del Sprint y crear el Incremento esperado hacia el final del Sprint.
El Dev Team es el encargado de establecer la estructura de la reunion. Aveces se usan preguntas como:
- Que hice ayer que ayudo al Dev Team a lograr Sprint Goal?
- Que hare hoy para ayudar al Dev Team a lograr el Sprint Goal?
- Veo algun impedimento que evite que el Dev Team o yo logremos el Sprint Goal?
Luego de la reunion el Dev Team se reune inmediatamente para detallar o adaptar o replanificar el resto del trabajo del Sprint.
El Scrum Master se asegura de que el Dev Team tenga la reunion pero es el Dev Team el responsable de dirigirla. El Scrum Master enseña al Dev Team a mantener la duracion no mas alla de 15 min.
El Daily Scrum es interna del Dev Team, si otras personas estan presentes, el Scrum Master se asegura de que no interrumpan la reunion.
El Scrum diario mejora la comunicacion , elimina la necesidad de otras reuniones, identifica impedimentos que remover, resaltan y promueven la toma rapida de decisiones y mejoran el nivel de conocimiento del Dev Team. El Daily Scrum es clave.
Inspeccion y adaptacion
Se lleva a cabo al final de Sprint. Se inspecciona el Incremento y se adapta el Product Backlog de ser necesario. El Scrum Team y los interesados colaboran acerca de lo que se hizo en el Sprint, y determinan las siguientes cosas que podrian hacerse para optimizar el valor. Es informal, no es una reunion de seguimiento, y la presentacion del incremento pretente retroalimentar con informacion y fomentar colaboracion.
Dura maximo 4Hrs en un Sprint de 1 mes. EL Scrum Master se asegura que el evento se lleve a cabo y que los asistentes entiendan su proposito. El Scrum Master enseña a todos a mantener el evento en el Time Boxing fijado.
- Los asistentes son el Scrum Team y los interesados clave invitados por el Product Owner.
- El Product Owner explica que elementos del Product Backlog estan "Done" y cuales no.
- El Dev Team habla acerca de que estuvo bien durante el Sprint, que problema aparecieron y como fueron resueltos.
- El Dev Team hace una demostracion del trabajado "Done", y responde preguntas acerca del Incremento.
- El Product Owner habla acerca del Product Backlog en su estado actual. Proyecta objetivos probables y fecjhas de entrega en el tiempo basadose en el progreso objetido hasta la fecha. (Si es necesario)
- El Team completo colabora acerca de que hacer a continuacion, de modo que la revision del Sprint proporcione informacion de entrada valiosa para subsiguientes Sprint Planning.
- Revision de como el mercado o el uso potencial del producto podria hacer cambiado l que es de mas valor para hacer a continuacion.
- Revision de la linea de tiempo, presupuesto, capacidades potenciales y mercado para proximas entregas de funcionalidades o capacidad prevista del producto.
El Resultado del Sprint Review es una Product Backlog revisada que define los elementos de la Product Backlog posigles para el siguiente Sprint. Es posible ademas que la Product Backlog reciba un ajuste general para enfocarse en nuevas oportunidades.
Esta es una oportunidad para el Scrum Team de inspeccionarse a si mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint.
Ocurre luego del Sprint Review y antes del siguiente Sprint Planning, se trata de una reunion de no mas de 3 horas en Sprints de 1 mes. El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su proposito.
El Scrum Master se asegura de que la reunion sea positiva y productiva, ademas enseña a todos a mentener el Time Boxing fijado. El Scrum Master participa como un miembro del equipo ya que la responsabilidad del proceso Scrum recae sobre el.
- Inspeccionar como fue el ultimo Sprint en cuanto a personas, relaciones, procesos y herramientas.
- Identificar y ordenar elementos mas importantes que salien bien y posibles mejoras.
- Crear un plan para implementar estas mejoras a la forma en que el Scrum Team desempeña su trabajo.
El Scrum Master alimenta al equipo para que mejoren dentro de Scrum, para que sean mas efectivos y amenos al siguiente Sprint. El Scrum Team planifica formas de mejorar la calidad del producto mediante el mejoramiento de la calidad de los procesos o adaptando DOD, segun sea conveniente y no entre en conflicto con los estandares del producto u organizacionales.
Al final del Sprint Retrospective el Scrum team deberia hacer identificado mejoras que implementara en el proximo Sprint. El hecho de implementar mejoras en el siguiente Sprint constituye la adaptacion subsecuente a la inspeccion del Dev Team mismo. Aunque las mejoras pueden implementarse en cualquier momento, el Sprint Retrospective ofrece un evento dedicado para este fin, enfocado en la inspeccion y adaptacion.