Somos una consultoría que entrega proyectos para varios de nuestros clientes. Para algunos clientes, hay un propietario del producto que escribe la historia del usuario y los criterios de aceptación (entiendo que los criterios de aceptación no son obligatorios, pero generalmente les aconsejamos, ya que trabajamos con una variedad de recursos en una configuración distribuida, por lo que deben tener criterios de aceptación detallados). siempre es útil).
Es generalmente aceptado por todos que los Criterios de Aceptación deben estar disponibles antes de que comience el desarrollo del trabajo. La pregunta es quién debería estar escribiendo los Criterios de Aceptación.
Soy de la opinión de que el Propietario del producto escribe la Historia de usuario que describe la solicitud de función y los Criterios de aceptación deben ser una colaboración entre el equipo de desarrollo (desarrollador o probador) y el Propietario del producto y no necesariamente entregados en su totalidad al Propietario del producto.
Entonces, sería algo en este sentido.
Historia de usuario Como agente de un centro de contacto, quiero capturar información básica sobre el cliente cuando llama
Los criterios de aceptación deben ser
1. Captura de datos
2. Validación
Los Criterios de aceptación pueden ser escritos por el Propietario del producto, pero también pueden ser escritos por el desarrollador/probador siempre que estén firmados por el Propietario del producto.
Un colega mencionó que el problema de pedirle al desarrollador/probador que escriba los Criterios de aceptación es que es un trabajo adicional. También mencionaron que no existe un proceso para capturar que el Propietario del producto ha firmado los Criterios de aceptación, por lo que podrían dar la vuelta y decir que eso no es lo que preguntamos. (La segunda parte de la preocupación probablemente no esté relacionada con la metodología ágil y esté más relacionada con cuando trabajamos como consultoría).
Entonces, ¿quién debe escribir los criterios de aceptación? ¿Es responsabilidad total del propietario del producto o es responsabilidad del equipo?
En primer lugar, debe decirse que no hay reglas estrictas y rápidas sobre esto. Dicho esto, los equipos más exitosos que veo funcionan como usted describe. Específicamente, el PO crea un elemento de la cartera de pedidos con criterios de aceptación iniciales y se lo muestra al equipo en el refinamiento de la cartera de pedidos y, si es necesario, crean colectivamente más.
Y aunque el elemento de la cartera de pedidos debe estar "listo" antes de que comience el desarrollo, no es raro que el acto de desarrollo y prueba descubra nuevas preguntas que requieren la participación del PO y las respuestas pueden dar como resultado criterios de aceptación actualizados.
La Guía Scrum es bastante clara en este punto:
"El propietario del producto puede hacer el trabajo anterior o hacer que el equipo de desarrollo lo haga. Sin embargo, el propietario del producto sigue siendo responsable".
Su colega señaló que la creación de criterios de aceptación es un trabajo, y lo es. El desafío es que scrum ve el desarrollo como un esfuerzo de equipo donde todos están involucrados en todo tipo de trabajo. Comprender qué es lo correcto para construir es tan importante como el acto de construirlo, e involucrar el desarrollo en esa actividad ayuda a construir esa comprensión.
La otra cosa que mencionó su colega fue sobre el proceso. Para la mayoría de los equipos, el hecho de que estén escritos en un refinamiento de la cartera de pedidos tanto con los miembros del equipo como con el PO significa que puede estar prácticamente seguro de que el PO está informado y firmado. Dicho esto, si en tu caso necesitas algo más concreto, la mayoría de las herramientas de gestión de procesos en línea permiten flujos de trabajo modificados. Por ejemplo, sé que es posible personalizar los flujos en Jira que le pedirían a un PO que haga clic en un botón para cerrar sesión cuando se actualizó el cambio en la descripción de la historia del usuario. Espero que muchas otras herramientas también puedan adaptarse a este proceso. Puede ser una preocupación comercial justa para usted, pero no debería ser difícil de superar.
Los Criterios de Aceptación tienen que ver con la usabilidad. Cuando una función cumple con los criterios de aceptación, es seguro que se puede usar. El criterio de aceptación es tan claro como blanco/negro.
Vea este video, por favor: https://www.scrum.org/resources/definition-done-vs-acceptance-criteria
Ahora, cualquiera puede escribir una historia de usuario y ponerla en la cartera de productos. Cada historia de usuario debe refinarse antes de que pueda seleccionarse en el Sprint Backlog durante la planificación del Sprint.
Esto significa que el equipo de desarrollo y el propietario del producto analizan cada historia de usuario escrita por cualquier persona durante la reunión de refinamiento de la cartera de productos. Tanto el equipo de desarrollo como el propietario del producto escriben los criterios de aceptación.
En la práctica, la historia de usuario ya contiene los criterios de aceptación cuando ingresa a la reunión de Planificación de Sprint o los criterios de aceptación se definen durante la Planificación de Sprint por el Equipo de Desarrollo y el Dueño del Producto.
Un colega mencionó que el problema de pedirle al desarrollador/probador que escriba los Criterios de aceptación es que es un trabajo adicional.
Este trabajo se realiza durante el refinamiento de la cartera de productos o la planificación de Sprint.
También mencionaron que no existe un proceso para capturar que el Propietario del producto ha firmado los Criterios de aceptación, por lo que podrían dar la vuelta y decir que eso no es lo que preguntamos.
Si el propietario del producto sugiere que el equipo de desarrollo lo incluya en el Sprint Backlog, entonces sabemos que el propietario del producto ha leído y aceptado los criterios de aceptación de la historia de usuario.
Obviamente, los criterios de aceptación pueden evolucionar durante el Sprint. Cualquier modificación debe ser discutida sobre la marcha por el equipo de desarrollo y el propietario del producto.
No hay tiempo para esperar el próximo refinamiento de la cartera de productos. La historia de usuario ya se seleccionó para entregar este Sprint, por lo que la discusión debe realizarse lo antes posible.
Es por eso que el Product Owner siempre debe estar disponible para el Equipo de Desarrollo. Y es por eso que no hay "aprobación" en Scrum/Agile. Porque cualquier característica puede sufrir modificaciones cuando el Equipo de Desarrollo comienza a implementarla.
El propietario del producto debe reconocer esto lo antes posible y aclarar, en función de la nueva información, qué significa "la función se puede utilizar".
Por ejemplo:
Una historia de usuario se trata de hacer algo visible en la interfaz de usuario.
En la práctica, esto hace que el inicio de sesión del usuario tarde 5 segundos más debido a una solicitud grande y lenta contra el backend. Entonces, la historia de usuario podría entregarse tal como está, pero ¿es utilizable?
¿Es aceptable que el inicio de sesión del usuario tarde 5 segundos? Esta es una pregunta para el propietario del producto.
¿Cuál es la alternativa? El equipo de desarrollo afirma que necesita optimizar la solicitud de backend y quiere aumentar la complejidad de 2SP a 3SP. A cambio, esto significa que es posible que no se entregue otra historia de usuario.
¿Lo que debe hacerse? Opciones para el propietario del producto: 1. Entregar la historia de usuario como se describió originalmente, aceptando el tiempo de inicio de sesión adicional de 5 segundos. 2. Actualice la historia de usuario a 3SP y optimice la solicitud de back-end, esencialmente otorgando a esta historia de usuario una prioridad más alta que otra (que podría no estar "Listo" en este Sprint). 3. Entregue otras historias de usuario primero, luego comience a trabajar en esta, actualícela a 3SP y posiblemente no la entregue en este Sprint.
El propietario del producto debe considerar la nueva información ("retraso de inicio de sesión del usuario de 5 segundos") y decidir en el acto qué hacer.