There are a few ways that we've seen customers handle dependencies, some of which are possible on a physical kanban board, others not. I've shown three of them being used in the attached screenshot.

First, teams group a feature and its associated subordinate items in swimlanes. In the screenshot, the green cards are features, the orange cards are stories. The feature can't move on to the next major step in the overall process until all of the stories have gotten to the done lane of the swimlane.

Second, I've tagged the feature and its stories with a common tag, feature_1, and then filtered the board to make those items pop out from the rest. The main reason for using this approach in conjunction with the swimlane approach would be if dependent items weren't always in the same swimlane. For example, most of the work for a feature was in one development team's swimlane but some related infrastructure deliverables were in the systems engineering team's swimlane.

Third, I've activated the external ID feature for the board. You can see I marked the feature as 1 and the sub-items as 1-1, 1-2, 1-3, etc. We've mainly seen this used where the number is actually a reference to another system, like a requirements management system, defect tracking tool, etc. In that case, the card header can includde a link back to that system. But this feature can also be used without that linkage to create a visible connection between items without filtering.

And, not in the screenshot, if the dependent items need to span boards, you can link a card to its related item(s) using their permalinks and hyperlinks in the description field.

We're in the process of piloting some features that will make this cross-board linkage much more seamless to help very large organizations handle portfolio management. But the approaches outlined above work quite well, especially if/since the time any given set of related items is on the board should be relatively short.

I hope that helps

Kind regards

Jon