Afecta sobre todo a los usuarios pero también a los desarrolladores y nos lo encontramos tanto en enfoques clásicos como ágiles.
Cuando nos aproximamos a al definición de la primera entrega que va a producción (en el caso de un enfoque iterativo incremental se han podido liberar previamente versiones parciales que no han llegado a producción), el usuario empezará a querer incorporar funcionalidades que considera necesarias aún sabiendo que no son imprescindibles (los desarrolladores que en esto no deberían intervenir, pero que ya conocen el negocio, se convierten incluso en cómplices), sin tener en cuenta que tras esta versión, vendrán otras en las que podrán ir incorporando estas funcionalidades según las prioridades que establezcan.
Si este antipatrón se materializa presenta como inconveniente que se asuma una mayor capacidad de trabajo que la que el equipo puede soportar, lo que provocará, además del correspondiente overtime, una versión del producto con un peor acabado: más errores y más deuda técnica, y que no se cumplan los compromisos adquiridos ya que probablemente alguna funcionalidad no de tiempo a tenerla lista (esto último puede parecer menos importante pero no lo es, ya que la confianza está muy ligada al cumplimiento de los compromisos).
Es un ejemplo claro de que más es menos cuando se toman decisiones que no son compatibles con las posibilidades del equipo de proyecto.