Kanban - a PM tool? Differences between SCRUM

A kanban is an agile project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency (or flow). Kanban boards use cards, columns, and continuous improvement to help technology and service teams commit to the right amount of work, and get it done!

That is a nice definition of the kanban which describe a whole idea. I really like it.

And here is a more precise and detail defition brought be Atlassian:

Kanban is a popular framework used to implement agile software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.

The work of all kanban teams revolves around a kanban board, a tool used to visualize work and optimize the flow of the work among the team. While physical boards are popular among some teams, virtual boards are a crucial feature in any agile software development tool for their traceability, easier collaboration, and accessibility from multiple locations.

Regardless of whether a team's board is physical or digital, their function is to ensure the team's work is visualized, their workflow is standardized, and all blockers and dependencies are immediately identified and resolved. A basic kanban board has a three-step workflow: To Do, In Progress, and Done. However, depending on a team's size, structure, and objectives, the workflow can be mapped to meet the unique process of any particular team. The kanban methodology relies upon full transparency of work and real-time communication of capacity, therefore the kanban board should be seen as the single source of truth for the team's work.

Typical workspace in the Atlassian JIRA kanban board:

Scrum vs. kanban

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. A simple table with a comparison of the two methods.

source: atlassian.com/agile/kanban

Automation for JIRA #003 - Epic linking

Guys from a Marketing deparment at our office wants clarity and order in their Jira kanban board.
Nice.

I wrote two new automations for them which are semi-complex but very interesting. I will discuss and share them below. The problem was to “sort issues” and always link them with an appropiate epic. When an issue is added (a task or a story), with a specified Atom (Atom is the unique specific name for the project) then create epic link to the appropriate Epic.
Ok, it sounds very simple but there is no such easy way to get there, plus I had to minded few exceptions.
The whole automation was divide into two.
The first one:

This automation is doing a linking thing while an Epic exists and when there is no Epic with a specific Atom then automation is creating it in the first place.

The Second one is doing “epic linking” with smart value {{destinationissue}}.

Why this automation can not be done in the one process? The answer is: The smart values can not be used in the JQL condition.

There are three if-else conditions. First one checks if there is story from issue labeled “releaseprocess” (the one from service desk), another condition checks if it is a story with the appropriate {{destinationIssue.issueType.name}} and the last one is for a task.

Automation for JIRA #002 - What is an issue?

Today let's move back to the beginning. A Jira foundations - issues. I will try to compress this knowledge and explain it as simple as I can.
You can browse an Atlassian documentation to find many more useful information.

Issues are the building blocks of any Jira project.
An issue could represent an epic, a story, a bug, a task, or another issue type in your project. In my work I use issues that way: An epic is „a big thing” it is like a complete main menu screen for a game. Than it can be divided it into smaller pieces – stories. For example a story can be graphics for that menu. After that tasks come into action: graphics for buttons, a logo graphics, icons, etc... If it is needed also sub-tasks can be added to this complete tree of issues.
A subtask can be created for an issue to either split the issue into smaller chunks, or to allow various aspects of an issue to be assigned to different people. If you find a subtask is holding up the resolution of an issue, you can convert the subtask to an issue, to allow it to be worked on independently. If you find an issue is really just a subtask of a bigger issue, you can also convert an issue to a subtask.

To sum this up in JIRA Core, an issue is essentially a packet of work. You can create relations between them, adding attachments, adding and editing special fields, manage them.

source: confluence.atlassian.com