在我们的团队中，我们正在评估使用看板作为软件开发的组织工具。开发阶段大约需要6个月，团队人数为5人。 我们将所有与客户商定的功能要求，业务规则和使用案例 - 换句话说，宏观要求作为输入。我们将故事中的这些规则转换为看板董事会的“原子”处理单元。看板本身将被用作绩效评估工具和进度路线图。 看板“规定”每个阶段都有一个固定数量的故事，但由于软件是新的和复杂的，“故事”可能会有几百个 - 所以我猜想所有的故事都积压在开始的发展不会是一个明智之举。看板来组织新软件的开发
这种情况的最佳做法是什么？
首先，很少有团队设定积压限制。看板建议在制品（WIP）限制。积压项目很少被视为“正在进行”。其次，考虑到你，或多或少地了解项目的范围，强迫自己人为地限制积压项目的数量是没有多大意义的。
同时你说得对，把几百件物品放在积压物品上是没有意义的。董事会过度拥挤，其有用性将大幅下降。
典型的战略，以组织积压是这样的情况包括：
保持在积压的史诗故事/功能，并将其分割成详细的故事/任务只有当你开始在其中工作。这样你的项目就少得多了，而你仍然能够在开发阶段处理详细的任务。
叠加故事将成为应用程序的相同部分的一部分。如果你已经划分了范围，那么人为地隐藏这些信息就毫无意义。但是，您可以堆叠已连接或将在同一时间完成的工作项目。它使积压更清洁，一旦你开始建造物品，你可以轻松地将它们拆除。
分期积压。如果你有一个粗略的计划，你的开发将如何进行，你可以有几个阶段的积压。早期的是一个盒子，您可以在其中存储所有要构建的功能（甚至可以将一个物理盒子连接到主板上），然后显示只显示下一个时间段的功能。通过这种方式，您可以在板上看到更少的项目，但技术上所有的工作都在那里。
当然，混合所有这些想法是可能的，甚至鼓励，只要它看起来合理。
BTW：您可以在this presentation（幻灯片21）中看到这些技巧中的一些的可视化。
Henrik Kniberg在他关于看板的免费书中描述了如何将WIP限制设置为积压有助于首先关注最重要的功能。
我认为这是一个很好的策略，特别是对于产品所有者。积压仅包含即将到来的时期将要开发的故事，而其他故事可能在思维导图或“愿望清单”中。
我必须不同意：限制积压是一种可能性。可能不在输入栏中，但例如，如果流程有一些优先级列，则最高优先级列可以包含一个限制，因此可能不会推送到许多高优先级任务，因为WIP无法保持这种速度，并且它们将被挂在那里。
谢谢你的回答，很清楚！我还发现你的[博客]（http://blog.brodzinski.com/）是PM信息的好来源 – Roberto