Ready to go.
準備好出發。

…you have a Product Backlog that is a Refined Product Backlog, or nearly so, and you are beginning to plan a Sprint. Out of necessity, some items on the Product Backlog are still too nebulous for the Development Team to be able to implement then. Yet the Sprint Backlog embodies the work necessary to achieve the Sprint Goal, as well as guides development. Therefore, the items on the Sprint Backlog must be concrete; they cannot be nebulous. But how much “concreteness” does the Development Team need to do its job?

…您擁有⼀個已經梳理過的產品待辦事項清單，或者接近細化的狀態，並且您正準備規劃⼀個Sprint。 由於某些原因，產品待辦事項清單ㄒ上的某些條⽬對於開發團隊來說仍然過於模糊，無法⽴即實施。然⽽，Sprint待辦事項清單既包含實現Sprint⽬標所需的⼯作，也指導著開發過程。 因此，Sprint待辦事項清單 上的條⽬必須具體，不能模糊不清。 但對於完成⼯作，開發團隊到底需要多具體的條⽬呢？

✥ ✥ ✥

If the Development Team does not precisely understand Product Backlog Items (PBI), development effort (and time) tend to balloon, which in turn cause the Sprint to miss the Sprint Goal or to not deliver what stakeholders expect.

如果開發團隊對產品待辦事項 (*PBI*)理解不充分，那麼開發⼯作量（和時間）往往會膨脹，進⽽導致 Sprint無法實現Sprint⽬標或交付利益相關者期望的成果。

The challenge of development is taking new ideas and making them real—actually developing them. This is a fundamental change in thinking: the idea starts out quite abstract, but development demands that the idea become concrete in every particular. This change in thinking ultimately happens fully only in the moments of development. However, if you expect to do any detailed planning at all (and you need detailed short-term planning to inject some sanity into your process), the development ideas need to be concrete enough to make it possible to answer design questions. How concrete? Enough to enable detailed planning in which the team can have confidence.

開發的挑戰在於將新想法變成現實——真正地實現它們。 這是⼀種根本性的思維轉變：想法最初是抽象的，但開發要求想法在每⼀個細節上都變得具體。 這種思維轉變最終只會在開發過程中完全發⽣。 然⽽，如果您期望進⾏任何詳細的規劃（您需要詳細的短期規劃來為您的流程注⼊⼀些合理性），那麼開發想法就需要⾜夠具體，以便回答設計問題。 具體到什麼程度？ ⾜以進⾏詳細的規劃，讓團隊充滿信⼼。

I once did some mercenary programming for a small company. At one point, the CEO asked me to write some software, and proposed a fixed price. “Are we agreed?” he asked. “No,” I said. “The software is not defined precisely enough for me to know how long it will take.”

我曾經為⼀家⼩公司做過⼀些臨時程式開發⼯作。 有次，⾸席執⾏官 (CEO) 要求我編寫⼀些軟體，並給出了⼀個固定價格。“我們達成協議了嗎？”他問道。“沒有，” 我說，“軟體定義得不夠精確，我無法確定完成它需要多長時間。”

Said another way: there is a shearing layer between the market world and the design world. The realizations they produce evolve at different scales: market understanding comes slowly, while design usually converges quickly (under Enabling Specifications). You need an organizational boundary between them; otherwise you dilute the focus both of the market effort and of the engineering effort. In theory you could achieve this separation with a process boundary. But people membership cuts across process, thus you are still faced with the problem that individuals may be torn between focusing on the business and value landscape and the product and technology landscape. You in turn could solve that problem by time-slicing individuals’ focus between these two domains, but that leads to context switching, which is known to decrease efficiency. Scrum separates these concerns into the organizational realms of the Product Owner and Development Team, respectively. It is crucial for success that there be a touchpoint where these two realms meet.

換句話說：市場和設計之間存在著⼀個緩衝層。它們產⽣的結果以不同的尺度演進：市場理解來得緩慢，⽽設計通常會在合適的實現規範下快速收斂。在兩者之間，你需要⼀個組織層⾯的分界線，否則市場導向和⼯程導向的焦點都會被削弱。理論上，你可以通過流程上的劃分來實現這種分離。但是，由於⼈員會同時參與多個流程，因此個體仍然可能在關注業務和價值層⾯以及產品和技術層⾯之間搖擺不定。解決這個問題的⼀種⽅法是，讓個體在關注這兩個領域的焦點之間進⾏時間劃分，但這會導致上下⽂切換，從⽽降低效率。Scrum通過將這些關注點分別劃分到產品負責⼈和開發團隊的組織領域來解決這個問題。這兩個領域必須存在⼀個接觸點是獲得成功的關鍵。

When you are in the throes of planning, there is a strong temptation to make quick assumptions and defer hard questions (such as detailed estimation) until later. When a group does planning together there is often implicit peer pressure to defer hard questions so that the planning process can proceed. To combat this, the team needs to agree to face the most difficult issues first. To avoid starting work on shaky footing, the team needs to adhere to an objective standard of shared clarity about the end point.

在規劃過程中，⼈們很容易做出快速假設，並將棘⼿的問題推遲（例如詳細估算）到以後再去處理。當團隊⼀起進⾏規劃時，往往會存在⼀種隱性的同儕壓⼒，要求推遲棘⼿的問題以使規劃順利進⾏。為了對抗這種壓⼒，團隊需要同意優先⾯對最棘⼿的問題。為了避免在搖搖欲墜的基礎上開始⼯作，團隊需要對最終⽬標清晰度的客觀標準達成共識。

Variability is one source of waste in lean thinking. If the Development Team insufficiently understands what some Product Backlog Item really means, or how to develop it or estimate it, there is increased variation in possible Sprint outcomes and the effort is likely to incur increased cost, risk, and uncertainty.

可變性是精實思想中浪費的⼀個來源。如果開發團隊對產品待辦事項的真正含義、如何開發它們或如何進⾏估算理解不⾜，那麼Sprint的潛在成果就會出現更⼤程度的差異，並且這項⼯作可能會導致成本、⻛險和不確定性增加。

Therefore:

因此：

Each Product Backlog Item must meet at least the following criteria before the Development Team can take it as a candidate for the work on the Sprint Backlog during Sprint Planning:

在Sprint規劃期間，開發團隊將產品待辦事項納⼊Sprint待辦事項列表之前，每個條⽬⾄少必須滿⾜以下標準：

1. The work is immediately actionable by the team.
2. The planned deliverable has value.
3. The Product Owner and the Development Team have discussed it.
4. The Development Team has estimated it.
5. It is testable, and the Product Owner has specified tests for it.
6. The Scrum Team has sized the pieces appropriately (see Small Items).

1. 團隊可以⽴即著⼿開展這項⼯作。
2. 計劃交付的成果具有價值。
3.  產品負責⼈和開發團隊已經討論過該條⽬。
4.  開發團隊已經對該條⽬進⾏了估算。
5.  該條⽬可測試，並且產品負責⼈已經明確了測試內容。
6.  Scrum 團隊已經對條⽬進⾏了適當的拆分。（請參閱 ⼩型事項）。

A Product Backlog is “Ready” if it has enough Product Backlog Items at its top, meeting these criteria, to fill a Sprint.

產品待辦事項清單被認為是 “就緒”狀態的前提是，清單頂端擁有⾜夠多的產品待辦事項滿⾜上述標準，能夠填滿⼀個Sprint週期所需的容量。

A good Definition of Ready can help guide the team to handle external dependencies. If an item depends on something outside the team’s control, putting it on the Sprint Backlog can greatly increase the risk of not having a potentially releasable Product Increment at the end of the Sprint, and you can’t do anything about it! Take dependency analysis all the way down to the level of Product Backlog Items instead of just managing gross dependencies at the level of Regular Product Increments; the team will ultimately need to understand dependencies at that level to order work during the Production Episode. Consider including criteria concerning external dependencies as part of the Definition of Ready.

就緒的定義可以幫助團隊處理外部依賴問題。如果⼀個條⽬依賴於團隊控制範圍之外的因素，將其放⼊Sprint待辦事項清單會⼤⼤增加Sprint結束後無法交付可發佈的產品增量的風險，⽽這又是你們無法控制的！依賴分析應該⼀直細化到產品待辦事項的層⾯，⽽不是僅僅在定期產品增量層⾯進⾏粗略的依賴管理；團隊最終需要理解這個級別的依賴關係，以便在⽣產週期內排序⼯作。可以考慮將有關外部依賴的標準納⼊就緒的定義的⼀部分。

There is important interplay between this pattern and Enabling Specifications. The candidate Product Backlog Items for the upcoming Sprint must become Ready during Sprint Planning at the latest. Coming out of Sprint Planning, Product Backlog Items—together with the Product Owner’s explanation and clarification—must Enable the team to start implementation undaunted.

這個模式與實現規範之間存在著重要的相互作⽤。即將到來的Sprint的候選產品待辦事項最遲必須在Sprint規劃環節達到 “就緒” 狀態。在Sprint規劃結束後，產品負責⼈需要對產品待辦事項進⾏解釋和澄清，從⽽能夠讓團隊毫⽆畏懼地開始實施⼯作。

✥ ✥ ✥

The goal is for the Scrum Team to meet all the Ready criteria as it works towards a Refined Product Backlog and strives to develop Enabling Specifications before Sprint Planning. The goal is that PBIs pass through the “Ready gate” without pause or delay, subject only to adherence to a short checklist. While the list is important for undeveloped teams to be able to “stop the line,” the greater good comes from anticipating the stipulations and arranging ahead of time for the PBIs to be fully Ready by the time the Sprint starts, so that flow is unimpeded.

Scrum團隊的⽬標是在梳理產品待辦清單的過程中滿⾜所有 “就緒”標準，並努⼒在Sprint規劃之前制定實現規範。理想情況下，產品待辦事項能順利通過 “就緒的關卡” ，無需停頓或延遲，只需要遵循⼀份簡短的檢查清單即可。儘管這份清單對於尚未成熟的團隊來說很重要，能夠及時叫停不符合標準的條⽬，但更重要的做法是提前預見到這些標準並提前安排，確保產品待辦事項在Sprint 開始之前完全符合 “就緒” 的狀態，從⽽保障⼯作的順暢。

Note that all PBI in the Product Backlog do not have to be Ready, though as they move up the Product Backlog, they should progress toward becoming Ready.

注意，產品待辦事項清單中並⾮所有產品待辦事項都需要處於 “就緒” 狀態。不過，隨著條⽬在產品待辦事項清單中的排序不斷提升，它們也應該逐步接近 “就緒” 狀態。

Contrast the Definition of Ready, which applies to PBIs going into a Sprint, with the Definition of Done, which is a criterion applied to a PBI for delivery during or at the end of a Sprint.

相對於 “完成的定義” (Definition of Done)。“ “就緒的定義” 適⽤於即將進⼊Sprint 的產品待辦事項，⽽ “完成的定義” 則是Sprint 期間或結束後⽤於產品待辦事項是否交付的標準。

What happens if a PBI is not Ready? Though the entire team works on PBIs, the Product Owner is responsible to come to Sprint Planning fully prepared to enable the team to proceed unimpeded to develop the candidate PBIs for the current Sprint. Most of the time, being not Ready is a sign that the Product Owner has to go back and do more analysis and bring the PBI to the team again at a later date. The Scrum tradition is that if the Product Backlog is not Ready at Sprint Planning, the Development Team has the right to “go to the beach,” as Jeff Sutherland describes in [1] (“Be Ready to be Done,” p. 137). This makes it visible that the Product Owners have not done their job to make the backlog Ready. If you end up at the beach a lot you are probably in the wrong line of work. What is your contribution to the backlog not being Ready? How can the team help the Product Owner?

如果產品待辦事項未達到 “就緒” 狀態會怎樣？雖然整個團隊都基於產品待辦事項開展⼯作，但產品負責⼈有責任在Sprint規劃環節做好充分準備，使團隊能夠順利開展⼯作，不受阻礙地開發當前Sprint 的候選產品待辦事項。

⼤多數情況下，產品待辦事項未達到 “就緒” 狀態意味著產品負責⼈需要回去進⾏更多分析，然後在稍晚⼀些時候將該條⽬再次提交給團隊。Scrum 的傳統，如果產品待辦事項列表在Sprint規劃時未達到 “就緒” 狀態，那麼根據 傑夫·薩瑟蘭(Jeff Sutherland)在 [1] (“Be Ready to be Done,” 第 137 ⻚) 的描述，開發團隊則有權 “去海灘度假”。

這能讓⼤家清楚地看到產品負責⼈沒有完成讓產品待辦事項列表達到 “就緒” 狀態的職責。如果團隊經常 “去海灘度假”，這可能意味著你們從事了錯誤的⼯作。那麼，是什麼原因導致產品待辦事項未達到 “就緒” 狀態？團隊可以如何幫助產品負責⼈呢？

To differentiate the Scrum notion of Ready as a term of the trade distinct from the vernacular sense of “ready,” Scrum folk will sometimes use the phrase “Ready-Ready” instead of the single word “Ready.” Richard Kronfält apparently published the first formal description of Definition of Ready in 2008. [2]

為了將 Scrum 語境下的 “Ready” (就緒) 與⽇常⽤語中的 “ready” (準備) 區分開來，Scrum ⼯作者有時會使⽤”Ready-Ready” (真正準備就緒) 這個短語來代替 “Ready”。據記載，Richard Kronfält 在 2008 年發佈了 “就緒的定義” 的第⼀個正式描述。 [2]

Thanks much to Peter Gfader for comments!

⾮常感謝Peter Gfader的評論！

[1] Jeff Sutherland and J. J. Sutherland. “Be Ready to be Done.” In Scrum: The Art of Doing Twice the Work in Half the Time. New York: Crown Business, September 30, 2014, p. 137.

[2] Richard Kronfält. “Ready-ready: the Definition of Ready for User Stories going into Sprint Planning.” Blogspot.dk, Oct. 2008, http://scrumftw.blogspot.nl/2008/10/ready-ready-definition-of-ready-for.html (accessed 1 November 2017).

Picture credits: https://www.rawpixel.com/image/8657/hands-holding-bangkok-thailand-travel-guide-book-map-floor (under CC0 license).