敏捷實戰分享:Runtastic停止了估算故事並改善衝刺,效率提高30%
我們的一些團隊成員是Allen Holub的追隨者。他是noEstimates方法的堅定倡導者。我們決定嘗試一下。我們想測試一下,如果我們跳過故事的評估估算,而完全依賴我們的直覺判斷將發生什麼。我們還希望瞭解是否可以找到一種方法來預測衝刺併發布預測,而無需建立單獨的流程。
我們立即感到不必再處理故事點了,這樣就根本沒有機會談論擺在我們面前的工作的複雜細節。藉助INVEST原則(不必擔心評估E,一個故事能在沒有實際估算下變成可估算了),我們設法減少了會議時間,使我們有更多時間進行實際工作。同時,我們在衝刺期間遇到的驚喜也更少。
使用這種新方法,我們可以在三個月內將平均週期時間減少30%。對於團隊來說,這個新流程變得更加自然。維持也更容易。我們沒有依靠任何儀式大師來使我們前進。
“我們設法減少了開會時間,並且在衝刺期間遇到的驚喜也更少了。”
在高階團隊中,我們將故事分解為任務。我們任務的目標不是將我們的故事切成相同大小的單元,例如“需要1個小時的工作”。相反,我們使用任務將故事分解為自然的最小單元。這意味著一項任務可能只需要30分鐘,而另一項任務可能需要一整天。任務是故事的邏輯單元,可以獨立進行並且可以執行。
事實證明,雖然我們完成的故事數量因衝刺而異,但我們的任務數量卻沒有。透過簡單地計算“每人每天的任務”,我們找到了一個指標,可以用來更準確地預測我們的速度。該指標在許多層面上都超越了故事點:
- 無需其他任何程式即可維護此號碼
- 它來自我們已經在做的工作
- 它節省了我們的時間,使我們能夠專注於交付價值
現在,我們使用此指標來檢查我們的衝刺承諾,因此可以確保我們不會使工作負擔過重或削弱我們的流程。
詳細點選標題
相關文章
- [原]敏捷開發-故事與估算敏捷
- VS提高實戰效率
- 敏捷最佳實踐:設計衝刺完整指南 -Useberry敏捷
- 【DevCloud·敏捷智庫】如何利用故事點做估算devCloud敏捷
- Choerodon豬齒魚敏捷管理實踐(二)——衝刺管理敏捷
- 團隊作業4:專案衝刺-敏捷衝刺日誌的集合貼敏捷
- 敏捷衝刺day2--數字工匠隊敏捷
- 敏捷衝刺day4--數字工匠隊敏捷
- 敏捷估算:點之殤敏捷
- 衝刺05
- 衝刺08
- 衝刺03
- 衝刺04
- 衝刺07
- 衝刺2
- 衝刺1
- 衝刺3
- 衝刺4
- 衝刺8
- 衝刺7
- 衝刺6
- 衝刺5
- 衝刺10
- 衝刺9
- 敏捷實施中的估算與實際效果 - Ottinger敏捷
- 採用四緩衝提高自繪介面的效率
- 利用並行提高sql執行效率(轉)並行SQL
- 4.29(衝刺一)
- 5.2(衝刺四)
- 5.5(衝刺七)
- 專案衝刺
- 衝刺計劃
- 減輕敏捷實戰中故事點發生漂移的風險 - modernanalyst敏捷NaN
- 專案衝刺——第二篇Scrum衝刺部落格Scrum
- 專案衝刺——第三篇Scrum衝刺部落格Scrum
- 專案衝刺——第五篇Scrum衝刺部落格Scrum
- 敏捷中需要分享故事點給利益相關者嗎?敏捷
- 為了提高開發效率,我實現了 uTools 的超級皮膚