本文由 AI 分析生成
Summary
GitLab Marketing team’s guidelines for using milestones and iterations, distinguishing the two concepts: milestones for larger time-bound releases and epics planning, iterations for 2-week agile sprints. Includes naming conventions, level hierarchy, and known limitations of each.
GitLab 的兩種時間追蹤概念：Milestone（較大範圍的發布計劃）和 Iteration（2 週敏捷衝刺），本文說明兩者的適用場景、命名規範和已知限制。
Key Points
- Milestones track multiple related issues over a variable time period; support burndown charts and grouped views
- Iterations are fixed 2-week sprints (Mon–Sun); named
Mktg: YYYY-MM-DD(end date) - Both milestones and iterations can exist at project and group levels; define at lowest required level
- Milestone naming convention: prefix with 2-letter team abbreviation (
rm_,sm_) to enable filtering - Key milestone limitations: cannot filter milestone lists, no label support on milestones, no change history
- Backlog milestone: use for unscheduled/unready issues; no start/due dates set; named
Backlog - Milestone duration varies by team — shorter is generally better; some teams use weekly, some quarterly
Insights
- The “milestones cannot be filtered and have no labels” limitation is significant for large organizations — it explains why the naming convention (prefix abbreviation) carries so much weight as a workaround.
- The distinction between milestones (variable duration, release-oriented) and iterations (fixed 2-week, sprint-oriented) maps to the epic/story hierarchy in traditional agile: milestones serve epics, iterations serve user stories.
Connections
- Issue and Kanban boards project management guidelines — iteration boards are one of the two required boards per team
- Milestones — concrete implementation of milestones for Customer Support Operations
- Milestone Planning — AppSec team’s milestone-based planning process
Raw Excerpt
“Milestones are very useful when tracking the progress of multiple issues and when planning and managing epics.”