專案組一直在推敏捷開發，但發現乙個關於每日例會的問題。
場景：有時大家比較忙時，主持人會乙個個去詢問團隊成員工作狀況。
問題：不應該有個主持人，這會導致主持人過於繁忙，而其他人投入度降低（只關注自己的問題），建議每人個人主動去講解自己的工作和計畫，主動，自發和自組織，這才是關鍵；
最糟糕的是，主持人挨個詢問，這壓根就不能叫站立會議（只有主持人站著），只能叫任務跟蹤。
總結：站立會議 沒有 故事牆，是沒辦法把站立會議的成果 貢獻出來，這樣會導致反饋不足。
解決辦法：
建立故事牆，把故事分解成乙個個小任務，並按優先順序從上到下排列。標明未處理， 正在處理，已完成的任務。
團隊成員必須都到故事牆前，輪流講解。 自己昨天做了哪些任務；完成了那些；未完成的任務（為什麼沒完成？，需要什麼幫助？，或換人認領？），今天打算幹什麼（把一些未處理的任務移到正處理欄），最後如果有什麼心得可以分享給大家，如果有苦難也要及時求助。（任務標籤也可以寫上checkout 的名字，不是為了跟蹤，而是為實時知道誰在做哪個任務好及時溝通）。
故事牆更進一步的思考：
故事牆過高：
有些專案把故事牆放到很高，為什麼要放這麼高？我總結為：這個跟他們的位置有關係，因為他們是做成一條線的， 為了讓遠處的成員也能看到，就把故事牆放高了。
這裡有個問題是：他們的座位不合理，坐成一條直線，不利於最好的溝通 ；
故事牆放過高也不好，看不清楚，修正故事 也不方便。
可公升降故事牆：
使用可公升降的故事牆；如果高優先順序的故事完成了，可以上公升故事牆；人們就可以關注到現在要關注的故事，而不是已完成的。
想想這也有問題，為什麼要公升降，是不是說明當前sprint中的故事太多了呢？ 這應該是提示.
如果sprint 可以完成，說明sprint 週期太長了，可以縮的更短些（縮短反饋週期);
如果sprint 不能完成，說明sprint 承諾的太多了。
sprint 能不能完成可以從 burndown 燃盡圖看出來，如果曲線在 計畫斜線的上方，說明是承諾太多了，要減少故事。
SCRUM和使用者故事（User Story）
user story是一種描述使用者需求 業務價值的最佳實踐，但不是說非要用user story的形式來描述需求，而且通常在乙個sprint backlog中，尤其在最初的若干sprint中會存在一些架構設計 技術調研 介面定義 獲取背景知識這些方面的事項和任務需要處理，這意味著乙個sprint不是...
Scrum的心跳 每日站立
每日爭議 是監控scrum專案心跳的重要事件之一，也是團隊的 好習慣 每日站立是scrum團隊應該擁有的最有價值的實踐之一。每日爭議的目的是通過回答3個問題來增加團隊的溝通和關注 當團隊沒有舉行每日站立會議時，團隊可能會失去溝通，重點和團隊的動力，以便按時以適當的質量建立合適的產品。通常情況下，團隊...
循序漸進的敏捷 每日例會
通過一段時間的推行，每日例會也取得了不錯的效果，大家也都明白各自需要做的 工作事項。敏捷開發中的每日例會，就是為了確定下一天所需執行的工作，以最大可能地履行其承諾。團隊的每個成員都應該描述自上次會議以來所做的工作。他們計畫在當天完成的工作，以及可能對其他團隊成員產生影響或需要獲得其他團隊成員幫助的任...