scrum artifacts product backlog
Introducción a los artefactos de Scrum:
En los artículos anteriores de esta serie, nos presentaron a ágil y las diferentes metodologías ágiles . También aprendimos cómo las diversas metodologías son diferentes a su manera.
En nuestro último tutorial, entramos en los detalles de Scrum donde discutimos el Roles de Scrum como Product Owner, Scrum Master y el equipo de scrum y vieron cuáles eran sus responsabilidades individuales.
En este tutorial, continuamos con Scrum y avanzamos en los detalles sobre los diferentes artefactos de scrum.
Lo que vas a aprender:
- Diferentes artefactos de Scrum
- Pila de Producto
- Sprint Backlog
- Incrementos de producto
- Conclusión
- Lectura recomendada
Diferentes artefactos de Scrum
3 tipos de artefactos de scrum incluyen:
- Pila de Producto
- Sprint backlog y
- Incrementos de producto
Ahora veremos qué significan estos términos y cómo crear estos artefactos.
Pila de Producto
Para decirlo en términos simples, una cartera de productos es una lista de todas las cosas que se requieren en el producto. Es el documento final que debe consultar el equipo de scrum para cualquier tema relacionado con el producto. Es una lista ordenada de artículos que pertenece al propietario del producto (PO).
El PO es responsable de crear, mantener y priorizar esta lista. Los OP utilizan esta acumulación de productos para explicar los principales requisitos que deben realizarse durante el sprint a los equipos de scrum.
Los elementos de esta lista pueden estar o no en un lenguaje técnico. Incluso puede ser un lenguaje común, pero debe contener todos los requisitos del producto y los cambios que lo acompañan. Además, tener una acumulación de productos no significa que el equipo de scrum solo tenga que seguir este artefacto.
Pueden crear sus propios artefactos detallados, pero esos no contradecirán ni reemplazarán la acumulación de productos. Preferirán estar alineados con los requisitos de la cartera de pedidos del producto.
A continuación, se muestra un ejemplo de cómo puede verse una pila de productos típica:
| Historia | Estimar | Prioridad |
|---|---|---|
| Quiero iniciar sesión | 4 | 1 |
| Quiero cerrar la sesión | 2 | 2 |
| Quiero cambiar la contraseña | 1 | 3 |
| Quiero actualizar la dirección | 3 | 4 |
| Quiero agregar un nuevo número de teléfono residencial | 1 | 5 |
Esto nos lleva a la pregunta, ¿Cómo crear una buena cartera de productos?
Idealmente, una cartera de productos debe seguir las siguientes reglas:
(i) Debe tener prioridad - Los elementos de la cartera de productos deben ordenarse según su prioridad. Esta prioridad puede ser decidida por el PO y el equipo scrum juntos. Los factores de priorización pueden ser cualquier beneficio similar al punto de la historia, el esfuerzo involucrado en la creación, la complejidad, la prioridad del cliente, etc.
Ayuda al equipo a comprender qué se debe entregar primero.
(ii) Debe estimarse - Las historias siempre deben estimarse según la definición acordada, cualquiera que sea. Esto también se puede utilizar para establecer prioridades.
(iii) Debe ser de alto nivel - Las historias en la cartera de pedidos del producto están destinadas a ser de alto nivel y no deben entrar en detalles. La creación de historias de usuario detalladas según el requisito depende del equipo de scrum y no del PO.
(iv) Debe ser dinámico - La acumulación de productos no es un documento estático final. Debería revisarse a medida que la OP recibe información del equipo scrum y los requisitos del cliente se vuelven cada vez más claros. Por lo tanto, los requisitos de los documentos no se congelan al principio porque se esperan adiciones / eliminaciones / modificaciones a medida que avanza el proyecto.
El último punto es el más relevante. El propósito de una acumulación de productos es ser una fuente activa de requisitos. No debe crearse al principio y luego guardarse en un lugar de almacenamiento.
En cambio, está destinado a ser compartido una y otra vez a medida que se produzcan cambios. Es posible que surjan nuevos requisitos a medida que se avanza y eso también podría cambiar la prioridad de los elementos del trabajo pendiente. Habrá situaciones en las que un nuevo requisito dependa de otro elemento del trabajo pendiente, por lo que es posible que deba reorganizarse la prioridad del elemento.
O puede haber una historia de usuario crítica que podría tener que implementarse primero porque el cliente quiere ver eso antes que los demás, aunque no sea de alta prioridad según los factores decididos por el PO y el equipo scrum.
Por lo tanto, la cartera de productos es una lista ordenada de requisitos comerciales propiedad de la orden de compra y visitados una y otra vez a medida que avanza el proyecto.
Sprint Backlog
Quizás recuerde que los equipos de scrum trabajan en iteraciones cortas de 2 a 4 semanas llamadas sprint. Durante estos sprints, el equipo de scrum identifica los elementos de la cartera de productos creada por la orden de compra, que planean entregar como parte de la próxima iteración. Los elementos que el equipo de scrum selecciona para trabajar se convierten en parte del backlog del sprint.
Por lo tanto, deciden qué funcionalidades estarán allí en la próxima iteración del producto. El equipo de scrum es el que decide qué se incluirá en el backlog del sprint, ya que son ellos los que van a trabajar en ello.
Por lo tanto, son ellos quienes deberían estimar el esfuerzo que implica implementar esas historias y decidir cuánto pueden ofrecer.
El equipo no solo elige los elementos de la cartera de productos en los que trabajar, sino que también calcula cuánto tiempo les llevará desarrollar esa funcionalidad. También se suman a las historias de usuarios de alto nivel mediante la creación de tareas detalladas necesarias para lograr el objetivo del sprint.
preguntas y respuestas de la entrevista de c # net
El equipo de scrum también puede seguir actualizando el backlog del sprint cuando sea necesario durante el sprint, pero solo el equipo de scrum puede realizar cambios en el backlog del sprint.
Un Sprint Backlog típico se verá como se muestra a continuación.
Idealmente, el equipo puede actualizar esto una vez al día y el scrum master puede usar esta información para crear un gráfico de evolución del sprint. Este gráfico de evolución ayudará al equipo a ver cuánto trabajo queda todavía para el sprint y el equipo puede planificar su trabajo en consecuencia. Incluso pueden agregar o eliminar tareas si es necesario.
Algunas de las mejores prácticas al crear una acumulación de sprints pueden ser:
# 1) Tome decisiones grupales - No debe ser el scrum master ni ningún otro miembro del equipo scrum quien decida la acumulación. Más bien, debe ser todo el equipo el que decida qué elementos incluir en el backlog del Sprint y cómo planificarlos.
Cada miembro de este equipo multifuncional aporta sus propias habilidades y es esencial que utilicemos su experiencia para crear la mejor acumulación posible.
# 2) No asigne tareas - Como se ha repetido varias veces en la literatura ágil, nunca asigne tareas a los miembros del equipo. Se supone que un equipo de scrum es autosuficiente y debe saber cómo organizar su trabajo por su cuenta.
Entonces, en lugar de asignar trabajo, deberíamos dejar que el equipo elija el trabajo por sí mismo y decida entre ellos cómo quieren proceder.
# 3) Definición de hecho - No solo debe ser acordado por las partes interesadas, sino que también debe ser claramente visible para el equipo en todos los puntos cuando tengan que tomar una decisión con respecto a los objetivos del sprint. Esto servirá como un recordatorio de lo que se debe hacer exactamente antes de que puedan entregar un producto de envío que funcione.
# 4) Sigue actualizando el backlog - Es imperativo que a medida que evolucione el sprint, el equipo obtenga una mayor comprensión y, por lo tanto, debería actualizar la acumulación del sprint para reflejar también esta mayor comprensión. No debe convertirse en un documento estático en ningún momento.
# 5) Agrega cualquier tarea - La tarea no solo tiene que estar relacionada con la codificación, sino que podría ser esencial para entregar un producto que se pueda enviar. Por lo tanto, mencione estas tareas también en la lista de trabajos pendientes.
Incrementos de producto
Esto nos lleva al último artefacto de scrum que son los incrementos de producto. Según lo definido por la guía de scrum, un Incremento es la suma de todos los Elementos de la lista de productos completado durante un pique y el valor de los incrementos de todos los Sprints anteriores. Como ya sabemos bien, Scrum es un proceso iterativo.
El resultado de cada iteración es este incremento de producto y cada incremento de producto ayuda al equipo a dar un paso más hacia la entrega del producto final.
Lo que esto significa es que cualquier resultado del sprint es un incremento. Obviamente, para que el resultado se considere un incremento, primero debe cumplir con la definición predefinida de hecho, es decir, el resultado final debe ser un producto utilizable que se pueda 'enviar'.
Puede verificarse, usarse y probarse para asegurarse de que realmente está 'hecho' según la definición y, si el propietario del producto lo desea, también puede lanzarse para que se active.
Lo más importante para ofrecer este incremento de producto es tener un entendimiento compartido de la 'definición de hecho' que todos comprenden.
El equipo de scrum nunca debe tener dudas sobre si lo que están haciendo será aceptado o no. Si hay alguna duda, la definición de hecho debe ser lo suficientemente completa para guiarlos sobre cómo continuar. Basándose únicamente en esta definición, el equipo de scrum decide cuántos elementos de la cartera de productos elegir para el sprint.
Este es el mínimo de lo que se espera fuera del sprint.
Conclusión
A partir de este tutorial, hemos entendido cuáles son los 3 artefactos scrum, quién los posee junto con algunas de las mejores prácticas que nos ayudarían a crear artefactos de mejor calidad. En nuestros próximos tutoriales de esta serie, discutiremos los eventos de Scrum y veremos cómo ejecutar esos eventos.
En nuestro próximo tutorial sobre 'Scrum Eventos , '¡Discutiremos cada uno de los eventos de Scrum en detalle!
PREV Tutorial | SIGUIENTE Tutorial
Lectura recomendada
- Scrum Events: Time Boxing, Sprint Planning, Daily Stand-up y Backlog Refinement
- Funciones y responsabilidades del equipo Scrum: Scrum Master y Product Owner
- Tutorial de JIRA Scrum Board: Scrum Handling con Jira para gestionar el Sprint
- Cuestionario en línea de Agile Scrum: Pon a prueba tu conocimiento de Agile Scrum
- Rol de los analistas de negocios en SCRUM y ¿Por qué es mejor un control de calidad para este rol?
- Triaging de defectos en Scrum: cómo se organiza en una configuración de Scrum
- Ejemplos de informes de errores para aplicaciones web y de productos
- Los 9 mejores software PLM en 2021 para administrar el ciclo de vida de su producto