Scrum en proyectos de software: roles, proceso y velocity

Scrum es adecuado para proyectos de software en los que los requisitos solo se aclaran con el uso: el proyecto avanza en sprints cortos y fijos, y al final de cada uno hay un resultado utilizable que usted puede revisar y repriorizar. Que funcione depende de tres cosas: un Product Owner con capacidad de decisión, una Definition of Done vinculante y un uso sensato de la velocity.

Scrum es uno de los marcos ágiles más conocidos y, al mismo tiempo, uno de los que más se malinterpretan. A veces se presenta como panacea y otras se desprecia como un ritual de reuniones sin utilidad. Este artículo explica a quienes encargan el software cómo encajan en la práctica los roles, los artefactos y los eventos, qué aporta la Definition of Done, para qué sirve la velocity y cuándo es mejor Kanban.

Scrum en proyectos de software: principio básico y roles

Scrum divide un proyecto en sprints: periodos de tiempo fijos de un mes como máximo y, en la práctica, normalmente de dos semanas. Cada sprint termina con un incremento, es decir, un resultado utilizable que las partes interesadas pueden ver y valorar. En lugar de fijar todos los requisitos al principio, tras cada sprint se comprueba si el rumbo sigue siendo el correcto. El marco se basa en la transparencia, la inspección y la adaptación, y reduce el riesgo de desarrollar durante meses algo que no responde a la necesidad real.

En el software a medida esto es especialmente valioso: muchos requisitos solo se vuelven tangibles cuando los usuarios tienen en sus manos una primera versión. El ritmo de sprints hace que este ciclo de aprendizaje sea corto y asequible.

El principio incluye roles claros. Desde la versión de 2020, la Guía de Scrum describe un único equipo Scrum con tres responsabilidades. La antigua distinción entre el equipo Scrum y un «equipo de desarrollo» aparte ya no existe; los desarrolladores son todas las personas que trabajan en el incremento, por ejemplo en frontend, backend, diseño y pruebas.

Product Owner

El Product Owner es responsable del Product Backlog y, con ello, del orden del trabajo. Decide qué se desarrolla a continuación y es una sola persona, no un comité. En los proyectos para clientes, este rol está idealmente de su lado: en alguien que conozca la necesidad del negocio, pueda tomar decisiones y tenga tiempo con regularidad. Si falta cualquiera de las tres cosas, el proyecto se atasca: las preguntas quedan abiertas durante días y el equipo construye sobre suposiciones.

Desa­rro­lla­dores

Los desarrolladores reúnen todas las competencias necesarias para un incremento terminado: frontend, backend, diseño, pruebas y operación. Se organizan por sí mismos y deciden cómo se implementan técnicamente los requisitos. Son corresponsables de la calidad, no una única persona de pruebas al final de la cadena.

Scrum Master

El Scrum Master se asegura de que Scrum se entienda y se practique, facilita las reuniones cuando hace falta y elimina obstáculos, como accesos que faltan a los sistemas de prueba o coordinaciones pendientes con terceros. Apoya al equipo en lugar de asignarle tareas.

Artefactos y eventos de un vistazo

Scrum se compone de pocos elementos que se apoyan entre sí:

Elemento	Finalidad	Duración según la Guía de Scrum
Product Backlog	lista priorizada de todos los requisitos conocidos, alineada con el objetivo del producto	se mantiene de forma continua
Sprint Backlog	los elementos que el equipo desarrolla en el sprint, con objetivo del sprint y plan	se crea en la planificación del sprint
Incremento	resultado utilizable que cumple la Definition of Done	al final de cada sprint
Planificación del sprint	selección de los elementos y formulación del objetivo del sprint	como máximo 8 horas en un sprint de un mes, menos en sprints más cortos
Scrum diario (Daily)	coordinación diaria de los desarrolladores	15 minutos
Revisión del sprint	mostrar el resultado, recoger comentarios y ajustar el backlog	como máximo 4 horas en un sprint de un mes
Retrospectiva	mejorar la colaboración y la forma de trabajar	como máximo 3 horas en un sprint de un mes

Refinamiento del backlog: el trabajo previo que se subestima

El refinamiento no es un evento aparte, sino una actividad continua, y decisiva. Los elementos se preparan para que puedan realizarse dentro de un sprint: con criterios de aceptación claros, dependencias aclaradas y una estimación aproximada. Quien descuida el refinamiento dedica la planificación del sprint a discusiones de fondo y empieza sprints con elementos que resultan demasiado grandes o poco claros.

Un sprint en un proyecto para clientes: así transcurre

1. Planificación del sprint: el Product Owner y el equipo eligen los elementos más importantes del backlog y formulan un objetivo común del sprint, una frase que describe el valor que aporta.
2. Desarrollo: el equipo desarrolla, prueba y se coordina en el Daily. El Product Owner resuelve las dudas con rapidez.
3. Revisión del sprint: el resultado se muestra en vivo, idealmente a usuarios del departamento especializado, que dan sus comentarios de inmediato.
4. Retrospectiva: el equipo analiza qué salió bien y qué quiere mejorar en el siguiente sprint, con medidas concretas.

Para usted, como cliente, esto significa que ve con regularidad software real y funcional en lugar de informes de estado, y puede ajustar las prioridades antes de que se haya comprometido mucho presupuesto.

Ejemplo: un portal de clientes por sprints

Supongamos que una empresa comercial encarga un portal de clientes para pedidos y facturas. La responsable del servicio interno de ventas asume el papel de Product Owner y reserva cada semana horas fijas para resolver dudas. El objetivo del primer sprint es que los clientes puedan iniciar sesión y consultar sus últimos pedidos. En la revisión del sprint, dos empleados prueban la función y comprueban que, sin un filtro por fecha de entrega, nadie encuentra nada. El elemento sube en el backlog y está resuelto dos semanas después, en lugar de aparecer solo en la prueba final, cuando los cambios son mucho más caros.

Definition of Done y velocity: calidad y planifica­ción

Definition of Done: el ancla de la calidad

¿Cuándo está realmente terminada una tarea? Sin una respuesta común surgen malentendidos: para el desarrollo, una función está «terminada» cuando el código funciona; para usted, solo cuando está probada, documentada y se puede utilizar. Una Definition of Done (DoD, definición de terminado) crea compromiso. Se aplica a cada elemento, mientras que los criterios de aceptación describen lo que debe cumplir funcionalmente un elemento concreto. Un ejemplo de DoD:

• El código ha sido revisado por una segunda persona.
• Existen pruebas automatizadas y se ejecutan con éxito.
• La documentación está actualizada.
• La monitorización y el registro de eventos están configurados.
• La función ha sido aceptada en el entorno de staging.

Sin una Definition of Done común, la deuda técnica crece de forma invisible. Cómo evaluar y reducir esa carga heredada se explica en el artículo Priorizar la deuda técnica.

Velocity: una ayuda para planificar, no una comparación de rendimiento

La velocity describe cuántos story points suele completar un equipo por sprint. Los story points son estimaciones relativas: comparan tareas entre sí, no con horas. La velocity no es un requisito de la Guía de Scrum, sino una práctica extendida, y solo sirve para planificar dentro de un mismo equipo.

Las comparaciones entre equipos engañan: un punto significa algo totalmente distinto en el equipo A que en el equipo B. Si la velocity se convierte en indicador de rendimiento, suben las estimaciones, no los resultados. Para el cliente son más reveladores los objetivos del sprint y los incrementos realmente aceptados.

Planificar con realismo también significa tener paciencia. Como valor de experiencia, la velocity se estabiliza tras cuatro a seis sprints; las previsiones fiables de las fechas de lanzamiento solo son posibles después de varias iteraciones. Quien prefiere trabajar sin puntos cuenta, en su lugar, cuántos elementos de tamaño similar se terminan por sprint.

¿Scrum o Kanban? Una guía para decidir

En productos bien definidos y con buen acceso a las partes interesadas, Scrum funciona muy bien. La situación cambia cuando un proyecto depende mucho de sistemas externos, las prioridades cambian continuamente o gran parte del trabajo consiste en soporte y mantenimiento. Entonces suele tener más sentido Kanban, con un flujo de trabajo continuo.

Situación	Más adecuado	Motivo
Producto nuevo o evolución importante con un objetivo reconocible	Scrum	los objetivos del sprint y las revisiones guían el avance
Operación, soporte y corrección de errores	Kanban	las tareas llegan de forma irregular y son difíciles de planificar en sprints
Las prioridades cambian varias veces por semana	Kanban	las nuevas tareas pueden entrar sin esperar al límite del sprint
Fuerte dependencia de terceros, por ejemplo en interfaces o autorizaciones	Kanban o Scrum con márgenes	los tiempos de espera deben hacerse visibles y no pueden desbaratar el sprint
Ningún Product Owner con tiempo y capacidad de decisión	primero aclarar el rol	sin decisiones, cualquier marco carece de base

Elegimos el marco según el contexto, no según la moda. En muchos proyectos combinamos ambos: Scrum para la evolución del producto y Kanban para la operación y la corrección de errores.

Ágil y, aun así, planificable: presupuesto y contrato

Una preocupación frecuente es: «Ágil significa que nunca sabemos cuánto costará». No tiene por qué ser así. Cuando el alcance está claramente definido, ofrecemos preferentemente un precio cerrado. Si el alcance aún está abierto, trabajamos con un marco presupuestario acordado y un backlog priorizado: las funciones más importantes van primero y, tras cada sprint, puede decidirse si el estado alcanzado basta o si tiene sentido añadir más sprints.

Una buena base es un pliego de requisitos (Lastenheft) estructurado; si primero quiere probar una idea, empiece con un MVP. El contrato debería regular el marco presupuestario, la duración del sprint, el papel del Product Owner, el procedimiento de aceptación por incremento y el tratamiento de las solicitudes de cambio. Tanto si se trata de un contrato de obra (Werkvertrag) con precio cerrado como de un contrato de servicios (Dienstvertrag) por esfuerzo con marco presupuestario, haga revisar la fórmula por un abogado.

Errores típicos y checklist para clientes

Errores típicos y cómo evitarlos

• Product Owner sin tiempo: las decisiones se retrasan. Reserve horas fijas en el calendario.
• Revisión solo con los implicados en el proyecto: falta feedback real. Invite a usuarios del departamento especializado.
• Duración del sprint cambiada constantemente: la planificación y la velocity dejan de ser fiables. Elija una duración y manténgala.
• La velocity como indicador de rendimiento: suben las estimaciones, no los resultados. Úsela solo dentro del equipo.
• Retrospectiva sin consecuencias: los mismos problemas se repiten. Acuerde medidas con responsables.
• Scrum a la carta: se eliminan los elementos incómodos, como la revisión o la Definition of Done, y apenas queda nada del beneficio.

Checklist: cómo lograr que Scrum funcione en un proyecto para clientes

• Product Owner con tiempo y capacidad de decisión nombrado
• Duración del sprint definida y respetada con constancia
• Refinamiento del backlog periódico fijado en el calendario
• Definition of Done acordada por escrito
• Velocity utilizada solo dentro del equipo para planificar
• Revisiones del sprint con usuarios reales y no solo con los implicados en el proyecto
• Retrospectivas con medidas de mejora concretas
• Marco presupuestario, procedimiento de aceptación y gestión de cambios regulados por contrato

Cómo le ayuda Nano Concepts

¿Planea un software a medida y quiere saber qué forma de trabajo encaja con su proyecto? Elegimos el marco según el contexto, no según la moda. La primera consulta es gratuita y después recibe un presupuesto transparente. Nuestros paquetes ofrecen un punto de partida: Starter desde 2.500 €, Professional desde 8.000 € y Enterprise según el alcance individual.

Este artículo no sustituye el asesoramiento jurídico.