Crear un trabajo pendiente de producto grande
El equipo crea un trabajo pendiente del producto, que normalmente contiene casos de usuario, para representar lo que los clientes necesitan y valoran. A lo largo del proyecto, el equipo agregará información detallada a los casos de usuario, los desglosará en casos más pequeños, los clasificará según su prioridad, realizará cálculos estimativos y, por último, los implementará y entregará los resultados a sus clientes. Al escribir excelentes casos de usuario y actualizar continuamente el trabajo pendiente del producto, el equipo podrá proporcionar más eficazmente valor a los clientes.
Bill Wake resume las características de un buen caso de usuario mediante el acrónimo INVEST (siglas en inglés de independiente, negociable, valioso, calculable, pequeño y susceptible de ser sometido a prueba). Para obtener más información, vea el siguiente sitio web: XPlorations. Mike Cohn explica cómo escribir casos de usuario uno de sus libros. Puede descargar el capítulo pertinente del siguiente sitio web: User Stories Applied for Agile Software Development.
Cuando el equipo cree un caso de usuario, asegúrese de que represente el correspondiente valor para el cliente. Para ello, responda a las siguientes preguntas:
Quién es el usuario
Qué tiene que hacer el usuario
Por qué el usuario necesita hacerlo
En la mayoría de los casos, el equipo puede lograrlo creando un título eficaz. Mike Cohn sugiere la fórmula siguiente: "En mi calidad de <usuario>, necesito <acción> para poder <motivo>". Este enfoque se ilustra en el ejemplo siguiente: "En mi calidad de representante del servicio de atención al cliente, necesito tener acceso a la información de los clientes para poder responder a sus preguntas con mayor rapidez". En muchos casos, el motivo es evidente. Por ejemplo, "En mi calidad de vegetariano, puedo filtrar la vista para ver únicamente las comidas vegetarianas".
Los casos de usuario también se deben definir de tal forma que se puedan implementar en cualquier orden. Sin embargo, no siempre resulta práctico crear casos de usuario completamente independientes. Bill Wake y Mike Cohn describen técnicas que el equipo puede utilizar cuando crear casos de usuario independientes plantee un reto.
Los casos de usuario valiosos e independientes, como se ha descrito previamente, constituyen el trabajo pendiente del producto. Se calculan y clasifican por orden de prioridad. A continuación, el equipo empieza a trabajar en los casos de usuario que ocupan los primeros puestos de la clasificación. Antes de implementar un caso de usuario, el equipo debe disponer de las características de la siguiente lista. El propietario del producto trabajará para asegurarse de que los casos de usuario clasificados en los puestos prioritarios cumplan estos criterios antes de presentarlos en una reunión de planeación de sprint.
Lo bastante reducidos para implementarlos en el sprint
Los casos de usuario que están a punto de implementarse deben tener un tamaño lo bastante reducido para poder finalizarlos en el sprint. El propietario del producto trabajará con el equipo a fin de desglosar los casos de usuario que sean demasiado grandes. Por ejemplo, el caso de usuario "En mi calidad de representante del servicio de atención al cliente, necesito tener acceso a la información de los clientes para poder responder a sus preguntas con mayor rapidez" podría ser demasiado grande para finalizarlo en un sprint. Se podría desglosar en casos como los siguientes: "En mi calidad de representante del servicio de atención al cliente, necesito tener acceso al nombre del cliente y al resumen de llamadas recientes mediante el número de teléfono del cliente" y "En mi calidad de representante del servicio de atención al cliente, necesito tener acceso al historial de llamadas completo del cliente para poder investigar el problema actual con mayor detalle".
Con los detalles suficientes para describir y calcular el trabajo necesario para implementar el caso
Antes de incluirlos en un sprint, se efectúa el cálculo de puntos de cada caso de usuario. Se trata de cálculos intencionadamente aproximados que se utilizan sobre todo para administrar el trabajo pendiente y ayudar a preparar el sprint. Al iniciar un sprint, el equipo desglosará el caso de usuario en las tareas necesarias para implementarlo. El equipo trabajará con el propietario del producto en la reunión de repaso del trabajo pendiente del producto, a fin de determinar qué casos requieren más información antes de poder desglosarlos en tareas y calcular las horas de trabajo. El propietario del producto puede recopilar estos detalles y registrarlos en la descripción del caso de usuario.
Asegúrese de no agregar más detalles de los necesarios al caso de usuario. El caso de usuario debe ser la base de una conversación y negociación con el propietario del producto y los clientes, que continuarán hasta que el caso de usuario quede finalizado y aceptado. Demasiados detalles pueden obstaculizar la negociación creando una idea implícita de precisión que no es exacta.
Definición de los criterios de aceptación
Al final de un sprint, los clientes o el propietario del producto aceptarán el caso de usuario como finalizado o lo rechazarán. Antes de iniciar el sprint, se deben describir los criterios para la aceptación por parte del cliente con tanta claridad como sea posible. Por supuesto, puede suceder que un caso de usuario no acepte por motivos imprevistos. Sin embargo, las conversaciones que el equipo mantiene con los clientes para ayudar a definir los criterios de aceptación ayudarán a asegurarse de que el equipo entienda las expectativas de sus clientes. Los criterios de aceptación se pueden utilizar como base para las pruebas de aceptación, a fin de permitir una evaluación más eficaz de si un caso de usuario ha finalizado o no.
Epopeyas y temas
Se insiste con frecuencia en que los casos de usuario deben ser pequeños. Esto es así para aquellos que están a punto de implementarse. Sin embargo, los casos con menor rango pueden ser más grandes. De hecho, que sean grandes es una manera eficaz de impedir que el trabajo pendiente del producto sea demasiado grande para administrarlo bien. Los casos de usuario se pueden desglosar en casos de usuario más pequeños a medida que se acercan la parte superior de la clasificación según su prioridad del trabajo pendiente del producto. Resulta útil considerar los casos de usuario grandes como epopeyas y temas.
Las epopeyas son casos de usuario de gran tamaño que representan una cantidad de trabajo significativa. Al desglosar una epopeya, se pueden crear numerosos temas y otros casos de usuario más pequeños.
Los temas son casos de usuario de tamaño relativamente grandes, generalmente mayores de lo que se implementaría en un sprint. Antes de que el equipo implemente un tema, se debe desglosar en casos de usuario menores.
Al clasificar trabajo pendiente del producto según su prioridad, deben desglosarse las epopeyas y los temas más próximos a la parte superior. A continuación, deberán clasificarse según su prioridad los nuevos casos de usuario, más pequeños. Cuando haya finalizado, los casos de usuario de máxima prioridad deberían ser lo bastante pequeños para implementarlos. En general, la mayoría de los casos de usuario son más grandes a medida que se desciende por el trabajo pendiente clasificado según su prioridad.
Picos
En ocasiones, el equipo tendrá que realizar trabajos que no sean una implementación directa de un caso de usuario. Este trabajo se denomina pico. Tres tipos comunes de picos son investigación, errores pendientes y mejoras de procesos o de ingeniería. Para crear un pico en Team Foundation, cree un elemento de trabajo de caso de usuario, establezca su tipo en Pico y, a continuación, clasifíquelo según su prioridad en el trabajo pendiente del producto, junto con los demás casos de usuario.
Investigación
La investigación se produce cuando hay preguntas abiertas sobre un caso de usuario que se deben responder para poder desglosar completamente en tareas el caso de usuario y calcularlo. Por ejemplo, el equipo se encuentra con el caso "En mi calidad de viajero frecuente, puedo reservar viajes de premio" durante una reunión de planeación de sprint. Después de debatirlo, tienen más preguntas que respuestas. El equipo crea un caso de usuario que represente este pico. " Como miembro del equipo puedo entender lo que significa "reservar viajes de premio" y, por tanto, puedo escribir los casos para incluirlos en sprints futuros". El equipo determina cuántas horas está dispuesto a dedicar a la investigación y escribe ese número como el tiempo limitado disponible para el pico. Ninguno de los casos escritos durante el pico se pueden realizar durante esa iteración. El trabajo se debe programar para una iteración futura utilizando el trabajo pendiente del producto.
Errores pendientes
El mejor momento para corregir un error es cuando se encuentra. Si no puede corregirlo en el mismo día en que lo encontró, debe crear un elemento de trabajo de error para asegurarse de no perderle la pista. Asegúrese de no acumular errores. Si el equipo acumula errores, cree un caso de usuario y vincule los errores al pico, para poder calcularlo y clasificarlo según su prioridad junto con los demás casos de usuario y picos.
Mejoras de procesos o ingeniería
El equipo realizará mejoras de procesos o ingeniería que le ayudarán a realizar correctamente su labor. Con frecuencia, estas mejoras se identifican durante las reuniones retrospectivas de los sprints y las reuniones de Scrum cotidianas. Por ejemplo, puede que el equipo necesite mejorar la cobertura de código de las pruebas unitarias, o reducir el tiempo de compilación en el servidor de integración continua.