在前兩天所述，卡紙在我們日常開發的情境，已足夠成為資訊的載體，他協助我們索引到釐清需求當天的對話與白板、丟到線上對話平台的照片、各項討論。只要有當時我們共同抽象化出來的簡述，我們就可以找到這些更多資訊。

其實透過數位照片、上傳到網路空間 (無論是雲端硬碟或是 Slack 之類的對話平台)，就已經是數位化的一種。但更近一步要思考的是，什麼時候需要拓展到數位化管理工具，像是 Jira、Trello 等？

如果現在對我們來說，這樣的方式就足夠溝通了，那我們也沒必要為用而用，畢竟「個體與互動，重於流程與工具」。

一個可能會被提出來的情境是——「Product Backlog Items 數量太多，需要透過數位化的方式協助管理。」真的是這樣嗎？我們是有需要留那麼多個項目下來嗎？這邊引用一個極端的例子，是我今年在 Awakener, Daniel Tang 的 CSM 課程聽他所述：「我沒有一個 Product Backlog，因為我認為忘記的其實都不太重要。 (非原話重現)」。當我們處於這類情境時，我們該思考的是我們是不是保留太多雜訊、過期的資訊在我們的 Product Backlog 裡了呢？

另一個情境可能是——「Product Backlog Items 太混雜了，我透過卡紙難以管理。」這的確是容易遇到的情境，但真正的問題可能是，我們只仰賴在同一個媒介下，呈現所有不同顆粒度大小的項目。在過去學習裡，Product Backlog 應該有大有小、越低 Priority 的優先度越低，成線狀的方式排列。但這其實只是在協助我們理解較低 Prioririty 的 Item，應該越後面被拆解與釐清。事實上我們是可以用不同的方式去展現，比如說 Product Roadmap 顯示 1 年以上的計畫與較大的顆粒度，透過 Release/Iterations Plan 顯示當前目標在數個 Sprints 的預期與顆粒度，最後在 Product Backlog 聚焦在最近 1~3 Sprint 的 Item。這部分我們後面會再提到。沒有做到這些，就算轉移到數位化管理工具，也是無法解決我們的痛點，反而更容易累積大量的 Item，讓我們更容易失焦。

那我的經驗裡，是什麼促使我們將紙本的 Product Backlog 拓展到數位化管理呢？這個提問我們明天繼續聊。