Alan Shalloway在精益-敏捷郵件組中寫道：

你有什么比較不錯的，可以寫進合同（或者工作計劃）里，用來跟蹤一個軟件承包方的進度/效能的度量方法推薦嗎？【...】然而【問題在于】，這一困惑在敏捷/精益/看板領域尤為突出。

　　Jeff Anderson給出了幾條具體條款以作參考：

這些是我剛完成的合同中所包括的條款。我們有幸曾經真正地與客戶一起完成過用戶故事，因而對其復雜度有所了解。具體數據并不重要，主要給你個概念。

• 周期，我們承諾故事的一個SLA匯報周期為20天，準確度為80%
• 產量，我們承諾每月完成7個用戶故事

為了實現這一點，我們假設待辦事項列表中的故事的平均復雜度與已經完成的故事相同。我們每周持續匯報進度，異常值將按照變更請求來處理。有些類型的問題，我們讓客戶來負責，那些被總共阻礙超過2天的故事也會當做變更請求來處理。

　　Hillel Glazer已經開始從一個不尋常的角度制定他的合同條款了：

總體來說，我所采取的重構合同的方法，是以我想要如何發揮客戶關系的心理圖作為起點的。接下來，我想到了客戶在付錢給我的時候的感覺。他們付我錢買了什么？更重要的是，為什么？還有，我值得嗎？我不希望覺得，他們付我錢是因為我的合同/協議規定如此。這使得我更關注價值。不僅僅局限于合同，而是我與他們的相互交流。

再來看看合同里的語言，我發現自己與律師們所用的委托書竟然驚人地（近乎不可思議地）一致。于是，我找了一份入手，搞出了一份“合同”書，約定了提供服務的報酬，“從何時到何時”，“基于客戶的需求”以及“對特定的任務和工作量附帶相應的期望產出”。（等等）

每一個特定的最終交付物都是獨立任務，而不只是簡單的文字定義。事實上，我所提供的服務就在協議當中，而任務和最終交付物都是提供那些服務的特有實例。

　　另一方面， Peter Stevens 認為，一份合同應該包括：

1. 項目以及公司間合作的目標
2. 項目組織架構概述
3. 主要人員
4. 付款和結算
5. 提前以及正常終止條款
6. 任何根據當地法律或者法定慣例所需的法律細節問題