A mi forma de ver, a scrum le falta un nivel de zoom, o de detalle en como trata los requisitos, por eso, definir las tareas de la pila del producto, o product backlog, se suele terciar de forma confusa.
¿Qué es cada elemento de un product backlog?: ¿una funcionalidad? ¿una historia de usuario? ¿un caso de uso?.

 Aclara bastante trabajar con tres niveles de requisitos:

1. Nivel de product manager: funcionalidades generales que quiere el cliente
2. Nivel de usuario: historias de usuario que componen cada funcionalidad
3. Nivel del equipo: tareas de programación en las que se descompone cada historia

Los podemos llamar así, si tenemos en cuenta el rol de quien emplea los requisitos a ese nivel. También se podrían llamar: nivel de producto, nivel de versión y nivel de sprint; es sólo cuestión de adoptar un criterio de nombres conocido y válido en la organización.

Supongamos que necesitamos un método para formular el número de naranjas que caben en un volumen determinado, y que necesitamos que sea un método fiable para que una ingeniería lo pueda emplear con garantías, tanto si lo aplica con furgonetas, camiones, barcos...

Deberíamos determinar primero el volumen. También habría que tener en cuenta el tipo de naranjas, porque de una a otra variedad, el diámetro medio de la pieza cambia sustancialmente. Se podrían establecer criterios de clasificación de la mercancía en función de la variedad de la que se trate, o del porcentaje de cada una, si es una mezcla. También habrá que tener en cuenta si se carga a granel o en cajas y el tipo de estas...

El blog de requirements.net apunta el carácter paradójico de algunos CIOS, analizando las respuestas de una encuesta hecha a directivos de empresas TIC:

• El 75% afirma no conocer bien qué es desarrollo ágil.
• El 75% afirma estar dispuesto a implantar una metodología ágil.

Recuerdo el CEO de una firma de software, que a mi recomendación para adoptar prácticas de CMMI me respondió (absolutamente serio y convencido de lo que decía): "No, mejor ISO 9000. CMMI no es un modelo conocido, sin embargo ISO 9000 sí, y es mejor para la empresa decir que trabajamos con ISO 9000"

Algunos directores son así :-)

La priorización de la pila del producto (product backlog), los formatos de reuniones , y las iteraciones breves hacen que los campos de Scrum sean especialmente hostiles a las leyes de Parkinson.
Y aún más si se añade a la pila del sprint alguna tarea de "reserva" por si se hubieran  sobre-estimado los tiempos

Leyes fundamentales de Parkinson:

1ª. "El trabajo crece hasta llenar el tiempo de que se dispone para su realización".
2ª. "Los gastos aumentan hasta cubrir todos los ingresos".
3ª. "El tiempo dedicado a cualquier tema de la agenda es inversamente proporcional a su importancia".

En JavaHispano está publicado el podcast que con Jorge Rubira y Alfredo Casado, grabé el oto día, charlando... como no! :-)  de cosas de Scrum, de gestión ágil,  gestión predictiva...

•  JavaHispano Podcast 009 - Flexibilidad con Scrum, entrevista a Juan Palacio

El método de trabajo que dibuja scrum para trasladar a la programación los principios de desarrollo ágil de los "campos de scrum", tiene los siguientes roles:

• Propietario del producto
• Equipo
• Scrum Master
• Otros implicados
  

y considera como comprometidos con el desarrollo (cerdos): al cliente, al equipo y al Scrum Master; y como implicados (gallinas) al resto. (gallinas y cerdos)

Pero el Scrum Master ni desarrolla ni gestiona el proyecto. Ambas cosas las hacen el equipo y el propietario del producto; por eso... ¿Es acertado darle un rol de cerdo en el equipo?. En los campos de scrum no hay tal rol (?)

Mantenimiento:
"Modificación de un producto de software, después de su entrega para corregir errores, mejorar el rendimiento u otros atributos o adaptar el producto a cambios del entorno".
IEEE Std. 1219-1998

 En la gestión ágil de un producto de software, ¿cuándo acaba el desarrollo y empieza el mantenimiento?

En cuanto a calidad... así, así: el 46% dice que los resultados usando Scrum son los mismos o peores que con otros métodos, mientras que el 54% dice que son mejores.
Sin embargo sobre la productividad la opinión es bastante más favorable: el 74% dice que con Scrum han mejorado la productividad; y en lo que también saca buena nota es en la "simpatía" y buena disposición hacia el modelo: Le cae bien al 77%, y hace que el equipo tenga más claros sus objetivos y lo que se espera de él (80%).
 

En los cursos de formación de Scrum de Ken Schwaber en Londres en otoño de  2005, los gestores de proyectos tradicionales se quedaban a cuadros: "Entonces, si no descomponemos en un WBS, no planificamos, no asignamos el trabajo ni seguimos su evolución para arbitrar medidas de corrección... entonces ¿en qué se queda nuestro trabajo?".

Este cambio es un elemento cultural duro, pero sin embargo es una de las claves del funcionamiento de los equipos ágiles.

Este es un indicador curioso para medir el nivel de "gasolina" de los equipos ágiles: la motivación. Se trata del "Calendario de Niko-niko" (Niko-niko Calendar), una especie de "twiter" de la moral, actualizado a diario y situado en un lugar visible junto con el resto de indicadores de seguimiento diario empleados por el equipo (sprint backlog, gráfico burn down, pizarras Kanban...)  y viene a ser una cosa así: 

Esta es la comparación que Jason Gorman hace entre la propagación de los virus y los consultores de Scrum. Jason es un consultor inglés, beligerante y sarcástico con quienes, con mayor o menor conocimiento de los principios de la agilidad, dogmatizan anclados en ella.

El diseño del modelo de gestión ágil DSDM incluye antes de comenzar con las iteraciones (funcional - Diseño - e implementación), un punto de inicio representado por el triángulo de su diagrama ("el queso ") con las fases:

• Pre-proyecto
  
• Estudio de viabilildad
• Estudio de negocio