2.9.3 Backlog
Una vez que queda claro quienes serán los usuarios y la duración del sprint y los miembros del equipo, se definen las tareas y se agregan a un backlog (es una lista de tareas que se deben realizar). Se pueden clasificar de la siguiente manera:
User Stories: Es una lista de los requerimientos que necesitan cumplirse en el sprint, debe ser de utilidad para el usuario. Ejemplos:
Registrar los usuarios con correo electrónico
Registrar los usuarios con Facebook.
Task: Son las tareas que se necesitan realizar para el User Story. Las tareas deben ser completadas en máximo un día de trabajo. Las tareas se pueden ir detallando antes del inicio de cada sprint. No se trata de detallar todo el sistema en un inicio si no ir agregando los detalles poco a poco. Ejemplos:
User Story: Registrar los usuarios con correo electrónico Tasks (Tareas):
Crear el script de la base de datos para registrar la tabla de usuarios.
Crear el servicio para registrar los usuarios.
Crear el componente en Angular
Crear las pruebas unitarias para el servicio
Crear las pruebas con protactor.
Features: Como el sprint se trata de dividir un user story en tareas mas sencillas, para ir entregando un producto minimo viable (MVP) y luego irle agregando mas funcionalidad, el feature es una colección de User Stories.El feature terminado puede terminarse en varios sprint. Ejemplos:
Feature: Opción para registrar usuarios User Stories
Registrar los usuarios con correo electrónico
Registrar los usuarios con Facebook
Registrar los usuarios con Google
Registrar los usuaarios con Linkedin
Epic: Es una colección de User Stories que pertenecen al mismo módulo o característica para alcanzar una meta. Por ejemplo serían todas las user stories para controlar la caducidad de los productos
Una vez definido se registran user stories se les asigna una prioridad y se agregan al backlog que contiene la lista de las user stories. En el inicio de cada sprint se eligen que user stories se van a desarrollar. El equipo de desarrollo puede ir tomando las tareas mas importantes primero y cuando termina una puede tomar la siguiente disponible.
Recomendaciones para crear User Stories
Se recomienda que las User Stories sean:
Independientes: no debe interferir con otras user stories.
Entregar algún valor al usuario: Todas las user stories deben agregarle un valor al usuario.
Debe terminarse durante un sprint.
Deben proporcionar la información para estimar el tiempo necesario para completarla
Deben ser probadas: Se deben definir los criterios de aceptación, el cual puede sser checklist con la funcionalidad que el usuario espera.
Se revisa con el cliente las prioridades a entregar en cada sprint.
Puedes ver la documentación oficial aquí de momento solo esta en inglés
Como definir las User Stories
Antes de empezar a programar o pensar en las soluciones debes pensar mucho en el problema que se desea resolver, por ejemplo puedes preguntar por ejemplo 5 veces el porque y el para que es necesaria realizar tal opción. Al pensar mas en el problema y observando como es el proceso actual antes de empezar a programar puedes entregar un sistema que resuelva realmente la necesidad.
Es mejor dedicar un buen tiempo a analizar y probar las posibles soluciones junto con los usuarios, desde el inicio prototipos antes de definir y estimar tiempos.
Se recomieda incluir lo que requieren hacer las personas, que problema se soluciona, que está pasando por no contar con esta función y qué es lo que esperan obtener con la tarea.
Ejemplo:
Las personas desean realizar compras en el sitio web sin tener que registrarse. Es más fácil para ellos registrarse con su login de Linkedin, Facebook o Google.
Actualmente según los datos de google analytics mucha gente al ver el formulario de registro abandona la página y su carrito de compras, por lo cual se están perdiendo posibles ventas.
Se espera que al agregar este login con redes sociales se incrementen las ventas en línea.
Al dividir las tareas del User Story debes incluir las tareas de desarrollo, creación o acutalización de base de datos, testing, etc. Las tareas del user story deben completarse en menos de un día.
Ejemplo de un User Story
Para la aplicación de ejemplo un User Story sería:
Nombre: Servicio para registrar las categorías de los productos
Descrición: Un usuario de tipo Administrador registra las categorías de todos los productos, de esta manera mas adelante podrá asignar a cada vendedor las categorías de productos que debe vender y cuidar la fecha de caducidad.
Criterio de Aceptación:
Debe validar que solo los usuarios de tipo administrador tengan acceso a esta opción en el menú.
Se deben crear, modificar y borrar categorías.
Si un usuario no es administrador y quiere acceder a la página directamente debe mostrarle un error.
Prioridad: 1
Puedes ver los siguientes links en inglés para aprender mas sobre scrum y las buenas prácticas
Last updated
