在我們的團隊中，我們正在評估使用看板作爲軟件開發的組織工具。開發階段大約需要6個月，團隊人數爲5人。 我們將所有與客戶商定的功能要求，業務規則和使用案例 - 換句話說，宏觀要求作爲輸入。我們將故事中的這些規則轉換爲看板董事會的「原子」處理單元。看板本身將被用作績效評估工具和進度路線圖。 看板「規定」每個階段都有一個固定數量的故事，但由於軟件是新的和複雜的，「故事」可能會有幾百個 - 所以我猜想所有的故事都積壓在開始的發展不會是一個明智之舉。看板來組織新軟件的開發
這種情況的最佳做法是什麼？
首先，很少有團隊設定積壓限制。看板建議在製品（WIP）限制。積壓項目很少被視爲「正在進行」。其次，考慮到你，或多或少地瞭解項目的範圍，強迫自己人爲地限制積壓項目的數量是沒有多大意義的。
同時你說得對，把幾百件物品放在積壓物品上是沒有意義的。董事會過度擁擠，其有用性將大幅下降。
典型的戰略，以組織積壓是這樣的情況包括：
保持在積壓的史詩故事/功能，並將其分割成詳細的故事/任務只有當你開始在其中工作。這樣你的項目就少得多了，而你仍然能夠在開發階段處理詳細的任務。
疊加故事將成爲應用程序的相同部分的一部分。如果你已經劃分了範圍，那麼人爲地隱藏這些信息就毫無意義。但是，您可以堆疊已連接或將在同一時間完成的工作項目。它使積壓更清潔，一旦你開始建造物品，你可以輕鬆地將它們拆除。
分期積壓。如果你有一個粗略的計劃，你的開發將如何進行，你可以有幾個階段的積壓。早期的是一個盒子，您可以在其中存儲所有要構建的功能（甚至可以將一個物理盒子連接到主板上），然後顯示只顯示下一個時間段的功能。通過這種方式，您可以在板上看到更少的項目，但技術上所有的工作都在那裏。
當然，混合所有這些想法是可能的，甚至鼓勵，只要它看起來合理。
BTW：您可以在this presentation（幻燈片21）中看到這些技巧中的一些的可視化。
Henrik Kniberg在他關於看板的免費書中描述瞭如何將WIP限制設置爲積壓有助於首先關注最重要的功能。
我認爲這是一個很好的策略，特別是對於產品所有者。積壓僅包含即將到來的時期將要開發的故事，而其他故事可能在思維導圖或「願望清單」中。
我必須不同意：限制積壓是一種可能性。可能不在輸入欄中，但例如，如果流程有一些優先級列，則最高優先級列可以包含一個限制，因此可能不會推送到許多高優先級任務，因爲WIP無法保持這種速度，並且它們將被掛在那裏。
謝謝你的回答，很清楚！我還發現你的[博客]（http://blog.brodzinski.com/）是PM信息的好來源 – Roberto