orders in Kanban board

Question

There are 3 issues in Kanban.

As per the screenshot, my team should finish issues in the order 1-3-2, right? 1st issue should be delivered before starting 2nd issue, right?

Answer 1

As per the screenshot, my team should finish issues in the order 1-3-2, right? 1st issue should be delivered before starting 2nd issue, right?

No. The backlog in a Kanban board is ordered in order of importance, so the most important stuff to work on next should be at the top. This mostly tells you something about the order in which tasks are started, but it does not necessarily say anything about the order in which they are completed.

If you have multiple people on your team, it will be rare that you only have a single ticket that is being worked on, unless your tickets cover a huge amount of work that can easily be shared out among the team members. It is also a given that not all tickets on your backlog will be exactly the same size, even if you try to break them down until they are all of comparable size. This means that a smaller ticket that is picked up later can be completed before a larger ticket that was started first.

It can be that you have dependencies between tickets, for example that ticket 2 needs the results from ticket 1 before meaningful work can be done on it. Such relations are sometimes unavoidable, but the more you hve them, the harder it becomes to do project planning in a meaningful way, because a delay in one task can cause a huge ripple effect in the timeline of the whole project.

Answer 2

The order is not specified. All that Kanban states is

It visualizes the work of the development team (the features and user stories)

The way the backlog appears in the Kanban is merely a way to visualize its contents.

Now typically in agile, teams are self-organizing, meaning they choose their own work. The ordering in the backlog, if any, is just a suggestion. However, it has been found valuable to be able to order them by "importance," that being a very fuzzy term by design. The order conveys some concept of importance in a visual way.

In most agile efforts, one of the aspects of self-organizing is that the team is accountable. If the team fails to complete a critical task because you chose to start a lower-importance task, they may want you to explain why you made that choice during the retrospective (example rationale: it was near the end of the day, and I knew I could bang that task out before I left). If some team members find they are constantly being stuck solving difficult high-importance tasks, they may want to know why you aren't helping with those, and cherry picking easy low-importance tasks.

Or you could be in an environment where there are critical chain issues and the issue at the top of the board happens to always be on the critical chain. In such a case, the team as a whole might be held accountable for why critical chain tasks weren't getting prioritized in an absolute strict way.