專案組一直在推敏捷開發，但發現一個關於每日例會的問題。

場景：

　　每日例會是早上9：00, 把大家召集起來，這時有個主持人（每日輪流), 一個一個詢問團隊成員昨天做了什麼，今天做了什麼， 並記錄在一個本子上。

　　有時大家比較忙時，主持人會一個個去詢問團隊成員工作狀況。

問題：

     每日例會不應把每日的進度放到一個本子裡，這會導致沒有多少人去會關心進度問題，想了解進度的人（比如上級領導）也只能找專案經理，而他也只能憑個人感覺說出來；

     不應該有個主持人，這會導致主持人過於繁忙，而其他人投入度降低（只關注自己的問題），建議每人個人主動去講解自己的工作和計劃，主動，自發和自組織，這才是關鍵；

     最糟糕的是，主持人挨個詢問，這壓根就不能叫站立會議（只有主持人站著），只能叫任務跟蹤。

     總結：站立會議 沒有 故事牆，是沒辦法把站立會議的成果 貢獻出來，這樣會導致反饋不足。

解決辦法：

     建立故事牆，把故事分解成一個個小任務，並按優先順序從上到下排列。標明未處理， 正在處理，已完成的任務。

     團隊成員必須都到故事牆前，輪流講解。  自己昨天做了哪些任務；完成了那些；未完成的任務（為什麼沒完成？，需要什麼幫助？，或換人認領？），今天打算幹什麼（把一些未處理的任務移到正處理欄），最後如果有什麼心得可以分享給大家，如果有苦難也要及時求助。（任務標籤也可以寫上checkout 的名字，不是為了跟蹤，而是為實時知道誰在做哪個任務好及時溝通）。

故事牆更進一步的思考：

故事牆過高：

     有些專案把故事牆放到很高，為什麼要放這麼高？我總結為：這個跟他們的位置有關係，因為他們是做成一條線的， 為了讓遠處的成員也能看到，就把故事牆放高了。

　　這裡有個問題是：他們的座位不合理，坐成一條直線，不利於最好的溝通 ；

     故事牆放過高也不好，看不清楚，修正故事 也不方便。

可升降故事牆：

      使用可升降的故事牆；如果高優先順序的故事完成了，可以上升故事牆；人們就可以關注到現在要關注的故事，而不是已完成的。

      想想這也有問題，為什麼要升降，是不是說明當前sprint中的故事太多了呢？ 這應該是提示.

      如果sprint 可以完成，說明sprint 週期太長了，可以縮的更短些（縮短反饋週期);

      如果sprint 不能完成，說明sprint 承諾的太多了。

      sprint 能不能完成可以從 burndown 燃盡圖看出來，如果曲線在 計劃斜線的上方，說明是承諾太多了，要減少故事。