GitLab Issue Dependencies
When I first had the idea for this post, this feature was part of the Bronze plan. Now the pricing structure has changed, it is part of the "Premium" plan, formerly "Silver". As such, it costs $19/user/month to access this feature. This feature was the very specific feature of why I had my company upgrade from the free tier. At the time $4/user/month was absolutely paid for by time saved by this feature.
Issue dependencies are additional features which form part the related issues feature in GitLab. Where related issues allow you to link similar issues, the dependencies part allows you to define which issues block, or are blocked by another issue.
Why would you block issues?
The simple answer is to stop people working on the issue. In an ideal world, anyone would be able to pick an issue out of the appropriate lane in the backlog and work on it. Problems creep in when something needs to exist before something else can call it. This could be as simple as a UI change needing to wait for an API update, or something more complicated which needs a database change, requiring a Database Administrator (DBA) to approve a change.
By blocking an issue, you can prevent someone picking up work which isn't ready to be implemented. This can then prevent them from doing more work than is in scope for the issue, or wasting time trying to figure out why things aren't working as specified. Overall, they can be working on issues which provide immediate value.
How does it work?
Once an issue has been created, the view screen for the issue shows a "Linked Issues". This lets you specify the relationship to another issue (on the Premium tier or higher (or open source projects)). It can be simply related, or it can block or be blocked by another issue.
If a relationship is set to cause a blockage, the blocked issue will be indicated as such on issues boards
When the blocking issue is closed, the blocked issue will automatically update to remove the blocking symbol. This acts as a visual cue to let people know the issue can proceed.
Problems with this method
For anyone using the Gitflow method of development, these blocked issues add manual overheads to the process. Because issues are not automatically closed in GitLab until they are merged into the default branch, and the Merge Request (MR) contains
Closes #id, then knowing when an issue has been complete and merged into the feature branch requires either the issue to be closed manually, or for someone to manually change the related issue from being blocked to just related. What is more likely to happen is they remove the link, but don't replace the blocker with a regular relationship. This removal increases the difficulty of knowing what is actually related, and where important information about an issue may exist.
The simple way around this is to try using GitLab Flow. With this method, branches are created off the main branch, which acts as the traditional
develop branch. When MRs are complete, issues are closed. This retains the issue relationships, and removes the blocking visual cue when issues are closed.
I work as part of a small team, so my company's monthly overheads on GitLab are fairly small. We have a modest backlog at the moment, some of which are blocked by other issues. The monthly cost of being able to use issue dependencies is far lower than the cost to the business of having one of the team work through every issue, and update the description to let others know which issues are blocked by which others. That's just for the current backlog. Some items are added to the backlog where several subsequent issues need to be blocked by one or more of the issues created before it. It's easy to miss something when creating the description, so the blockers could be easily overlooked.
If you have a process or work stream where some issues block others, can you really afford to not spend $19/user/month to have that feature?
For further perspective, the average Software Developer salary in the UK is £31,056($42,820). The cost of the Premium tier of GitLab is $19(£13.68)/user/month. If being able to use blockers saves each developer 1 hour of time looking through issues to see what they can work on, then the feature has paid for itself. To further put it in perspective, it only needs to save a developer 3 minutes per working day to make a saving (based on 20 working days per month).
Personally, without this feature I would spend hours per week trying to work out what is ready for other members of the team to work on. They would equally spend as much time trying to find things to work on, resulting in lost development time. Either that, or we would have far fewer work items, but they would all be massive. They would have to cover everything from start to finish on a feature in one task. Doing so could result in other issues being blocked for longer whilst a feature waits to be completed. Large pieces of work blocking other developers will result in developers sitting round doing nothing while they wait. That's far more expensive than paying to quickly add a visual identifier for blocked issues.
 Based on 40 hour working week and an hourly rate of £13.68, which is £28,454.40 per year; below the average Software Developer salary.