← 返回 Linear 完全指南Linear 完全指南 · Lesson 2.3
Issue 解剖學
Issue 是 Linear 的最小工作單位。這一課不是只列欄位名稱，而是告訴你每個欄位怎麼寫，才會真的幫助執行。
一張好 issue 應該回答什麼？
- 這件事到底要做什麼？
- 為什麼要做？
- 誰負責？
- 什麼情況算完成？
- 它現在排在哪裡？
常見欄位
- Title
- Description
- Assignee
- Priority
- Labels
- Project / Cycle
- Estimate
- State
真正重點
- 不要只填欄位，要讓下一個接手的人看得懂
- 標題要具體
- 描述要有背景與完成標準
- 狀態要反映現況，不要亂掛
標題（Title）怎麼寫
壞標題通常像：改一下登入、修 bug、優化首頁。它們的共同問題是太模糊。
比較好的寫法是：修正登入頁在 Safari 無法送出表單、首頁 Hero 區塊改為新版價值主張文案。
好標題要讓人一眼看出對象、動作、範圍。
描述（Description）怎麼寫
至少要有三件事：
- 背景：為什麼有這張票
- 需求：具體要做什麼
- 驗收：完成後怎樣算 done
如果缺這些，issue 很容易只剩一句口號，最後靠口頭補資訊。
Assignee、Priority、Labels
- Assignee：這張票現在誰主責，不要同時掛很多人假裝大家都負責
- Priority：幫團隊排先後，不是表達情緒
- Labels：拿來分類，不要變成每個人自創關鍵字的地方
Issue 在 Project 底下，還是 Cycle 底下？
比較準確的說法是：Issue 是最小工作單位，它可以同時跟 Project 和 Cycle 發生關係。
- Project 回答的是：這張 issue 是在幫哪個較大的目標服務
- Cycle 回答的是：這張 issue 是不是這一輪要做
所以同一張 issue 很常同時有這兩個屬性。例如：
縮短註冊流程為 3 步 這張 issue，可能屬於 Onboarding 2026 Q2 這個 project，也同時被排進 Cycle 18
意思就是：
- 它屬於某個較大的專案目標
- 同時也被安排在某一輪執行節奏裡
所以不要把 project 跟 cycle 想成二選一。對一張 issue 來說，project 管的是目標歸屬，cycle 管的是執行時機。
那 Cycle 跟 Project 的關係是什麼？
Project 比較偏長一點，代表一段時間內要完成的目標；Cycle 比較短，代表這 1–2 週團隊打算完成哪一批工作。
它們不是上下層互相包含的單一關係，而是兩個不同維度：
- Project：管「為了什麼目標而做」
- Cycle：管「什麼時候做」
所以 Cycle 不會在某一個 Project 底下，Project 也不是 Cycle 的上層父節點。
比較貼近實際的理解是：
- 一個 Cycle 裡，可以同時有很多不同 Projects 的 issues
- 同一個 Project 的 issues，也可以分散在很多個 Cycles 裡慢慢完成
如果硬要形容它們的關係，比較像是多對多，但這個多對多不是 project 直接連 cycle，而是透過 issue 連起來。
所以很常見的情況是：
- 一個 project 底下有很多 issues
- 這些 issues 不會在同一輪全部做完，而是分散到好幾個 cycles
例如 Onboarding 2026 Q2 這個 project，底下可能有 20 張 issues：
- 其中 5 張排進
Cycle 18 - 再 6 張排進
Cycle 19 - 剩下的之後再安排
反過來看，Cycle 18 裡也可能同時包含：
Onboarding 2026 Q2 的幾張 issue註冊流程簡化 的幾張 issue- 甚至一些不屬於任何 project 的 maintenance / bug issue
所以你可以把它想成：
- Project 像一個較大的目標容器
- Cycle 像團隊在這一輪，從不同地方先挑出來要做的那批票
Project / Cycle / Estimate / Time Estimate / State
這幾個欄位分別回答不同問題：
- Project：它屬於哪個較大的目標
- Cycle：它是不是本輪打算做完的事
- Estimate：它大概多大顆
- Time Estimate：如果團隊有在管實際時間，這張票大概要花多久
- State：它現在進展到哪裡
不要拿單一欄位硬扛所有資訊。像是把 state 當優先序、把 label 當 project，最後都會很亂。
Time Estimate 什麼時候會填？
不是每個團隊都一定會填 time estimate。很多產品團隊只用 Estimate 來放 S / M / L 或 points，並不追求每張票的精準工時。
如果團隊真的需要看比較實際的時間預估，常見會在這幾個時候填：
- 進 backlog 後 refinement 階段：先有粗略時間感，方便判斷這張票是不是太大
- 接近 cycle planning 時：當票已經比較 ready，會更適合補一個較實際的時間估算
- 準備進 cycle 時：用來幫助判斷這輪容量吃不吃得下
比較常見的做法是：
- Estimate 仍然保留給相對大小（像是
S / M / L） - Time Estimate 才放比較像
4 小時、2 天 這種時間概念
一句話記：Estimate 比較像「多大顆」；Time Estimate 比較像「大概要多久」。不是所有團隊都需要兩個都用，但如果兩種資訊都想保留，分開會最清楚。
這一課的收尾
Issue 品質幾乎決定了 Linear 的體驗。工具本身不會自動讓團隊更清楚；是你們有沒有把 issue 寫成真正能執行、能交接、能追蹤的工作單位。