任務編組必須短小精幹
問：在騎單車的時候，哪一種騎法比較有效率？高轉速或低轉速？
答：從心裡、生理及生物醫學的角度綜合來說，轉速高一點時（約８０至１００RPM），效能會比較好。轉速在８０以下時，騎者會失去量能（＂Momentum＂），讓每一腳踩下去都有必須重新開始的感覺。不但更花力氣，也加重了心理的負擔。
在軟體工程的組織上，也有同樣的考量。例如在實施任務編組（Feature Crew）的環境裡，＂組＂（"Crew”）是工作單元；它必須符合短小精幹的原則才能達到最佳的效能：周期要短；組織要小；開發項目要精幹。
一個任務編組的理想的周期長度是３至５週。如果一個組的周期過長，組員在後期往往失去焦點，忘了當初成立的宗旨，以致失去了衝勁，時間不知不覺地流失，案子變得沒完沒了。站在管理者的角度來看，也是問題重重：周期過長的任務編組的進度不透明，不容易知道什麼時候可以達到預定的目標，讓下一步的規劃困難重重。
一個任務編組的理想的編制是３至５人（１個專案經理搭配１至２位開發工程師和１至２位測試工程師）。如果一個組的編制過大，人多、口雜手也雜，溝通協調變得困難，往往浪費了許多珍貴的時間。更多的時候是角色的定位變得模糊、重疊，不但產生混淆，更容易發生衝突。
一個組的任務（也就是開發項目Feature）通常是跟據以下的原則成立後，再決定它的編制大小及周期長短：
- 一個Feature通常實現一個、或多個邏輯上相關的產品功能。
- 一個Feature通常是一個可以獨立測試的單元。
- 一個Feature通常是一個依賴鏈（Dependency Chain）的一個環節。例如Print Preview是一個Feature，Pring Dialog是另一個Feature。Print Dialog要靠Print Preview來讓它的功能變得完整。相對的，Print Preview也依賴Page Setup（另一個Feature）才能完成它的功能。
如果一個Feature太過龐大，或者太過複雜，不但會有上列工程上的缺點，它還會有多邊的負面影響：
- 專案經理無法獲得對設計的早期回饋。
- 測試工程師無法盡早提供測試結果讓開發工程師有改進的機會。
- 依賴鏈上游的友組無法開始它們的工作，整個大組的工作同時性（Concurrency）降低，影響了全面的生產力。