作為
測試人員，以前的我們每天參照圖1來了解手上還有多少活。
圖1：等待測試的用戶故事個數
存在的問題：
(1)只有故事數量導致我們看不到故事后面
工作量的變化。例如，今天測試通過，關閉了3個小的用戶故事，但同時今天開發提交了3個大的用戶故事。從數量上看，昨天和今天的待完成工作是一樣的。在這張圖表的暗示下，我們有時要刻意地拒絕優先測試那些比較簡單的故事以便讓這個數字快速變小的誘惑。
(2)只看目前手頭還有多少未完成的工作無法讓人產生太多的成就感或者緊迫感。因為伴隨著每日構建，待測試的故事數此消彼長，其數量就象一個隨機數，從中我們無法感知測試進度是否在可接受的范圍內。還有5個用戶故事沒有測試？多嗎？少嗎？來得及嗎？沒人知道。
最近，我們改為每天參照圖2來了解測試進度是否健康。
圖2：測試&開發進展圖
線1：這個迭代至今測試累計完成的工作量
線2：這個迭代至今開發累計實際已完成（已提交測試）的工作量
線3：這個迭代至今開發累計理想需要完成（應該提交測試）的工作量
差距1：線1和線2的差距代表測試人員追趕開發實際進度的情況
差距2：線2和線3的差距代表開發實際進度追趕開發理想進度的情況
好處：
?。?）關注工作量而非數量可以更實際地反應進度。除了關注測試進度，也關注開發進度其實也是確保測試進度的方式之一，因為這可以及時預防開發滯后導致測試被動的風險。
?。?）有了歷史數據的趨勢圖，有了和另外的工作量的參照后，從圖2上我們可以感到更多的成就感或者緊迫感。這有點象我們跑步的時候如果有個領跑員在身旁，往往會跑得更帶勁、更有節奏。個人感覺做軟件和跑步有一點不同的是，我們更多的時候追求的不是絕對速度，而是相對速度。因為絕對速度（團隊生產率）的提高需要較長的時間，而保證相對速度（團隊按照預期將軟件產品交付使用；團隊內開發按照預期的速度將軟件交付測試，測試按照預期的速度將開發好的部分完成測試和缺陷修復的驗證。。。）則是每個迭代都要力爭的。