Milestones or Iterations

How to Use GitLab
1

I am new to GitLab and I am evaluating it for use as an Agile Planning tool. I am an experienced Agile Coach and I am starting my learning with Scrum.

Something that threw me from the start is the difference between Milestones and Iterations. It seems like Milestones have been around for a while and Iterations is a new feature in the product. To spread up my learning cand you please advise the best approach for Scrum. Milestones or Iterations.

2 Likes
2

I’m on a content team that loosely follows Scrum and uses Gitlab for project management. Iterations are equivalent to sprints. You date-range them, and they’ll display a burndown chart for all the issues you assigned to it.

Milestones can also be date-ranged and show a burndown, but they’re better used as landmarks for a given product-- i.e., Prototype Completed, Production Completed; 50 Hours of Content Uploaded.

We started off using milestones for our sprints, but because an issue can only have 1 milestone at a time, we’re having trouble getting big-picture views on our production, esp knowing when we’ve achieved some big steps. We’re finding that iterations better suit our process.

3 Likes
3

I am finding the distinction between Milestones and Iterations in GitLab extremely awkward.

In theory, it makes sense to use Iterations for sprint planning. They show burndown/burnup charts. They nicely allow you to organise issues based on when you think they will be completed.

However, there are a few problems with Iterations that makes it hard to use as a project planning tool:

  • The Iteration screen doesn’t show the project an issue belongs to
  • The Iteration screen doesn’t show issue labels
  • The iteration screen doesn’t allow you to sort/group/filter by state or assigned user
  • This iteration screen doesn’t sort/group/filter by project, epic, or milestone
  • You can’t assign an issue to an interaction until after it has been created

Some of these problems could possibly be remedied by using a board with each list assigned to a different iteration, however, each board list is quite narrow so the info can feel quite compact and you can only see a few issues in the list at a time before needing to scroll.

The second problem is that the start and end date of Epics are not adjusted based on the iterations an issue is part of. This is an awesome feature that only belongs to Milestones.

So why don’t we just use Milestones for sprints? Because milestones are meant to be just that, milestones. A sprint isn’t a milestone, a sprint is a block of time. A milestone is a larger scope of work to be completed to reach some goal (aka milestone) that may or may not have a deadline. Because a ticket can only belong to one milestone, it means I would need to choose to use Milestones as sprint iterations or as goal milestones. I can’t choose both, because a ticket can only be assigned to one milestone. I cant have an issue assigned to the week 7 interation milestone, and the stage 3 goal milestone.

Ultimately, I just wish GitLab would embue Iterations with the same power that Milestones currently have, change Milestones so they exist within the context of a single epic, and allow an issue to belong to multiple milestones from different epics.

1 Like
4

Thanks for the feedback. I’m the GitLab PM responsible for Iterations and Milestones, so hopefully, my reply will provide a bit of additional context.

Why Iterations? They are indeed intended to be used as a shorter timebox for planning. We thought through solving this use case with Milestones, but the problem with Milestones is that you can have many Milestones with overlapping dates, there is no inferred relationship between Milestones, and trying to solve that problem proved to be an undesirable user experience. We need distinct relationships between timeboxes with like-sized durations so we can programmatically calculate velocity.

At the same time, many organizations have multi-layered planning horizons, such as quarterly release planning, and bi-weekly iteration planning. This is where using Milestone for the longer time horizon and Iterations for the shorter time horizon can be useful.

I completely agree that we have a lot of work to make Iterations and Milestones work together more effectively with each other and with other features like inherited dates on Epics. It isn’t going to happen overnight as there are some larger changes in the works, but here is the TL;DR on what to expect in the future:

  • Iteration Cadences are just about to be generally available. They allow multiple teams that are working out of a group to each have their own set of iterations. Cadences also bring some efficiency gains as you can enable automated scheduling and rollover of issues.
  • Adding parenting to issues, issue types, creating a new issue detail view, and improving how attributes roll-up and cascade between parent and children issues. (this is where we are going to fix some of the differences between Milestone and Iteration inheritance)
  • Making issues natively available with a Group
  • Migrating Epics to Issues so there is a unified “work item” with parenting, dependency management, and so on. (this will more or less enable the equivalent of Milestones being assigned directly to an epic)
  • Saved views (this will address most of the feedback on the gaps in the current Iteration report view)

I’m excited about where we are headed and I’m thankful to folks like yourself that take the time to provide such great, candid feedback. Feel free to jump into any of the linked issues/epics and collaborate with us!

5 Likes
5

Thank you the update it is muchly appreciated!!! Those new features do sound awesome and will go a long way to improving the sprint planning process :slight_smile:

6

Thanks a lot for this write-up.

Knowing intentions help a lot in understanding the purpose and intended difference of Milestone and Iterations.