更快地完成工作和反饋
scrum團隊應該在工作方式上保持透明：讓利益相關者更緊密，每天與他們合作，讓反饋在兩個方向流動，並分擔採取某個方向的風險。
使工作進度更加明顯
團隊可以看到進度：燒毀圖表和白板是顯示衝刺目標進度的傳統方法。乙個簡單的報告顯示各級規劃的進展，從sprint一直到視覺，可以非常有效地減少「何時完成？」的數量。交談。
更新資訊的自由流動
資訊需要雙向傳播。利益相關者和產品角色，特別是那些直接與團隊合作的人，也必須是透明的。可以向團隊顯示路線圖，發布計畫或完成定義形式的產品方向，以便他們了解他們承諾實現的總體目標和期望。
什麼scrum master可以幫助
在scrum中，不是為scrum master工作的團隊，而是scrum master，他們致力於促進開發團隊的工作。scrum master必須與產品負責人，開發團隊和其他相關方合作，以了解事件和工件是否完全透明。scrum master必須幫助每個人在沒有完全透明的情況下應用最合適的實踐。scrum master可以通過檢查工件，感知模式，仔細聆聽所說的內容以及檢測預期結果和實際結果之間的差異來檢測不完整的透明度。
事件的透明度
sprint是所有其他活動的容器，scrum中的每個活動都是檢查和調整某些內容的正式機會。這些活動專門用於實現關鍵的透明度和檢查。未能包括任何這些事件會導致透明度降低，並且失去了檢查和適應的機會。
採用使用者故事
使用者故事旨在傳達產品所有者和scrum團隊之間的共享理解。有一種標準的已接受和預期的格式有助於促進一致性，並且附有故事的良好驗收標準定義並闡明範圍。
但是，為什麼敏捷宣言的原則之一有乙個很好的理由：
「向開發團隊內部和內部傳達資訊的最有效和最有效的方法是面對面交流。」
對使用者故事的理解及其他
概述 這幾年一直在思考敏捷開發中的使用者故事，並嘗試在工作中使用使用者故事。發現不論敏捷開發還是瀑布式開發，很多東西都是相通的 或者說一樣的 在本文的後半部分我根據對使用者故事的實踐和理解列出一些內容。你會發現，這些內容與 系統分析與設計方法 第7版 第7章 使用用例建模系統需求 p179 中的 幾...
使用者故事，史詩故事和主題故事
本文 scrum中文網 敏捷團隊喜歡以一種剛剛好的方式處理需求。我們採用最低限度地 逐漸細化並儲存在產品待辦項 product backlog 中的特性描述文字，來替代傳統長篇大論的需求文件。我們發現使用者故事是最好的描述方式，這種形式能夠捕獲到特性足夠多的資訊，並促進產品負責人和團隊在後續進一步交...
使用者故事驅動的敏捷開發（建立backlog）
本系列的第一篇 使用者故事驅動的敏捷開發 規劃篇 跟大家分享了如何使用使用者故事來幫助團隊建立需求的過程，在這一篇中，我們來看看如何使用這些使用者故事和功能點形成產品backlog。產品backlog是敏捷開發中用來管理需求列表，排定優先順序，形成迭代計畫，組織開發 測試和交付過程的工具。可以說，產...