我所在的团队一直以敏捷的方法非常成功地工作，直到现在，在我们逐步构建产品的过程中，这对当前项目和我们的初始工作都非常有效。
不过，我们现在正进入下一阶段，管理层希望我们自己设定一些具体的截止日期，以便我们能够在几个月内向真正的客户演示和销售。
对于我们想要包含的每一个功能元素，我们都有一个组织良好的大型积压工作，并且对这些单独的功能部分的优先级有很好的了解。
天真的解决方案是获得能够提供演示产品的故事的最小列表，对所有这些故事进行单独估计，然后将它们相加，并与我们的速度相结合，以获得日期，并宣布我们将从那时起进行演示。不过，这并没有留下任何余地，而且随着截止日期的临近，似乎很可能会导致一场疯狂的危机，而我非常想避免这种情况。
作为一种改进，我想增加一些比例的可选故事，作为应急或奖金的改进，这取决于我们的进展情况，但我们不知道什么比例是合理的，也不知道这是否是标准方法。
我还担心的是，必须一次估算我们的所有积压工作，因为这似乎非常耗时，而且我们很可能会在了解该故事之前的几个月内发现更多信息，这将影响我们的估算。
是否有建议的方法来处理设置最后期限以允许敏捷开发过程？我看到的大多数信息似乎都是关于在你有一个固定的截止日期后处理这种情况。我也会感兴趣的任何相关文献或有趣的博客文章，涵盖这个问题。
关于文献：我所知道的关于软件评估的最好的书是Steve McConnel的《软件评估：揭开黑人艺术的神秘面纱》。它涵盖了你的案子。此外，它还描述了估计和承诺之间的差异(换句话说，设置截止日期)，并解释了如何可靠地从第一个中得出第二个。
最简单的解决方案是获得提供可演示的产品，单独评估所有这些产品，以及把它们加起来，结合我们的速度来确定日期，并宣布从那时起我们将降级。不过，这似乎没有留下任何余地随着截止日期的临近，可能会导致一场疯狂的危机我非常想避开。
这是我过去使用过的解决方案。你最初的估计会有点偏离，所以在设定发布日期之前，通过几次额外的冲刺来增加一些放松。如果你落后了，你就可以弥补不足。如果没有，您的产品积压工作将为您提供额外的功能，如果您愿意，可以将这些功能包括在发布中。不过，这将取决于你对团队的速度度量。根据你觉得这个指标对当前团队的准确程度来调整你的松弛度。一旦你有了目标版本，你就可以回过头来看看是否有任何已知的资源限制可能会影响该版本。
您描述的方法可能是正确的。你可能想估计所有想要的功能，并优先考虑UI元素(因为投资者和客户基本上只看到闪亮的UI)，然后你的截止日期将是估计的完成日期；然后以缩放估计的形式添加一些松弛。使用当前生产力和最糟糕时期之间的比率来创建悲观的估计。您可以使用相同的比率来缩放较短的估计值(例如，将您的估计值缩放到最小特征集)。