Sprint 需要 Timebox嗎？（Is Timeboxing a Sprint necessary?）

共同作者：Shalom Chin 與 KK；譯者：KK

從 Scrum 的五個 Event 中，Scrum 實踐者會花最少的時間詳細說明 Sprint。它通常被寫成一個有 Timebox 的 Event，它可以是一到四週的時長。它扮演著其他四個 Event 的容器。Timebox 的優點值得一提，因為 Timebox 是 Scrum 和 Event 的基礎。

《Hooked》的作者 Nir ​​Eyal 在他的網站上提到，Timebox 是「你大概不會用的最強大的時間管理技術」。番茄工作法也跟 Timebox 有關，因此人們能有效管理他們的時間，不會分心的完成任務。

除了專注以外，我們希望能管理交付未讓客戶滿意的產品的風險。透過瀑布式專案管理，產品交付給客戶的時間，會發生在專案生命週期結束時。當我們延遲讓產品進行測試的時間越長，這種風險就會大幅增加。關鍵在於研究客戶如何與產品互動，以便讓我們每一次發佈產品時都能取得回饋。這同時也降低了不同元件整合的失敗風險。

透過試著使我們的工作在一個 Sprint 內完成，我們必須拆解工作，把它變成一小批、一小批。透過這種方式，人們能更快地開始和完成工作，從而減少每項工作的交付時間。這能更快發佈小塊交付的價值。產品發佈的頻率越高，我們就能越快檢測到產品問題。雖然我們希望在發佈前盡可能減少重工，但當我們觀察客戶正在使用的產品時，有時能更好地檢查到問題。即使產品可能不完整、缺少客戶要的每個功能，但頻繁地逐一交付到使用者手中，能贏得客戶和利害關係人的信任。

Timebox 還能讓 Scrum 團隊有一個斷點，以便停止並思考對於持續改進，他們所要做的調整。 Sprint 末端有一個能檢視工作、客戶價值、團隊幸福程度和內部流程的機會。這讓團隊思考一個計劃，以用來面對團隊中和產品上的挑戰。做產品和團隊流程的實驗，能為即將到來的 Sprint 測試假設。不只如此，Timebox 限制了可能被花在實驗並得出結論的成本和時間。

最後，Timebox 作為一種自我約束，透過優先考量客戶最重要的事情，以便聰明的選擇你的戰場。由於有限的時間、資源和成員可用性被含納在一個 Timebox 中，所以 Product Owner 必須選擇做最重要的事情。一旦團隊將這些 Backlog Item 拉入 Sprint Backlog 中，在 Sprint 中就不能做任何變更，除非出現有新資訊出現並提到目標已不再能替客戶帶來價值。

結論是，Sprint 有許多優點，並能在產品開發的脈絡中很好地運作。 Sprint 長度的調整，取決於產品的特性。

補充摘錄：

Timebox 是 Scrum 和 Sprint 的基本部分，但為什麼它這麽重要？除了管理風險和改善品質外，我們覺得藉由這篇短文來解釋 Timebox 的用處會蠻好的。

對有 Timebox 的 Sprint ，你有什麼經驗呢？

Co-written by Shalom Chin and Kaitlyn Peng

Out of the five Events in Scrum, Scrum practitioners would spend the least time elaborating much about the Sprint. It is usually written off as a timeboxed Event which can last from one to four weeks. It acts as a container for the other four Events. The merits of timeboxing are worth some mention since timeboxing is fundamental to Scrum and its Events.

Nir Eyal, the author of “Hooked”, writes on his website, that timeboxing is “the most powerful time management technique you’re probably not using”. The Pomodoro Technique is all about timeboxing so people are able to effectively manage their time to work on tasks without distractions.

In the context of Scrum, timeboxing is also about focusing our efforts but the focus is to achieve the Sprint Goal. When timeboxing is too long, there is a tendency to forget about the purpose or why we are doing all the work. Having shorter time frames for a timebox helps to keep the goal in our short-term memories at the top of our minds.

Besides focus, we want to be able to manage the risks of delivering a product that does not satisfy the customer. With waterfall project management, delivery of the product to the customer happens at the end of the project lifecycle. This risk substantially increases the longer we delay putting the product in the field for testing. The key is to study how our customers interact with the product so that we can get feedback each time the product has been deployed. This also reduces the risks of failure in any integration among different components.

By trying to fit our work in a Sprint, we have to break the work down into small batches. With small batches of work, people can start work and finish it quicker, so that the lead time of each work can be reduced. This enables faster deployment of small chunks of value. The more frequently the product is launched, the faster we can detect quality issues. Although rework is something we wish to minimize before launch, there are times in which defects can be better detected when we can observe the product being used by our customers live in action. Although the product may be incomplete and lack every feature desired by the customer, the frequent piecemeal delivery to the hands of the users earns the trust of both our customers and stakeholders.

Timeboxes also allow Scrum Teams to have a breakpoint to stop and reflect on the changes they need to make towards continuously improving. The end of the Sprint is an opportunity to review the work, the customer value, the happiness of the team, and the internal processes. This allows the team to think of a plan to address the challenges within the team and with the Product. Experiments for the product and the team’s processes can be developed for the upcoming Sprint to test assumptions. Moreover, timeboxing limits the cost and time that can be spent on the experiment to derive a conclusion.

Finally, timeboxing acts as a self-constraint to choose your battles wisely by prioritizing what matters first to the customer because it is ex. With limited time, resources, and people availability encapsulated within a timebox, the Product Owner will have to choose the most important items to work on. Once those backlog items have been pulled by the team into the Sprint Backlog, there can be no changes during the Sprint unless new information comes up to show that the goal is no longer relevant in bringing customer value.

In conclusion, the Sprint comes with many benefits and can work well in the context of developing products. Adjusting the length of the Sprint would depend on the nature of the product.

Extract: Timeboxing is a fundamental part of Scrum and and the Sprint but why is it so important? Besides managing risk and improving quality, Kaitlyn Peng and I felt that it would be good to explain the usefulness of timeboxing through this short article.

What are your experiences with a timeboxed Sprint?