什麼是衝刺目標？
衝刺目標描述當前衝刺的商業目的和價值。比如
支持報告生成
加載地圖數據
收集硬件信息
共同承諾
衝刺目標是團隊和產品負責人作出共同承諾的基礎。團隊承諾在當前衝刺結束之前完成目標，產品負責人承諾在衝刺執行過程中不變更目標 。
是變更，還是澄清？
什麼情況算變更？變更是工作或資源的變動，在經濟上會造成潛在的嚴重浪費，中斷工作流或在一個衝刺內大量增加工作範圍。比如：產品負責人：“哦，我所說的是要能夠在警察數據庫中搜索少年犯，並不只是按姓名搜索，還有能夠按照嫌犯的汶上照片來搜索數據庫！”（增加圖片搜索可能意味着開發量大增，屬變更）
什麼情況是澄清呢？
澄清是在衝刺執行期間提供更多的細節來幫助團隊實現衝刺目標。比如：
開發團隊：“你說搜索出來的少年犯應該顯示在列表中，你對列表排序方式有什麼偏好嗎？”
產品負責人：“有，按照姓的字的字幕順序排序”
開發團隊：“沒問題，可以這樣做”
變更引起的後果
鎖定目標後若在衝刺中進行變更，除了浪費這樣的直接經濟後果，還可能損害團隊的士氣和信任關係。
注重實效
理想很豐滿，現實很骨感。在某些特殊情況下，Scrum團隊除了鎖定目標，還需要注重實效。比如
假設競爭對手在我們執行衝刺的過程中推出了一個新產品。在考察這個新產品後，我們得出結論，考慮到競爭對手所完成的產品，我們現在做的事情沒有什麼價值，需要改變當前衝刺設定的目標。這種情況下，我們應該盲目的遵循“鎖定目標”這個規則嗎？也許不必盲從。
假如一個重要的生產系統發生故障，而且只有我們團隊裏部分或所有人才能修復這個故障，此時應該怎麼辦？我們能跟業務部門說，我們將在下一個衝刺中優先考慮修復故障嗎？也許不能。
歸根結底，我們必須用經濟合理的方式採取行動。Scrum團隊的每個人都會理解。如果我們改變當前衝刺，就會出現前面談到的負面經濟後果。但是，如果變更造成的經濟後果遠遠小於推遲變更所造成的經濟後果，那麼適時變更就是一個明智的決策。如果產品負責人與團隊能夠針對變更的必要性進行一次坦誠的、關注經濟效果的討論，大多數團隊都應該能理解並領會這種必要性，這樣一來，就能保全士氣和信任。
異常中止
假如衝刺的目標變得完全無效，Scrum團隊可能會認爲繼續當前的衝刺沒有任何意義並建議產品負責人異常中止當前衝刺。一個衝刺異常終止時，Scrum團隊需要聚在一起執行一次衝刺回顧。然後，團隊和產品負責人在一起計劃下一個衝刺，設置不同的目標並開發一組不同的PBI（Production Backlog Item）
雖然產品負責人有權取消任意一個衝刺，但從過往經驗上看，產品負責人很少動用這個權權力。Scrum團隊常常可以採取一些更溫和的手段來處理目前的形式，因爲衝刺很短，且突發狀況多發生在衝刺中途，所以終止衝刺所產生的經濟後果可能還不如走下去更有利。要有這樣的意識，中止衝刺應該是不得已而爲之的最後手段。
完成的定義
從概念上說，完成的定義是，在宣佈工作潛在可發佈之前，要求團隊成功完成的各項工作檢查。（如下表）
設計評審完成
代碼完成
代碼重構完成
代碼是標準格式
代碼已加註釋
代碼已提交
代碼已檢查
最終用戶文檔已更新
完成測試
完成單元測試
完成集成測試
完成迴歸測試
完成平臺測試
完成語言測試
零已知缺陷
完成接收測試
已在生產服務器上線
顯然，檢查列表上的具體項目依賴很多變量。
正在構建的產品的性質
構建所採用的技術
構建產品的組織
當前阻礙可能完成的事情的因素
在多數情況下，完成的定義至少要產生一個產品功能的完整切片，即經過設計、構建、集成、測試並編寫了文檔，能夠交付已驗證的客戶價值。
完成的定義可以隨時間演變
可以將完成的定義看作是對衝刺結束時工作狀態的定義。對於很多高效率團隊來說，工作的目標結束狀態是產品潛在可發佈-並且這種結束狀態在整個開發週期中保持相對恆定。有些情況下，團隊知道他們的障礙無法立即移除。因此知道在產品開發的過程中完成的定義必須演變。一個常見的例子是一個產品同時包含硬件和軟件，有時硬件要滯後很久才能提供，所以只能先在仿真機上做測試，後期，有了實際的硬件之後，完成的定義就會演變成潛在可發佈或者至少接近於這個標準。
結語
本文強調了Scrum框架中衝刺的重要作用。衝刺提供基本的Scrum股價，大多數其他的活動和工件都以它爲基礎。下一集，我們關注衝刺的輸入：用戶故事。